From report at bugs.python.org Mon Sep 1 00:01:33 2014 From: report at bugs.python.org (Jason R. Coombs) Date: Sun, 31 Aug 2014 22:01:33 +0000 Subject: [issue22315] TypeError in error handling in distutils.dir_util.copy_tree In-Reply-To: <1409498105.67.0.812360133901.issue22315@psf.upfronthosting.co.za> Message-ID: <1409522493.39.0.890336833332.issue22315@psf.upfronthosting.co.za> Jason R. Coombs added the comment: Claudiu, thanks for the tip. That was quite helpful. I did not realize that unittest included a mock implementation. I've updated the test to use the same technique. I've furthermore verified that the test captures the failure and adjusted the implementation to match that expectation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 00:02:54 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 31 Aug 2014 22:02:54 +0000 Subject: [issue22315] TypeError in error handling in distutils.dir_util.copy_tree In-Reply-To: <1409498105.67.0.812360133901.issue22315@psf.upfronthosting.co.za> Message-ID: <3hmT7K6xBnz7Lrd@mail.python.org> Roundup Robot added the comment: New changeset 7304b9b95438 by Jason R. Coombs in branch '3.4': #22315: Add test to capture the failure. http://hg.python.org/cpython/rev/7304b9b95438 New changeset 300cd36eb25c by Jason R. Coombs in branch '3.4': #22315: Use technique outlined in test_file_util http://hg.python.org/cpython/rev/300cd36eb25c New changeset 3402813338db by Jason R. Coombs in branch '3.4': #22315: Provide an actual directory during test invocation. http://hg.python.org/cpython/rev/3402813338db New changeset ddb0f90620b7 by Jason R. Coombs in branch '3.4': #22315: Use an existent directory for 'src' to trigger appropriate behavior. http://hg.python.org/cpython/rev/ddb0f90620b7 New changeset 75a5cc4ef31c by Jason R. Coombs in branch '3.4': #22315: Use advertised API for OSError http://hg.python.org/cpython/rev/75a5cc4ef31c New changeset 640c575ab3e1 by Jason R. Coombs in branch 'default': Merge with 3.4; Closes #22315 http://hg.python.org/cpython/rev/640c575ab3e1 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 00:03:23 2014 From: report at bugs.python.org (Jason R. Coombs) Date: Sun, 31 Aug 2014 22:03:23 +0000 Subject: [issue22315] TypeError in error handling in distutils.dir_util.copy_tree In-Reply-To: <1409498105.67.0.812360133901.issue22315@psf.upfronthosting.co.za> Message-ID: <1409522603.14.0.269240143187.issue22315@psf.upfronthosting.co.za> Changes by Jason R. Coombs : ---------- stage: resolved -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 02:24:38 2014 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 01 Sep 2014 00:24:38 +0000 Subject: [issue22257] PEP 432: Redesign the interpreter startup sequence In-Reply-To: <1409503379.34.0.0856776287133.issue22257@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: Thanks for the reference! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 02:44:46 2014 From: report at bugs.python.org (Tim Chase) Date: Mon, 01 Sep 2014 00:44:46 +0000 Subject: [issue22319] mailbox.MH chokes on directories without .mh_sequences Message-ID: <1409532286.19.0.0096423454666.issue22319@psf.upfronthosting.co.za> New submission from Tim Chase: If a mailbox.MH() object is created by pointing at a path that exists but doesn't contain a ".mh_sequences" file, it raises an exception upon iteration over .{iter,}items() rather than gracefully assuming that the file is empty. I encountered this by pointing it at a Claws Mail IMAP-cache folder (which claims to store its messages in MH format? but it doesn't place a .mh_sequences file in those folders) only to have it raise an exception. To replicate: $ mkdir empty $ python >>> import mailbox >>> for msg in mailbox.MH('empty').values(): pass I suspect this could simply wrap the "f = open(os.path.join(self._path, '.mh_sequences'), 'r')" and following lines in a check to ignore the file if it doesn't exist (returning the empty "results"). ? http://www.claws-mail.org/faq/index.php/General_Information#How_does_Claws_Mail_store_mails.3F ---------- components: Library (Lib) messages: 226197 nosy: gumnos priority: normal severity: normal status: open title: mailbox.MH chokes on directories without .mh_sequences type: behavior versions: Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 02:52:20 2014 From: report at bugs.python.org (Tim Chase) Date: Mon, 01 Sep 2014 00:52:20 +0000 Subject: [issue22319] mailbox.MH chokes on directories without .mh_sequences In-Reply-To: <1409532286.19.0.0096423454666.issue22319@psf.upfronthosting.co.za> Message-ID: <1409532740.35.0.639799353877.issue22319@psf.upfronthosting.co.za> Changes by Tim Chase : ---------- keywords: +patch Added file: http://bugs.python.org/file36515/mailbox_mh_sequences.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 02:57:22 2014 From: report at bugs.python.org (Tim Chase) Date: Mon, 01 Sep 2014 00:57:22 +0000 Subject: [issue22319] mailbox.MH chokes on directories without .mh_sequences In-Reply-To: <1409532286.19.0.0096423454666.issue22319@psf.upfronthosting.co.za> Message-ID: <1409533042.02.0.4433235827.issue22319@psf.upfronthosting.co.za> Changes by Tim Chase : Added file: http://bugs.python.org/file36516/mailbox_mh_sequences_lbyl.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 03:18:05 2014 From: report at bugs.python.org (Martin Panter) Date: Mon, 01 Sep 2014 01:18:05 +0000 Subject: [issue12707] Deprecate addinfourl getters In-Reply-To: <1312760770.57.0.2285900636.issue12707@psf.upfronthosting.co.za> Message-ID: <1409534285.89.0.781872565659.issue12707@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 03:25:03 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 01 Sep 2014 01:25:03 +0000 Subject: [issue22318] unitest documentation on assertItemsEqual misleading In-Reply-To: <1409522154.37.0.82658213186.issue22318@psf.upfronthosting.co.za> Message-ID: <1409534703.88.0.72525192785.issue22318@psf.upfronthosting.co.za> R. David Murray added the comment: I'm not sure what you saw when "reading the code". I don't see any 'a is b' in there (only 'elem is NULL', which is correct). This has nothing to do with unittest, and everything to do with how == is defined/implemented in python. The invariant is that if two objects are equal, their hashes *must* be equal, and the hash check is used as a fastpath to skip items that are not equal without doing a full comparison. If you implement __eq__, you must implement __hash__ (or set it to None, thus marking the objects as not hashable). Not doing so is an error in Python3 (and probably also in python2 if you are using new style classes, but I didn't check). So, it is your objects that are buggy, I'm afraid, not unittest. ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 03:26:34 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 01 Sep 2014 01:26:34 +0000 Subject: [issue22319] mailbox.MH chokes on directories without .mh_sequences In-Reply-To: <1409532286.19.0.0096423454666.issue22319@psf.upfronthosting.co.za> Message-ID: <1409534794.24.0.376033342369.issue22319@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- components: +email nosy: +barry, r.david.murray stage: -> patch review versions: +Python 3.4, Python 3.5 -Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 03:34:25 2014 From: report at bugs.python.org (Martin Panter) Date: Mon, 01 Sep 2014 01:34:25 +0000 Subject: [issue4733] Add a "decode to declared encoding" version of urlopen to urllib In-Reply-To: <1230068654.82.0.881542673607.issue4733@psf.upfronthosting.co.za> Message-ID: <1409535265.38.0.494264333543.issue4733@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 03:47:13 2014 From: report at bugs.python.org (Hideaki Muranami) Date: Mon, 01 Sep 2014 01:47:13 +0000 Subject: [issue22320] Invalid link in General Python FAQ Message-ID: <1409536033.16.0.941096686527.issue22320@psf.upfronthosting.co.za> New submission from Hideaki Muranami: Link of "Developer FAQ" on https://docs.python.org/3.4/faq/general.html#how-do-i-obtain-a-copy-of-the-python-source is invalid. ---------- assignee: docs at python components: Documentation messages: 226199 nosy: docs at python, mnamihdk priority: normal severity: normal status: open title: Invalid link in General Python FAQ versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 04:02:42 2014 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 01 Sep 2014 02:02:42 +0000 Subject: [issue22316] Add rule about "extraneous whitespace around colon" to "Whitespace In Expressions and Statements" of PEP8 In-Reply-To: <1409500963.42.0.440331342486.issue22316@psf.upfronthosting.co.za> Message-ID: <1409536962.32.0.625904829913.issue22316@psf.upfronthosting.co.za> Guido van Rossum added the comment: Just like for other binary operators (except for the ones mentioned as always needing spaces), the spaces around ":" are neither mandatory nor objectionable. I am not making up a new rule, this is how I've always thought -- we just have to make it explicit that x[1: n] is wrong. How about this: - However, in a slice the colon acts like a binary operator, and should have equal amounts on either side (treating it as the operator with the lowest priority). In an extended slice, both colons must have the same amount of spacing applied. Exception: when a slice parameter is omitted, the space is omitted. :: Yes:: ham[1:9], ham[1:9:3], ham[:9:3], ham[1::3], ham[1:9:] ham[lower:upper], ham[lower:upper:], ham[lower::step] ham[lower+offset : upper+offset] ham[: upper_fn(x) : step_fn(x)], ham[:: step_fn(x)] ham[lower + offset : upper + offset] No:: ham[lower + offset:upper + offset] ham[1: 9], ham[1 :9], ham[1:9 :3] ham[lower : : upper] ham[ : upper] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 05:10:11 2014 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 01 Sep 2014 03:10:11 +0000 Subject: [issue22316] Add rule about "extraneous whitespace around colon" to "Whitespace In Expressions and Statements" of PEP8 In-Reply-To: <1409536962.32.0.625904829913.issue22316@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: Looks good to me! (and covers several cases that hadn't occurred to me before) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 05:20:30 2014 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 01 Sep 2014 03:20:30 +0000 Subject: [issue22316] Add rule about "extraneous whitespace around colon" to "Whitespace In Expressions and Statements" of PEP8 In-Reply-To: <1409500963.42.0.440331342486.issue22316@psf.upfronthosting.co.za> Message-ID: <1409541630.72.0.657776831876.issue22316@psf.upfronthosting.co.za> Guido van Rossum added the comment: Committed rev e98737176f1d. If there's more discussion I can add more. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 05:22:48 2014 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 01 Sep 2014 03:22:48 +0000 Subject: [issue22316] Add rule about "extraneous whitespace around colon" to "Whitespace In Expressions and Statements" of PEP8 In-Reply-To: <1409500963.42.0.440331342486.issue22316@psf.upfronthosting.co.za> Message-ID: <1409541768.37.0.704948468956.issue22316@psf.upfronthosting.co.za> Guido van Rossum added the comment: Does anyone care that there is now one bullet in the "avoid spaces ..." list that isn't strictly about avoiding spaces? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 06:36:27 2014 From: report at bugs.python.org (Josh Lynn) Date: Mon, 01 Sep 2014 04:36:27 +0000 Subject: [issue22320] Invalid link in General Python FAQ In-Reply-To: <1409536033.16.0.941096686527.issue22320@psf.upfronthosting.co.za> Message-ID: <1409546187.89.0.549790604341.issue22320@psf.upfronthosting.co.za> Josh Lynn added the comment: Hello. I'm new to contributing to Python and this looks like a decent place to start. Please bear with me. Just to be sure, should the link of "Developer FAQ" be https://docs.python.org/devguide/faq.html? ---------- nosy: +josh.lynn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 06:57:01 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 01 Sep 2014 04:57:01 +0000 Subject: [issue22318] unitest documentation on assertItemsEqual misleading In-Reply-To: <1409522154.37.0.82658213186.issue22318@psf.upfronthosting.co.za> Message-ID: <1409547421.59.0.757717488694.issue22318@psf.upfronthosting.co.za> R. David Murray added the comment: Is is an object identity test, by the way, it has nothing to do with __hash__. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 07:11:03 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 01 Sep 2014 05:11:03 +0000 Subject: [issue22320] Invalid link in General Python FAQ In-Reply-To: <1409536033.16.0.941096686527.issue22320@psf.upfronthosting.co.za> Message-ID: <1409548263.63.0.0827939919538.issue22320@psf.upfronthosting.co.za> Ned Deily added the comment: Hideaki, thanks for the report. Josh, yes ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 07:27:00 2014 From: report at bugs.python.org (Josh Lynn) Date: Mon, 01 Sep 2014 05:27:00 +0000 Subject: [issue22320] Invalid link in General Python FAQ In-Reply-To: <1409536033.16.0.941096686527.issue22320@psf.upfronthosting.co.za> Message-ID: <1409549220.57.0.610347461891.issue22320@psf.upfronthosting.co.za> Josh Lynn added the comment: Ned, thank you! This patch updates the link in the General FAQ from a broken link to be "https://docs.python.org/devguide/faq.html". ---------- keywords: +patch Added file: http://bugs.python.org/file36517/faqLinkUpdate.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 07:29:28 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 01 Sep 2014 05:29:28 +0000 Subject: [issue22320] Invalid link in General Python FAQ In-Reply-To: <1409536033.16.0.941096686527.issue22320@psf.upfronthosting.co.za> Message-ID: <1409549368.2.0.476084718895.issue22320@psf.upfronthosting.co.za> Berker Peksag added the comment: We can use https://docs.python.org/devguide/setup.html in that paragraph. It has more information about compiling Python. ---------- nosy: +berker.peksag stage: -> patch review versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 07:45:45 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 01 Sep 2014 05:45:45 +0000 Subject: [issue22320] Invalid link in General Python FAQ In-Reply-To: <1409536033.16.0.941096686527.issue22320@psf.upfronthosting.co.za> Message-ID: <1409550345.36.0.323489370949.issue22320@psf.upfronthosting.co.za> Ned Deily added the comment: Good point, Berker. The general FAQ predates the Developer's Guide. Josh, your patch looked good; would you care to update it? In any case, if you plan to contribute further patches (and we hope you do), please be sure to fill out a contributor form (https://docs.python.org/devguide/patch.html#licensing). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 07:58:55 2014 From: report at bugs.python.org (Josh Lynn) Date: Mon, 01 Sep 2014 05:58:55 +0000 Subject: [issue22320] Invalid link in General Python FAQ In-Reply-To: <1409536033.16.0.941096686527.issue22320@psf.upfronthosting.co.za> Message-ID: <1409551135.0.0.89570720989.issue22320@psf.upfronthosting.co.za> Josh Lynn added the comment: That page makes more sense! I have updated the paragraph to link to the "Getting Started Guide" at https://docs.python.org/devguide/setup.html Ned, I have signed a contributor form so it should be recorded soon. I plan on this being the first of many contributions :) Thank you! ---------- Added file: http://bugs.python.org/file36518/faqLinkUpdate.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 08:10:34 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 01 Sep 2014 06:10:34 +0000 Subject: [issue22315] TypeError in error handling in distutils.dir_util.copy_tree In-Reply-To: <1409498105.67.0.812360133901.issue22315@psf.upfronthosting.co.za> Message-ID: <1409551834.46.0.448269824152.issue22315@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 08:42:40 2014 From: report at bugs.python.org (Claudiu Popa) Date: Mon, 01 Sep 2014 06:42:40 +0000 Subject: [issue18615] sndhdr.whathdr could return a namedtuple In-Reply-To: <1375370275.79.0.808837089288.issue18615@psf.upfronthosting.co.za> Message-ID: <1409553760.65.0.196309886659.issue18615@psf.upfronthosting.co.za> Claudiu Popa added the comment: Serhiy, is there anything left to do for this patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 08:45:05 2014 From: report at bugs.python.org (Claudiu Popa) Date: Mon, 01 Sep 2014 06:45:05 +0000 Subject: [issue21527] concurrent.futures.ThreadPoolExecutor does not use a default value In-Reply-To: <1400453267.44.0.909455514702.issue21527@psf.upfronthosting.co.za> Message-ID: <1409553904.99.0.0821659599378.issue21527@psf.upfronthosting.co.za> Claudiu Popa added the comment: Thank you, Guido. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 09:02:03 2014 From: report at bugs.python.org (Rebecka) Date: Mon, 01 Sep 2014 07:02:03 +0000 Subject: [issue22296] cookielib uses time.time(), making incorrect checks of expiration times in cookies In-Reply-To: <1409306450.24.0.723741077293.issue22296@psf.upfronthosting.co.za> Message-ID: <1409554923.93.0.664045273487.issue22296@psf.upfronthosting.co.za> Rebecka added the comment: I've checked and an updated test file for 3.4 shows the same behaviour in the renamed module http.cookiejar. Even though no standard exists I hope 3.4+ would be changed to simplify the cookie handling, since there is a lot of hassle converting UTC times to local times (which in general should be avoided to avoid introducing further problems with e.g. daylight savings). ---------- Added file: http://bugs.python.org/file36519/cookie_timestamp_test_3.4.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 09:08:42 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 01 Sep 2014 07:08:42 +0000 Subject: [issue22320] Invalid link in General Python FAQ In-Reply-To: <1409536033.16.0.941096686527.issue22320@psf.upfronthosting.co.za> Message-ID: <3hmjF61cTxz7Ln0@mail.python.org> Roundup Robot added the comment: New changeset 241f9aa9fb89 by Ned Deily in branch '2.7': Issue #22320: Fix broken link in the General Python FAQ. http://hg.python.org/cpython/rev/241f9aa9fb89 New changeset 3eaba8a0cb3a by Ned Deily in branch '3.4': Issue #22320: Fix broken link in the General Python FAQ. http://hg.python.org/cpython/rev/3eaba8a0cb3a New changeset c81e2b6eccd8 by Ned Deily in branch 'default': Issue #22320: merge from 3.4 http://hg.python.org/cpython/rev/c81e2b6eccd8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 09:13:19 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 01 Sep 2014 07:13:19 +0000 Subject: [issue22320] Invalid link in General Python FAQ In-Reply-To: <1409536033.16.0.941096686527.issue22320@psf.upfronthosting.co.za> Message-ID: <1409555599.23.0.597224104546.issue22320@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks again for the patch! (I did change the wording slightly.) ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 09:14:23 2014 From: report at bugs.python.org (Josh Lynn) Date: Mon, 01 Sep 2014 07:14:23 +0000 Subject: [issue22320] Invalid link in General Python FAQ In-Reply-To: <1409536033.16.0.941096686527.issue22320@psf.upfronthosting.co.za> Message-ID: <1409555663.51.0.38169230589.issue22320@psf.upfronthosting.co.za> Josh Lynn added the comment: No problem! Thank you! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 09:19:45 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 01 Sep 2014 07:19:45 +0000 Subject: [issue10240] dict.update.__doc__ is misleading In-Reply-To: <1288406048.13.0.615215732385.issue10240@psf.upfronthosting.co.za> Message-ID: <1409555985.98.0.201652733508.issue10240@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 09:38:38 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 01 Sep 2014 07:38:38 +0000 Subject: [issue22311] Pip 404's In-Reply-To: <1409477681.69.0.43132778549.issue22311@psf.upfronthosting.co.za> Message-ID: <1409557118.75.0.633655307456.issue22311@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +dstufft _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 10:29:49 2014 From: report at bugs.python.org (Andrea Torre) Date: Mon, 01 Sep 2014 08:29:49 +0000 Subject: [issue20567] test_idle causes test_ttk_guionly 'can't invoke "event" command: application has been destroyed' messages from Tk In-Reply-To: <1391902578.02.0.588798272285.issue20567@psf.upfronthosting.co.za> Message-ID: <1409560189.33.0.92806584438.issue20567@psf.upfronthosting.co.za> Andrea Torre added the comment: Ubuntu 12.04 64-bit Python 2.7.3 (virtualenv) Hi, just adding a few info, hope not completely useless, that seem related to the issue. I got the same message when running nosetests against my source. It's an application using Tkinter as frontend. All tests pass, though. Besides, I always destroy root in tearDown(). I noticed that the the issue only comes up when i run tests without specifying any path, like in nosetests -vs. If i enter nosetests -vs tests/unit/ tests/integration/ everything runs smooth. ---------- nosy: +andtorg versions: -Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 10:48:19 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 01 Sep 2014 08:48:19 +0000 Subject: [issue18615] sndhdr.whathdr could return a namedtuple In-Reply-To: <1375370275.79.0.808837089288.issue18615@psf.upfronthosting.co.za> Message-ID: <1409561299.6.0.576414207283.issue18615@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The patch looks good. I'll apply it shortly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 10:48:49 2014 From: report at bugs.python.org (=?utf-8?q?Andreas_R=C3=B8sdal?=) Date: Mon, 01 Sep 2014 08:48:49 +0000 Subject: [issue20215] Python2.7 socketserver can not listen IPv6 address In-Reply-To: <1389319382.42.0.481013787618.issue20215@psf.upfronthosting.co.za> Message-ID: <1409561329.47.0.710287081861.issue20215@psf.upfronthosting.co.za> Andreas R?sdal added the comment: Is there any interest in this patch? it would be nice with a review of the patch. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 10:52:44 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 01 Sep 2014 08:52:44 +0000 Subject: [issue22306] Inconsistent division by 0 behaviour in decimal module In-Reply-To: <1409385535.02.0.413020952628.issue22306@psf.upfronthosting.co.za> Message-ID: <1409561564.53.0.0942448713547.issue22306@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > Sorry. Scratch my last comment. I see from the docs > ( https://docs.python.org/3/library/decimal.html ) >vthat the decimal module explicitly references that IBM spec. > I imagine that standard python arithmatic doesn't even attempt > to conform to this ibm spec. That is exactly correct. Closing as not-a-bug. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 10:55:18 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 01 Sep 2014 08:55:18 +0000 Subject: [issue22293] unittest.mock: use slots in MagicMock to reduce memory footprint In-Reply-To: <1409223925.36.0.353064472257.issue22293@psf.upfronthosting.co.za> Message-ID: <1409561718.08.0.167629275462.issue22293@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- stage: -> needs patch versions: +Python 3.5 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 10:59:42 2014 From: report at bugs.python.org (Heather McCartney) Date: Mon, 01 Sep 2014 08:59:42 +0000 Subject: [issue21400] Code coverage documentation is out-of-date. In-Reply-To: <1398870474.7.0.668295680228.issue21400@psf.upfronthosting.co.za> Message-ID: <1409561982.9.0.841930575645.issue21400@psf.upfronthosting.co.za> Heather McCartney added the comment: Here's a patch with a suggestion for the new text, with the part about the code coverage website removed. Once that part was gone, I found the remainder slightly easier to read when the options were presented the other way around, so the simpler (although slower) option to run all the tests with coverage appears first. But I'm happy to change this (or anything else) if you feel that would be better. ---------- keywords: +patch nosy: +hmcc Added file: http://bugs.python.org/file36520/issue21400-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 11:17:05 2014 From: report at bugs.python.org (Akira Li) Date: Mon, 01 Sep 2014 09:17:05 +0000 Subject: [issue22296] cookielib uses time.time(), making incorrect checks of expiration times in cookies In-Reply-To: <1409306450.24.0.723741077293.issue22296@psf.upfronthosting.co.za> Message-ID: <1409563025.93.0.00957645105775.issue22296@psf.upfronthosting.co.za> Akira Li added the comment: time.time() returns the current time in seconds since Epoch it is neither local nor UTC time. It can be converted to both. You can get local time using datetime.fromtimestamp(ts). You can get UTC time using datetime.utcfromtimestamp(ts) or to get an aware datetime object: datetime.fromtimestamp(ts, timezone.utc), where ts is the timestamp in seconds since Epoch. I don't know whether there is an issue with cookie.is_expired() but it is incorrect to use time.mktime() with UTC time tuple unless the local time is UTC. To get the timestamp from a datetime object, you could use .timestamp() method instead: from datetime import datetime, timezone now = datetime.now(timezone.utc) # the current time seconds_since_epoch = now.timestamp() seconds_since_epoch = time.time() # might be less precise ---------- nosy: +akira _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 11:29:32 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 01 Sep 2014 09:29:32 +0000 Subject: [issue19447] py_compile.compile raises if a file has bad encoding In-Reply-To: <1383126127.06.0.0829407086057.issue19447@psf.upfronthosting.co.za> Message-ID: <3hmmMc1MG5z7Llx@mail.python.org> Roundup Robot added the comment: New changeset 2d0bcb653085 by Berker Peksag in branch '3.4': Issue #19447: Suppress output of py_compile.compile(). http://hg.python.org/cpython/rev/2d0bcb653085 New changeset a8ef9d7c4d20 by Berker Peksag in branch 'default': Issue #19447: Suppress output of py_compile.compile(). http://hg.python.org/cpython/rev/a8ef9d7c4d20 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 11:30:29 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 01 Sep 2014 09:30:29 +0000 Subject: [issue19447] py_compile.compile raises if a file has bad encoding In-Reply-To: <1383126127.06.0.0829407086057.issue19447@psf.upfronthosting.co.za> Message-ID: <1409563829.79.0.149772895002.issue19447@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 11:50:47 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 01 Sep 2014 09:50:47 +0000 Subject: [issue20567] test_idle causes test_ttk_guionly 'can't invoke "event" command: application has been destroyed' messages from Tk In-Reply-To: <1391902578.02.0.588798272285.issue20567@psf.upfronthosting.co.za> Message-ID: <1409565047.97.0.277021390893.issue20567@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 12:03:22 2014 From: report at bugs.python.org (Dima Tisnek) Date: Mon, 01 Sep 2014 10:03:22 +0000 Subject: [issue22321] odd result for datetime.time.strftime("%s") Message-ID: <1409565802.22.0.948210004323.issue22321@psf.upfronthosting.co.za> New submission from Dima Tisnek: $ python2 -c 'import datetime; print datetime.time(10, 44, 11).strftime("%s")' -2208955189 $ python3 -c 'import datetime; print (datetime.time(10, 44, 11).strftime("%s"))' -2208955189 So apparently, datetime.time(...).strftime("%s") semantically "seconds since unix epoch" assumes Jan 1, 1900 for missing date part. However datetime module doesn't allow subtracting time objects, i.e. no assumption of date is made, where "same date" chould be reasonable. ---------- components: Extension Modules messages: 226224 nosy: Dima.Tisnek priority: normal severity: normal status: open title: odd result for datetime.time.strftime("%s") type: behavior versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 12:28:17 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 01 Sep 2014 10:28:17 +0000 Subject: [issue17396] modulefinder fails if module contains syntax error In-Reply-To: <1363003425.82.0.865184669213.issue17396@psf.upfronthosting.co.za> Message-ID: <1409567297.4.0.848892049254.issue17396@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: -> patch review type: -> behavior versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 12:29:35 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 01 Sep 2014 10:29:35 +0000 Subject: [issue20020] "modernize" the modulefinder module In-Reply-To: <1387425925.56.0.593354940747.issue20020@psf.upfronthosting.co.za> Message-ID: <1409567375.1.0.232658186816.issue20020@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 14:04:35 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 01 Sep 2014 12:04:35 +0000 Subject: [issue20215] Python2.7 socketserver can not listen IPv6 address In-Reply-To: <1389319382.42.0.481013787618.issue20215@psf.upfronthosting.co.za> Message-ID: <1409573075.64.0.625947323632.issue20215@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 14:24:29 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 01 Sep 2014 12:24:29 +0000 Subject: [issue22296] cookielib uses time.time(), making incorrect checks of expiration times in cookies In-Reply-To: <1409306450.24.0.723741077293.issue22296@psf.upfronthosting.co.za> Message-ID: <1409574269.46.0.586459633318.issue22296@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Note the .timestamp() method will work correctly if the datetime object is expressed in *local time*, which is not what Rebecka's code uses. Otherwise the incantation is a bit more complex: https://docs.python.org/3/library/datetime.html#datetime.datetime.timestamp (also .timestamp() doesn't exist in 2.7, in which case the manual computation must also be used) ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 14:36:55 2014 From: report at bugs.python.org (Akira Li) Date: Mon, 01 Sep 2014 12:36:55 +0000 Subject: [issue22296] cookielib uses time.time(), making incorrect checks of expiration times in cookies In-Reply-To: <1409306450.24.0.723741077293.issue22296@psf.upfronthosting.co.za> Message-ID: <1409575015.01.0.789639886282.issue22296@psf.upfronthosting.co.za> Akira Li added the comment: timestamp() method works correctly for an aware datetime objects as in my example (notice: timezone.utc in the code). The issue is not that it is a manual computation, the issue is that it is incorrect: #XXX WRONG, DO NOT DO IT time.mktime(datetime.datetime.utcnow().timetuple()) On older Python versions, given a utc time as a naive datetime object, POSIX timestamp is: ts = (utc_dt - datetime(1970, 1, 1)).total_seconds() utc_dt = datetime(1970, 1, 1) + timedelta(seconds=ts) # in reverse ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 14:41:26 2014 From: report at bugs.python.org (Akira Li) Date: Mon, 01 Sep 2014 12:41:26 +0000 Subject: [issue22296] cookielib uses time.time(), making incorrect checks of expiration times in cookies In-Reply-To: <1409306450.24.0.723741077293.issue22296@psf.upfronthosting.co.za> Message-ID: <1409575286.24.0.406362047116.issue22296@psf.upfronthosting.co.za> Akira Li added the comment: The last example assumes that time.gmtime(0) is 1970-01-01 00:00:00Z (otherwise time.time() may return different timestamp) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 14:52:25 2014 From: report at bugs.python.org (Tim Chase) Date: Mon, 01 Sep 2014 12:52:25 +0000 Subject: [issue22319] mailbox.MH chokes on directories without .mh_sequences In-Reply-To: <1409532286.19.0.0096423454666.issue22319@psf.upfronthosting.co.za> Message-ID: <1409575945.79.0.536969498697.issue22319@psf.upfronthosting.co.za> Tim Chase added the comment: I had to tweak the example reproduction code as it seemed to succeed (i.e., fail to demonstrate the problem) in some instances. The same exception occurs, but here's the full original traceback: $ cd /home/tim/.claws-mail/imapcache/mail.example.com/tim at example.com/INBOX/ $ python3 Python 3.2.3 (default, Feb 20 2013, 14:44:27) [GCC 4.7.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import mailbox >>> m = mailbox.MH('.') >>> for msg in m: ... print(msg) ... Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.2/mailbox.py", line 114, in itervalues value = self[key] File "/usr/lib/python3.2/mailbox.py", line 78, in __getitem__ return self.get_message(key) File "/usr/lib/python3.2/mailbox.py", line 1019, in get_message for name, key_list in self.get_sequences().items(): File "/usr/lib/python3.2/mailbox.py", line 1128, in get_sequences f = open(os.path.join(self._path, '.mh_sequences'), 'r') IOError: [Errno 2] No such file or directory: '/home/tim/.claws-mail/imapcache/mail.example.com/tim at example.com/INBOX/.mh_sequences' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 16:19:42 2014 From: report at bugs.python.org (Ian Cordasco) Date: Mon, 01 Sep 2014 14:19:42 +0000 Subject: [issue19494] urllib2.HTTPBasicAuthHandler (or urllib.request.HTTPBasicAuthHandler) doesn't work with GitHub API v3 and similar In-Reply-To: <1383577219.47.0.139805262488.issue19494@psf.upfronthosting.co.za> Message-ID: <1409581182.15.0.759094086885.issue19494@psf.upfronthosting.co.za> Changes by Ian Cordasco : ---------- nosy: +icordasc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 16:40:36 2014 From: report at bugs.python.org (Ian Cordasco) Date: Mon, 01 Sep 2014 14:40:36 +0000 Subject: [issue19494] urllib2.HTTPBasicAuthHandler (or urllib.request.HTTPBasicAuthHandler) doesn't work with GitHub API v3 and similar In-Reply-To: <1383577219.47.0.139805262488.issue19494@psf.upfronthosting.co.za> Message-ID: <1409582436.22.0.580807017915.issue19494@psf.upfronthosting.co.za> Ian Cordasco added the comment: > However, one sticking point is whether that optimization may also have adverse effects in terms of security (since we would always be sending auth headers, even when the server doesn't ask for it...). Antoine's concern has always been a concern of mine. There's an important part of this discussion that seems to have been left off. Even security conscious websites like GitHub do not return 404s for all endpoints that require you to authenticate. That fact aside, I think seeing how popular the package Matej added to PyPI will be a good way to decide how essential this is to add to Python 2.7. I am of course biased as a requests core developer and a large-scale GitHub API consumer, but I think this is a fairer way to make a decision. The patch for Python 3.5, however, looks great. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 17:11:58 2014 From: report at bugs.python.org (Peter Wu) Date: Mon, 01 Sep 2014 15:11:58 +0000 Subject: [issue22322] Zip files created by `git archive` result in a SyntaxError (due to comment?) Message-ID: <1409584318.1.0.656275318382.issue22322@psf.upfronthosting.co.za> New submission from Peter Wu: Files created by `git archive` are not understood by the Python interpreter. This could be caused by the additional comment (for the commit hash) in the file. echo 'print(1)' > __main__.py git init && git add __main__.py && git commit -m init git archive --format=zip HEAD > y.zip python y.zip Packing it with `zip x.zip __main__.py && python x.zip` works. ---------- components: Extension Modules messages: 226230 nosy: lekensteyn priority: normal severity: normal status: open title: Zip files created by `git archive` result in a SyntaxError (due to comment?) type: behavior versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 18:13:24 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 01 Sep 2014 16:13:24 +0000 Subject: [issue22321] odd result for datetime.time.strftime("%s") In-Reply-To: <1409565802.22.0.948210004323.issue22321@psf.upfronthosting.co.za> Message-ID: <1409588004.93.0.893022550485.issue22321@psf.upfronthosting.co.za> R. David Murray added the comment: I believe this is effectively a duplicate of issue 12750. That is, python doesn't do anything in particular with %s, it just lets the platform do what it will. Issue 12750 is about making what it does consistent and cross-platform. (On gentoo linux I get -1 from your examples for both python2 and python3.) You should any any further comments to issue 12750. ---------- nosy: +r.david.murray resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> datetime.strftime('%s') should respect tzinfo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 18:26:14 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 01 Sep 2014 16:26:14 +0000 Subject: [issue22322] Zip files created by `git archive` result in a SyntaxError (due to comment?) In-Reply-To: <1409584318.1.0.656275318382.issue22322@psf.upfronthosting.co.za> Message-ID: <1409588774.39.0.529472545637.issue22322@psf.upfronthosting.co.za> R. David Murray added the comment: You are correct. zipimport does not support zip files with comments. There is already an open issue (issue 5950) for adding support for this. ---------- nosy: +r.david.murray resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Make zipimport work with zipfile containing comments _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 18:36:16 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 01 Sep 2014 16:36:16 +0000 Subject: [issue5950] Make zipimport work with zipfile containing comments In-Reply-To: <1241628586.95.0.0801479384158.issue5950@psf.upfronthosting.co.za> Message-ID: <1409589376.04.0.79697903229.issue5950@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See issue22322 for yet one use case ("git archive" creates ZIP file with archive comment). ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 19:32:33 2014 From: report at bugs.python.org (Donald Stufft) Date: Mon, 01 Sep 2014 17:32:33 +0000 Subject: [issue22311] Pip 404's In-Reply-To: <1409477681.69.0.43132778549.issue22311@psf.upfronthosting.co.za> Message-ID: <1409592753.11.0.932856232491.issue22311@psf.upfronthosting.co.za> Donald Stufft added the comment: Yea can you give more information? How are you reproducing this? What version of Python? I can't reproduce it locally. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 19:40:13 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 01 Sep 2014 17:40:13 +0000 Subject: [issue19494] urllib2.HTTPBasicAuthHandler (or urllib.request.HTTPBasicAuthHandler) doesn't work with GitHub API v3 and similar In-Reply-To: <1383577219.47.0.139805262488.issue19494@psf.upfronthosting.co.za> Message-ID: <1409593213.76.0.207755930286.issue19494@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: -terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 19:42:38 2014 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 01 Sep 2014 17:42:38 +0000 Subject: [issue22311] Pip 404's In-Reply-To: <1409477681.69.0.43132778549.issue22311@psf.upfronthosting.co.za> Message-ID: <1409593358.95.0.153147955466.issue22311@psf.upfronthosting.co.za> Stefan Behnel added the comment: CPython 3.5, latest development versions. This started failing on August 21st, presumably with the changes for issue 22118. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 19:43:41 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 01 Sep 2014 17:43:41 +0000 Subject: [issue21965] Add support for Memory BIO to _ssl In-Reply-To: <1405156134.57.0.513965198344.issue21965@psf.upfronthosting.co.za> Message-ID: <1409593421.14.0.103928574374.issue21965@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > We can leave these undocumented at the Python level if you prefer. I'd rather that indeed. If there's a specific need, we can expose them as a separate issue. > Maybe just "SSLInstance", would that be better than "SSLObject"? That doesn't sound much better :-) Ok, let's keep SSLObject then. > I believe that the overall _ssl/ssl code could be simplified by: [snip] That would be nice. Would that also handle e.g. socket timeouts? > To use SSLObject as a mixin it would have to be aware of these two uses of its subclasses. It could be done but I don't think it's 100% clean either. Fair enough. We just have to make sure to implement and test new APIs twice (e.g the version() method in issue20421). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 19:45:31 2014 From: report at bugs.python.org (Donald Stufft) Date: Mon, 01 Sep 2014 17:45:31 +0000 Subject: [issue22311] Pip 404's In-Reply-To: <1409477681.69.0.43132778549.issue22311@psf.upfronthosting.co.za> Message-ID: <1409593531.89.0.992392968538.issue22311@psf.upfronthosting.co.za> Donald Stufft added the comment: Ok, I'll pull down Python 3.5 in a bit and see what is what. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 19:50:31 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 01 Sep 2014 17:50:31 +0000 Subject: [issue22311] Pip 404's In-Reply-To: <1409477681.69.0.43132778549.issue22311@psf.upfronthosting.co.za> Message-ID: <1409593831.92.0.343968660677.issue22311@psf.upfronthosting.co.za> Antoine Pitrou added the comment: No need to keep this open, this is tackled in issue 22278. ---------- resolution: -> duplicate stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 19:52:44 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 01 Sep 2014 17:52:44 +0000 Subject: [issue22278] urljoin duplicate slashes In-Reply-To: <1409075887.24.0.237889697027.issue22278@psf.upfronthosting.co.za> Message-ID: <1409593964.68.0.260075102611.issue22278@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Those tests don't seem to bring much. Part of them are straight from the RFC (and therefore already in the current test suite, I assume), part of them are for non-HTTP protocols such as "fred" (!). A couple of them seem to be genuine, although only one fails and it's a corner case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 20:00:29 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 01 Sep 2014 18:00:29 +0000 Subject: [issue22293] unittest.mock: use slots in MagicMock to reduce memory footprint In-Reply-To: <1409223925.36.0.353064472257.issue22293@psf.upfronthosting.co.za> Message-ID: <1409594429.1.0.47839199699.issue22293@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > This means that by the end of a run, we have quite a lot of references to MagicMocks. It sounds like you are bitten by unittest keeping references to all past TestCase instances. This has been fixed recently (see #11798). ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 21:57:54 2014 From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=) Date: Mon, 01 Sep 2014 19:57:54 +0000 Subject: [issue22301] smtplib.SMTP.starttls' documentation is just confusing In-Reply-To: <1409345812.89.0.82925514828.issue22301@psf.upfronthosting.co.za> Message-ID: <87egvv9kqo.fsf@tumbolandia.net> Michele Orr? added the comment: "R. David Murray" writes: > Since we want to encourage people to use the context, that sounds > reasonable for 3.x at least. Concerning this specific proposition, I really don't see the point in having .starttls() not simply accepting a SSLContext as argument, as imaplib.IMAP4.starttls is already doing, for example. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 23:18:11 2014 From: report at bugs.python.org (Akima) Date: Mon, 01 Sep 2014 21:18:11 +0000 Subject: [issue22302] Windows os.path.isabs UNC path bug In-Reply-To: <1409349502.55.0.177656049078.issue22302@psf.upfronthosting.co.za> Message-ID: <1409606291.14.0.410819954665.issue22302@psf.upfronthosting.co.za> Akima added the comment: I checked for the existence of this bug in 2 other python versions today. It's present in CPython 3.4.1, but CPython 2.7.5 doesn't exhibit the issue. Python 2.7.5 (default, May 15 2013, 22:43:36) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import os.path >>> os.path.isabs(r"\\server") True >>> os.path.isabs(r"\\server\share") True >>> os.path.isabs(r"\\server\share\folder") True >>> os.path.isabs(r"\\server\share\folder\folder") True >>> Python 3.4.1 (v3.4.1:c0e311e010fc, May 18 2014, 10:38:22) [MSC v.1600 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import os.path >>> os.path.isabs(r"\\server") True >>> os.path.isabs(r"\\server\share") False >>> os.path.isabs(r"\\server\share\folder") True >>> os.path.isabs(r"\\server\share\folder\folder") True >>> ---------- versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 23:32:14 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 01 Sep 2014 21:32:14 +0000 Subject: [issue22323] Rewrite PyUnicode_AsWideChar() and PyUnicode_AsWideCharString() Message-ID: <1409607134.14.0.210351686888.issue22323@psf.upfronthosting.co.za> New submission from STINNER Victor: I would like to deprecate PyUnicode_AsUnicode(), see the issue #22271 for the rationale (hint: memory footprint). The first step is to rewrite PyUnicode_AsWideChar() and PyUnicode_AsWideCharString() to not call PyUnicode_AsUnicode() anymore. Attached patch implements this. The code is based on PyUnicode_AsUnicode(), but it's more tricky because PyUnicode_AsWideChar() can truncate the string, and PyUnicode_AsUnicode() does no copy characters if kind == sizeof(wchar_t), PyASCIIObject.wstr "just" points to data. I hate PyUnicode_AsWideChar(), but we must keep it for backward compatibility :-) It would be possible to write an optimized PyUnicode_AsWideCharString() which computes the length, allocate memory and write wide characters, but I don't want to have 3 functions converting a Python string to a wide character string. There are already PyUnicode_AsUnicodeAndSize() and unicode_aswidechar() (+ unicode_aswidechar_len()). ---------- messages: 226244 nosy: haypo, loewis priority: normal severity: normal status: open title: Rewrite PyUnicode_AsWideChar() and PyUnicode_AsWideCharString() type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 23:42:44 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 01 Sep 2014 21:42:44 +0000 Subject: [issue22271] Deprecate PyUnicode_AsUnicode(): emit a DeprecationWarning In-Reply-To: <1408930876.51.0.0157656751737.issue22271@psf.upfronthosting.co.za> Message-ID: <1409607764.43.0.206898193674.issue22271@psf.upfronthosting.co.za> STINNER Victor added the comment: > The deprecate PyUnicode_AsUnicode(), we should stop using it in Python itself. Here is the first step: issue #22323, "rewrite PyUnicode_AsWideChar() and PyUnicode_AsWideCharString()" (to not call PyUnicode_AsUnicode() anymore). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 1 23:55:14 2014 From: report at bugs.python.org (Mike Short) Date: Mon, 01 Sep 2014 21:55:14 +0000 Subject: [issue22154] ZipFile.open context manager support In-Reply-To: <1407311800.94.0.537081542584.issue22154@psf.upfronthosting.co.za> Message-ID: <1409608514.83.0.750571804628.issue22154@psf.upfronthosting.co.za> Mike Short added the comment: Context manager comment & code snippet added to zipfile doc - patch attached. ---------- keywords: +patch nosy: +Mike.Short Added file: http://bugs.python.org/file36521/zipfile.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 00:39:50 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 01 Sep 2014 22:39:50 +0000 Subject: [issue22324] Use PyUnicode_AsWideCharString() instead of PyUnicode_AsUnicode() Message-ID: <1409611190.39.0.820072774539.issue22324@psf.upfronthosting.co.za> New submission from STINNER Victor: I would like to deprecate PyUnicode_AsUnicode(), see the issue #22271 for the rationale (hint: memory footprint). To deprecate PyUnicode_AsUnicode(), we should stop using it internally. The attached patch is a work-in-progress patch, untested on Windows (only tested on Linux). It gives an idea of how many files should be modified. TODO: * Modify posixmodule.c: I don't understand how the Argument Clinic generates the call to PyUnicode_AsUnicode() when the parameter type is declared as "unicode". What is the "unicode" type? Where is the code generating the call to PyUnicode_AsUnicode()? * Modify a few other files. ---------- files: wchar.patch keywords: patch messages: 226247 nosy: haypo, loewis priority: normal severity: normal status: open title: Use PyUnicode_AsWideCharString() instead of PyUnicode_AsUnicode() type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file36522/wchar.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 00:41:29 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 01 Sep 2014 22:41:29 +0000 Subject: [issue22324] Use PyUnicode_AsWideCharString() instead of PyUnicode_AsUnicode() In-Reply-To: <1409611190.39.0.820072774539.issue22324@psf.upfronthosting.co.za> Message-ID: <1409611289.08.0.323839582735.issue22324@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, I didn't generated wchar.patch correctly: please ignore changes in the unicodeobject.c files. These changes are part of issues #22271 and #22323. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 00:41:40 2014 From: report at bugs.python.org (Demian Brecht) Date: Mon, 01 Sep 2014 22:41:40 +0000 Subject: [issue22278] urljoin duplicate slashes In-Reply-To: <1409075887.24.0.237889697027.issue22278@psf.upfronthosting.co.za> Message-ID: <1409611300.86.0.635034472186.issue22278@psf.upfronthosting.co.za> Demian Brecht added the comment: I'll try to get some time this week to extend the various test cases, thanks for pointing that out Antoine. I also found that, other than the few RFC-specific blocks in the link that Nick added in the other ticket, not only were they questionable (non-HTTP as Antoine pointed out), but they were also just plain wrong in some cases given the new semantics. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 00:53:41 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 01 Sep 2014 22:53:41 +0000 Subject: [issue22324] Use PyUnicode_AsWideCharString() instead of PyUnicode_AsUnicode() In-Reply-To: <1409611190.39.0.820072774539.issue22324@psf.upfronthosting.co.za> Message-ID: <1409612021.75.0.241064839645.issue22324@psf.upfronthosting.co.za> STINNER Victor added the comment: wchar_posixmodule.patch: patch for posixmodule.c. Sorry, the code calling PyUnicode_AsUnicode() was not generated by Argument Clinic in fact. ---------- Added file: http://bugs.python.org/file36523/wchar_posixmodule.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 01:28:57 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 01 Sep 2014 23:28:57 +0000 Subject: [issue22290] "AMD64 OpenIndiana 3.x" buildbot: assertion failed in PyObject_Call() in test_subprocess.test_preexec() In-Reply-To: <1409145083.35.0.252869476366.issue22290@psf.upfronthosting.co.za> Message-ID: <1409614137.31.0.813575785489.issue22290@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, a lot of tests fail with MemoryError on this buildbot. It may explain this issue. For example, test_json crashed with SIGSEGV in this build, probably because of an unhandled MemoryError exception: http://buildbot.python.org/all/builders/AMD64%20OpenIndiana%203.x/builds/8557/steps/test/logs/stdio ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 02:19:18 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 02 Sep 2014 00:19:18 +0000 Subject: [issue22166] test_codecs "leaking" references In-Reply-To: <1407444567.64.0.0425446064781.issue22166@psf.upfronthosting.co.za> Message-ID: <1409617158.32.0.825799298032.issue22166@psf.upfronthosting.co.za> STINNER Victor added the comment: ExceptionChainingTest uses a function to raise an arbitrary exception. Problem: the function and its parameter becomes part of the exception traceback. Shortly, the exception links indirectly to itself in a nice reference cycle... Example: --- import traceback class Err(Exception): def __del__(self): print("del") def raise_exc(exc): raise exc e = Err() try: raise_exc(e) except Exception as e: t = e.__traceback__ #traceback.clear_frames(t) e = None print("exit") --- Uncommand the call the clear_frames() to see the exception deleted before the exit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 02:24:03 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 02 Sep 2014 00:24:03 +0000 Subject: [issue22166] test_codecs leaks references In-Reply-To: <1407444567.64.0.0425446064781.issue22166@psf.upfronthosting.co.za> Message-ID: <1409617443.07.0.391415038539.issue22166@psf.upfronthosting.co.za> STINNER Victor added the comment: Attached: Draft patch to fix some reference leaks in test_codecs. ---------- title: test_codecs "leaking" references -> test_codecs leaks references Added file: http://bugs.python.org/file36524/test_codecs_fix1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 02:36:17 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 02 Sep 2014 00:36:17 +0000 Subject: [issue22166] test_codecs leaks references In-Reply-To: <1407444567.64.0.0425446064781.issue22166@psf.upfronthosting.co.za> Message-ID: <1409618177.06.0.0477784184549.issue22166@psf.upfronthosting.co.za> STINNER Victor added the comment: ExceptionChainingTest creates a random codec name. If you change the codec name to a fixed string like "xxx", ExceptionChainingTest.test_raise_by_type() doesn't leak anymore (when test_codecs_fix1.patch is applied), but other tests start to fail. We should maybe enhance the codecs API to be able to unregister a codec? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 03:11:04 2014 From: report at bugs.python.org (Mike Short) Date: Tue, 02 Sep 2014 01:11:04 +0000 Subject: [issue19826] Document that bug reporting by email is possible In-Reply-To: <1385668245.52.0.0107396832211.issue19826@psf.upfronthosting.co.za> Message-ID: <1409620264.3.0.679574575505.issue19826@psf.upfronthosting.co.za> Mike Short added the comment: Addition to bugs.html to describe submitting bugs via email ---------- keywords: +patch nosy: +Mike.Short Added file: http://bugs.python.org/file36525/bugs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 03:11:53 2014 From: report at bugs.python.org (Mike Short) Date: Tue, 02 Sep 2014 01:11:53 +0000 Subject: [issue19826] Document that bug reporting by email is possible In-Reply-To: <1385668245.52.0.0107396832211.issue19826@psf.upfronthosting.co.za> Message-ID: <1409620313.0.0.942317396933.issue19826@psf.upfronthosting.co.za> Mike Short added the comment: Same addition to the Python Dev Guide - seemed more appropriate on the tracker page vs. the triaging page. ---------- Added file: http://bugs.python.org/file36526/tracker.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 03:26:29 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 02 Sep 2014 01:26:29 +0000 Subject: [issue19826] Document that bug reporting by email is possible In-Reply-To: <1385668245.52.0.0107396832211.issue19826@psf.upfronthosting.co.za> Message-ID: <1409621189.67.0.236413917793.issue19826@psf.upfronthosting.co.za> R. David Murray added the comment: I'd be just as happy to not document this. The fact that you need an account first means that people will try to submit without an account, and get a bounce. It also works better when people reply on the bug tracker rather than by email. I'd not want to take the capability away, but I'd prefer to not document or encourage it. That, however, is just my opinion. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 03:26:57 2014 From: report at bugs.python.org (Martin Panter) Date: Tue, 02 Sep 2014 01:26:57 +0000 Subject: [issue1508475] transparent gzip compression in urllib Message-ID: <1409621217.82.0.902144791809.issue1508475@psf.upfronthosting.co.za> Martin Panter added the comment: I think the patch is indeed a bit short, for instannce it looks like calling read() without a size limit could bypass the decoding. Also, I wonder if Content-Encoding handling is better done at a higher level. What if someone wants to download a *.tar.gz file? They may not expect the tar file to be transparently decompressed. And I suspect this would blow up if you tried a partial range request. Transfer-Encoding is meant to be the proper way to transparently compress HTTP messages at a low level, but it doesn?t seem to be used as much in the real world. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 03:59:25 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 02 Sep 2014 01:59:25 +0000 Subject: [issue22166] test_codecs leaks references In-Reply-To: <1407444567.64.0.0425446064781.issue22166@psf.upfronthosting.co.za> Message-ID: <1409623165.57.0.0216364508418.issue22166@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > We should maybe enhance the codecs API to be able to unregister a codec? That would be nice. At least as a private API in 3.4. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 04:37:57 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 02 Sep 2014 02:37:57 +0000 Subject: [issue22323] Rewrite PyUnicode_AsWideChar() and PyUnicode_AsWideCharString() In-Reply-To: <1409607134.14.0.210351686888.issue22323@psf.upfronthosting.co.za> Message-ID: <1409625477.88.0.0899245352631.issue22323@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Attached patch implements this. There is no patch. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 06:09:32 2014 From: report at bugs.python.org (John Malmberg) Date: Tue, 02 Sep 2014 04:09:32 +0000 Subject: [issue22038] Implement atomic operations on non-x86 platforms In-Reply-To: <1406049852.33.0.466915172772.issue22038@psf.upfronthosting.co.za> Message-ID: <1409630972.78.0.0705086554126.issue22038@psf.upfronthosting.co.za> Changes by John Malmberg : ---------- nosy: +John.Malmberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 08:15:27 2014 From: report at bugs.python.org (Rebecka) Date: Tue, 02 Sep 2014 06:15:27 +0000 Subject: [issue22296] cookielib uses time.time(), making incorrect checks of expiration times in cookies In-Reply-To: <1409306450.24.0.723741077293.issue22296@psf.upfronthosting.co.za> Message-ID: <1409638527.29.0.749640138113.issue22296@psf.upfronthosting.co.za> Rebecka added the comment: Akira is correct: using time.mktime to produce the expiration date for the cookie is wrong (thank you very much for the pointers!). Using e.g. http.cookiejar.http2time with a HTTP formatted date string gives a correct time stamp (with which cookie.is_expired succeeds), so this was not a bug (just user error...). ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 09:02:29 2014 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 02 Sep 2014 07:02:29 +0000 Subject: [issue22166] test_codecs leaks references In-Reply-To: <1407444567.64.0.0425446064781.issue22166@psf.upfronthosting.co.za> Message-ID: <1409641349.58.0.654471798243.issue22166@psf.upfronthosting.co.za> Nick Coghlan added the comment: Yeah, the unique name was a hack to deal with the fact I couldn't unregister anything. As a simpler short term fix for the reference leak, perhaps it would be worth trying a call to "traceback.clear_frames(caught)" as a new final line in ExceptionChainingTest.assertWrapped? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 09:13:12 2014 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 02 Sep 2014 07:13:12 +0000 Subject: [issue19826] Document that bug reporting by email is possible In-Reply-To: <1385668245.52.0.0107396832211.issue19826@psf.upfronthosting.co.za> Message-ID: <1409641992.65.0.218802592028.issue19826@psf.upfronthosting.co.za> Mark Lawrence added the comment: I agree with David, I've noticed several messages recently that are mostly untrimmed replies to email so essentially have no actual content. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 09:22:16 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 02 Sep 2014 07:22:16 +0000 Subject: [issue22296] cookielib uses time.time(), making incorrect checks of expiration times in cookies In-Reply-To: <1409306450.24.0.723741077293.issue22296@psf.upfronthosting.co.za> Message-ID: <1409642536.4.0.700828140374.issue22296@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: needs patch -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 09:52:30 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 02 Sep 2014 07:52:30 +0000 Subject: [issue22323] Rewrite PyUnicode_AsWideChar() and PyUnicode_AsWideCharString() In-Reply-To: <1409607134.14.0.210351686888.issue22323@psf.upfronthosting.co.za> Message-ID: <1409644350.34.0.322377003458.issue22323@psf.upfronthosting.co.za> STINNER Victor added the comment: > There is no patch. You're right. Here it is. ---------- keywords: +patch Added file: http://bugs.python.org/file36527/unicode_aswidechar.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 09:53:08 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 02 Sep 2014 07:53:08 +0000 Subject: [issue22258] set_inheritable(): ioctl(FIOCLEX) is available but fails with ENOTTY on Illumos In-Reply-To: <1408800024.14.0.0329688839383.issue22258@psf.upfronthosting.co.za> Message-ID: <1409644388.0.0.750644977661.issue22258@psf.upfronthosting.co.za> STINNER Victor added the comment: Ping Igor. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 10:22:51 2014 From: report at bugs.python.org (Elizabeth Myers) Date: Tue, 02 Sep 2014 08:22:51 +0000 Subject: [issue6331] Add unicode script info to the unicode database In-Reply-To: <1245790259.44.0.08771310344.issue6331@psf.upfronthosting.co.za> Message-ID: <1409646171.59.0.246904085475.issue6331@psf.upfronthosting.co.za> Elizabeth Myers added the comment: > I think this needs to be fixed, then - we need to study why there are > so many new records (e.g. what script contributes most new records), > and then look for alternatives. The "Common" script appears to be very fragmented and may be the cause of the issues. > One alternative could be to create a separate Trie for scripts. Not having seen the one in C yet, I have one written in Python, custom-made for storing the script database, based on the general idea of a range tree. It stores ranges individually straight out of Scripts.txt. The general idea is you take the average of the lower and upper bounds of a given range (they can be equal). When searching, you compare the codepoint value to the average in the present node, and use that to find which direction to search the tree in. Without coalescing neighbouring ranges that are the same script, I have 1,606 nodes in the tree (for Unicode 7.0, which added a lot of scripts). After coalescing, there appear to be 806 nodes. If anyone cares, I'll be more than happy to post code for inspection. > I don't know what this will be used for, but one application is > certainly regular expressions. So we need an efficient test whether > the character is in the expected script or not. It would be bad if > such a test would have to do a .lower() on each lookup. This is actually required for restriction-level detection as described in Unicode TR39, for all levels of restriction above ASCII-only (http://www.unicode.org/reports/tr39/#Restriction_Level_Detection). ---------- nosy: +Elizacat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 10:38:33 2014 From: report at bugs.python.org (Igor Pashev) Date: Tue, 02 Sep 2014 08:38:33 +0000 Subject: [issue22258] set_inheritable(): ioctl(FIOCLEX) is available but fails with ENOTTY on Illumos In-Reply-To: <1408800024.14.0.0329688839383.issue22258@psf.upfronthosting.co.za> Message-ID: <1409647113.75.0.0645554508719.issue22258@psf.upfronthosting.co.za> Igor Pashev added the comment: Yes, Victor. Your patch works. All os tests are passed :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 11:50:08 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 02 Sep 2014 09:50:08 +0000 Subject: [issue22258] set_inheritable(): ioctl(FIOCLEX) is available but fails with ENOTTY on Illumos In-Reply-To: <1408800024.14.0.0329688839383.issue22258@psf.upfronthosting.co.za> Message-ID: <3hnNmv39zWz7LjM@mail.python.org> Roundup Robot added the comment: New changeset 27cef7476f2b by Victor Stinner in branch '3.4': Closes #22258: Fix the the internal function set_inheritable() on Illumos. http://hg.python.org/cpython/rev/27cef7476f2b New changeset 4a51c45f405b by Victor Stinner in branch 'default': (Merge 3.4) Closes #22258: Fix the the internal function set_inheritable() on http://hg.python.org/cpython/rev/4a51c45f405b ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 11:50:57 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 02 Sep 2014 09:50:57 +0000 Subject: [issue22258] set_inheritable(): ioctl(FIOCLEX) is available but fails with ENOTTY on Illumos In-Reply-To: <1408800024.14.0.0329688839383.issue22258@psf.upfronthosting.co.za> Message-ID: <1409651457.92.0.514181524201.issue22258@psf.upfronthosting.co.za> STINNER Victor added the comment: > Yes, Victor. Your patch works. All os tests are passed :-) Thanks for the tests. I pushed my fix to Python 3.4 & 3.5. ---------- stage: resolved -> versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 12:03:47 2014 From: report at bugs.python.org (Constantino Antunes) Date: Tue, 02 Sep 2014 10:03:47 +0000 Subject: [issue22325] wrong subtraction result Message-ID: <1409652227.24.0.50311509349.issue22325@psf.upfronthosting.co.za> New submission from Constantino Antunes: I was using python as my calculator when I got a result which had to be rounded to be the value I expected. So I made some tests with a simple case. Given that 0.38 - 0.20 = 0.18, then 1000.38 - 1000.20 should be also 0.18. Here is this calculation done on three different systems: Python 2.7.5 (default, Mar 9 2014, 22:15:05) [GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> 0.38 - 0.20 0.18 >>> test = lambda x: (x+0.38) - (x+0.20) >>> test(0) 0.18 >>> test(1000) 0.17999999999994998 >>> test(1000000) 0.18000000005122274 >>> test(1000000000) 0.1799999475479126 >>> test(1000000000000) 0.1800537109375 >>> test(1000000000000000) 0.125 --- Python 2.7.3 (default, Mar 13 2014, 11:03:55) [GCC 4.7.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> 0.38 - 0.20 0.18 >>> test = lambda x: (x+0.38) - (x+0.20) >>> test(0) 0.18 >>> test(1000) 0.17999999999994998 >>> test(1000000000000000) 0.125 --- Python 2.4.3 (#1, Oct 23 2012, 22:02:41) [GCC 4.1.2 20080704 (Red Hat 4.1.2-54)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> 0.38 - 0.20 0.17999999999999999 >>> test = lambda x: (x+0.38) - (x+0.20) >>> test(0) 0.17999999999999999 >>> test(1000) 0.17999999999994998 >>> test(1000000000000000) 0.125 ---------- messages: 226270 nosy: Constantino.Antunes priority: normal severity: normal status: open title: wrong subtraction result versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 14:00:06 2014 From: report at bugs.python.org (Frank Thommen) Date: Tue, 02 Sep 2014 12:00:06 +0000 Subject: [issue22326] tempfile.TemporaryFile fails on NFS v4 filesystems Message-ID: <1409659206.56.0.836891924559.issue22326@psf.upfronthosting.co.za> New submission from Frank Thommen: Hi, tempfile.TemporaryFile fails on NFS v4 filesystems. Assume the following mounts: $ mount [...] psi:/volumes/vol1 on /mnt/nfsv4 type nfs4 (rw,addr=xx.xx.xx.xx) psi:/volumes/vol1 on /mnt/nfsv3 type nfs (rw,addr=xx.xx.xx.xx) [...] $ and the following script "testtmpfile.py": --------------- #! env python import tempfile def _is_writable_dir_unnamed(p): try: t = tempfile.TemporaryFile(dir=p) t.write('1') t.close() except OSError: return False else: return True def _is_writable_dir_named(p): try: t = tempfile.NamedTemporaryFile(dir=p) t.write('1') t.close() except OSError: return False else: return True if not _is_writable_dir_unnamed("."): print "(unnamed) . is not writable" else: print "(unnamed) OK" if not _is_writable_dir_named("."): print "(named) . is not writable" else: print "(named) OK" --------------- Then you'll find the following behaviour: $ pwd /mnt/nfsv4 $ /g/software/bin/python-2.7 /tmp/testtmpfile.py (unnamed) . is not writable (named) OK $ $ pwd /mnt/nfsv3 $ /g/software/bin/python-2.7 /tmp/testtmpfile.py (unnamed) OK (named) OK $ Additionally in the failing case, a - writable - temporary file named "tmp*" is left in the directory. Observed on CentOS 5.10 with kernel 2.6.18-371.11.1.el5 and on CentOS 6.5 with kernel 2.6.32-431.23.3.el6.x86_64. The problem appears with Python 2.4, 2.6 and 2.7. Cheers frank ---------- messages: 226271 nosy: drosera priority: normal severity: normal status: open title: tempfile.TemporaryFile fails on NFS v4 filesystems versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 14:36:32 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 02 Sep 2014 12:36:32 +0000 Subject: [issue22325] wrong subtraction result In-Reply-To: <1409652227.24.0.50311509349.issue22325@psf.upfronthosting.co.za> Message-ID: <1409661392.52.0.625933211971.issue22325@psf.upfronthosting.co.za> R. David Murray added the comment: https://docs.python.org/2/tutorial/floatingpoint.html ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 14:39:58 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 02 Sep 2014 12:39:58 +0000 Subject: [issue22326] tempfile.TemporaryFile fails on NFS v4 filesystems In-Reply-To: <1409659206.56.0.836891924559.issue22326@psf.upfronthosting.co.za> Message-ID: <1409661598.86.0.76505743649.issue22326@psf.upfronthosting.co.za> R. David Murray added the comment: What is the actual OSError raised? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 15:00:41 2014 From: report at bugs.python.org (Claudiu Popa) Date: Tue, 02 Sep 2014 13:00:41 +0000 Subject: [issue10312] intcatcher() can deadlock In-Reply-To: <1288874942.68.0.464773855859.issue10312@psf.upfronthosting.co.za> Message-ID: <1409662841.72.0.220575990399.issue10312@psf.upfronthosting.co.za> Changes by Claudiu Popa : ---------- nosy: -Claudiu.Popa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 15:59:36 2014 From: report at bugs.python.org (Saimadhav Heblikar) Date: Tue, 02 Sep 2014 13:59:36 +0000 Subject: [issue18766] IDLE: Autocomplete in editor doesn't work for un-imported modules In-Reply-To: <1376703586.47.0.0617094548794.issue18766@psf.upfronthosting.co.za> Message-ID: <1409666376.16.0.0109632593057.issue18766@psf.upfronthosting.co.za> Changes by Saimadhav Heblikar : ---------- nosy: +sahutd _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 16:03:35 2014 From: report at bugs.python.org (Brett Cannon) Date: Tue, 02 Sep 2014 14:03:35 +0000 Subject: [issue19826] Document that bug reporting by email is possible In-Reply-To: <1385668245.52.0.0107396832211.issue19826@psf.upfronthosting.co.za> Message-ID: <1409666615.75.0.25477132053.issue19826@psf.upfronthosting.co.za> Brett Cannon added the comment: And I agree with David and Mark. Thanks for the attempt at a patch, Mike, but in hindsight we are going to have to turn down your contribution. ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 16:17:13 2014 From: report at bugs.python.org (Frank Thommen) Date: Tue, 02 Sep 2014 14:17:13 +0000 Subject: [issue22326] tempfile.TemporaryFile fails on NFS v4 filesystems In-Reply-To: <1409659206.56.0.836891924559.issue22326@psf.upfronthosting.co.za> Message-ID: <1409667433.26.0.0485535277456.issue22326@psf.upfronthosting.co.za> Frank Thommen added the comment: errno: 5 strerror: Input/output error ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 16:22:47 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 02 Sep 2014 14:22:47 +0000 Subject: [issue19826] Document that bug reporting by email is possible In-Reply-To: <1385668245.52.0.0107396832211.issue19826@psf.upfronthosting.co.za> Message-ID: <1409667767.01.0.441470478651.issue19826@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: needs patch -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 16:23:55 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 02 Sep 2014 14:23:55 +0000 Subject: [issue22326] tempfile.TemporaryFile fails on NFS v4 filesystems In-Reply-To: <1409659206.56.0.836891924559.issue22326@psf.upfronthosting.co.za> Message-ID: <1409667835.0.0.194294501837.issue22326@psf.upfronthosting.co.za> STINNER Victor added the comment: I tried on my Fedora 20 (Linux, kernel 3.14.8-200.fc20.x86_64) and I'm unable to reproduce the issue. $ sudo mkdir /test $ sudo chown haypo: /test $ echo "/test *(rw)" >> /etc/exports $ sudo exportfs -af $ sudo mount -t nfs localhost:/test nfs $ cat > x.py $ python x.py (unnamed) OK (named) OK $ mount|grep nfs localhost:/test on /home/haypo/nfs type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp6,port=0,timeo=600,retrans=2,sec=sys,clientaddr=::1,local_lock=none,addr=::1) $ python -V Python 2.7.5 ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 17:20:03 2014 From: report at bugs.python.org (Frank Thommen) Date: Tue, 02 Sep 2014 15:20:03 +0000 Subject: [issue22326] tempfile.TemporaryFile fails on NFS v4 filesystems In-Reply-To: <1409659206.56.0.836891924559.issue22326@psf.upfronthosting.co.za> Message-ID: <1409671203.01.0.476762619907.issue22326@psf.upfronthosting.co.za> Frank Thommen added the comment: Agreed. If I export from CentOS and mount on CentOS (local or remote) it seems to work. So this is probably due to our specific fileserver setup or a problem of the underlying filesystem (zfs). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 19:39:27 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 02 Sep 2014 17:39:27 +0000 Subject: [issue21527] concurrent.futures.ThreadPoolExecutor does not use a default value In-Reply-To: <1400453267.44.0.909455514702.issue21527@psf.upfronthosting.co.za> Message-ID: <3hnbBQ5k0wz7LjM@mail.python.org> Roundup Robot added the comment: New changeset 2805b0dca798 by Guido van Rossum in branch 'default': Closes #21527: Add default number of workers to ThreadPoolExecutor. (Claudiu Popa.) http://hg.python.org/cpython/rev/2805b0dca798 ---------- nosy: +python-dev resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 20:29:44 2014 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Tue, 02 Sep 2014 18:29:44 +0000 Subject: [issue22253] ConfigParser does not handle files without sections In-Reply-To: <1408731768.17.0.221948826268.issue22253@psf.upfronthosting.co.za> Message-ID: <1409682584.24.0.270145587578.issue22253@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 22:25:03 2014 From: report at bugs.python.org (Oliver Smith) Date: Tue, 02 Sep 2014 20:25:03 +0000 Subject: [issue9694] argparse required arguments displayed under "optional arguments" In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za> Message-ID: <1409689502.97.0.987534998228.issue9694@psf.upfronthosting.co.za> Oliver Smith added the comment: The term "optional arguments" is a poorly formed adjectival suffix of "option". What it's trying to say is "these are kwargs" rather than "these arguments are not compulsory". I ran into this issue with 3.4 and was looking to file a simple change request: In early DOS/Linux days we called these "switches". I suggest we simply change the default wording from "optional arguments" to "switches". ---------- nosy: +Oliver.Smith Added file: http://bugs.python.org/file36528/parrot.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 22:40:31 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 02 Sep 2014 20:40:31 +0000 Subject: [issue22327] test_gdb failures on Ubuntu 14.10 Message-ID: <1409690431.38.0.272932349651.issue22327@psf.upfronthosting.co.za> New submission from Barry A. Warsaw: Lots of them, just like this: ====================================================================== FAIL: test_NULL_ob_type (test.test_gdb.PrettyPrintTests) Ensure that a PyObject* with NULL ob_type is handled gracefully ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/barry/projects/python/cpython/Lib/test/test_gdb.py", line 449, in test_NULL_ob_type 'set v->ob_type=0') File "/home/barry/projects/python/cpython/Lib/test/test_gdb.py", line 420, in assertSane cmds_after_breakpoint=cmds_after_breakpoint) File "/home/barry/projects/python/cpython/Lib/test/test_gdb.py", line 206, in get_gdb_repr import_site=import_site) File "/home/barry/projects/python/cpython/Lib/test/test_gdb.py", line 184, in get_stack_trace self.assertEqual(unexpected_errlines, []) AssertionError: Lists differ: ["Got object file from memory but can't read symbols: File truncated."] != [] First list contains 1 additional elements. First extra element 0: Got object file from memory but can't read symbols: File truncated. - ["Got object file from memory but can't read symbols: File truncated."] + [] ---------- components: Tests messages: 226280 nosy: barry priority: normal severity: normal status: open title: test_gdb failures on Ubuntu 14.10 versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 22:54:48 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 02 Sep 2014 20:54:48 +0000 Subject: [issue22327] test_gdb failures on Ubuntu 14.10 In-Reply-To: <1409690431.38.0.272932349651.issue22327@psf.upfronthosting.co.za> Message-ID: <1409691288.56.0.598130521393.issue22327@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 22:55:18 2014 From: report at bugs.python.org (Markus Unterwaditzer) Date: Tue, 02 Sep 2014 20:55:18 +0000 Subject: [issue22328] ur'foo\d' raises SyntaxError Message-ID: <1409691318.67.0.463109559126.issue22328@psf.upfronthosting.co.za> New submission from Markus Unterwaditzer: The string literal `ur'foo\d'` causes a SyntaxError while the equivalent `r'foo\d'` causes the correct string to be produced. ---------- components: Interpreter Core messages: 226281 nosy: untitaker priority: normal severity: normal status: open title: ur'foo\d' raises SyntaxError type: behavior versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 22:59:57 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 02 Sep 2014 20:59:57 +0000 Subject: [issue22328] ur'foo\d' raises SyntaxError In-Reply-To: <1409691318.67.0.463109559126.issue22328@psf.upfronthosting.co.za> Message-ID: <1409691597.03.0.772452705661.issue22328@psf.upfronthosting.co.za> R. David Murray added the comment: This is a conscious design decision. See issue 15096. ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed superseder: -> Drop support for the "ur" string prefix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 23:01:56 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 02 Sep 2014 21:01:56 +0000 Subject: [issue22043] Use a monotonic clock to compute timeouts In-Reply-To: <1406081401.66.0.461602325424.issue22043@psf.upfronthosting.co.za> Message-ID: <3hngh41SHsz7LjY@mail.python.org> Roundup Robot added the comment: New changeset 330bd57685fc by Victor Stinner in branch 'default': Issue #22043: Fix _PyTime_gettimeofday() if HAVE_GETTIMEOFDAY http://hg.python.org/cpython/rev/330bd57685fc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 23:26:16 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 02 Sep 2014 21:26:16 +0000 Subject: [issue22043] Use a monotonic clock to compute timeouts In-Reply-To: <1406081401.66.0.461602325424.issue22043@psf.upfronthosting.co.za> Message-ID: <3hnhD74btgz7LjR@mail.python.org> Roundup Robot added the comment: New changeset b12857782041 by Victor Stinner in branch 'default': Issue #22043: time.monotonic() is now always available http://hg.python.org/cpython/rev/b12857782041 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 23:37:41 2014 From: report at bugs.python.org (Danek Duvall) Date: Tue, 02 Sep 2014 21:37:41 +0000 Subject: [issue7918] distutils always ignores byte compilation errors In-Reply-To: <1265995747.45.0.532654407664.issue7918@psf.upfronthosting.co.za> Message-ID: <1409693861.55.0.327601163912.issue7918@psf.upfronthosting.co.za> Changes by Danek Duvall : ---------- nosy: +dhduvall _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 2 23:55:58 2014 From: report at bugs.python.org (Danek Duvall) Date: Tue, 02 Sep 2014 21:55:58 +0000 Subject: [issue7918] distutils always ignores byte compilation errors In-Reply-To: <1265995747.45.0.532654407664.issue7918@psf.upfronthosting.co.za> Message-ID: <1409694958.33.0.596936536324.issue7918@psf.upfronthosting.co.za> Danek Duvall added the comment: As a distribution maintainer of several Python modules, I've run into this bug twice in the past week. In each case, the python file in question had a SyntaxError and failed to compile, but the error just scrolled past in a large log and was missed because no failure occurred until we attempted to package the result, and the .pyc files were missing. While we managed to track the problem down fairly easily in both cases, if we only had folks working on the problem that didn't have lots of experience in tracking down build issues, this could have wasted a lot of otherwise valuable engineering time. I understand the desire to be able to package files that fail to compile, but having that be the default seems to me like it fails basic expectations, even given how long this bug has been around. I can't imagine that the number of deliberately-broken python files is particularly large compared to the number of python files that might get broken accidentally (or files that are "broken" for one version of python but not another) and so being required to maintain an exception list doesn't seem unreasonable. (Neither does some amount of transition period -- one or two minor releases of Python? -- between the introduction of the mechanism and the change of the default.) Would people be interested in a patch to that effect? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 00:11:38 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 02 Sep 2014 22:11:38 +0000 Subject: [issue9694] argparse required arguments displayed under "optional arguments" In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za> Message-ID: <1409695898.1.0.476319057241.issue9694@psf.upfronthosting.co.za> Terry J. Reedy added the comment: To me, the mistake is contrasting 'positional' versus 'optional'. The proper contrasts are 'positional' versus 'named' or 'keyword' -- I believe these are mutually exclusive for command lines -- and 'required' versus 'optional. The two axes (contrasts) are orthogonal. Where are optional positional parameters listed? If, as I presume, they are listed as 'positional' and given that all keyword arguments are already listed in the so-called 'optional' section, I think we should regard 'optional' as a misspelling of 'keyword'. That is a word already familiar to python programmers. The change should only be made in default for the same reason we do not correct minor errors in exception messages in bugfix releases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 00:16:20 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 02 Sep 2014 22:16:20 +0000 Subject: [issue7918] distutils always ignores byte compilation errors In-Reply-To: <1265995747.45.0.532654407664.issue7918@psf.upfronthosting.co.za> Message-ID: <1409696180.74.0.0130544181023.issue7918@psf.upfronthosting.co.za> ?ric Araujo added the comment: Again, I think this behaviour was a deliberate decision, not a patch. Developers should use tests to detect syntax errors in their code, not rely on distutils byte compilation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 00:16:37 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 02 Sep 2014 22:16:37 +0000 Subject: [issue7918] distutils always ignores byte compilation errors In-Reply-To: <1265995747.45.0.532654407664.issue7918@psf.upfronthosting.co.za> Message-ID: <1409696197.51.0.88414386012.issue7918@psf.upfronthosting.co.za> ?ric Araujo added the comment: a deliberate decision, not a bug* ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 00:47:26 2014 From: report at bugs.python.org (Danek Duvall) Date: Tue, 02 Sep 2014 22:47:26 +0000 Subject: [issue7918] distutils always ignores byte compilation errors In-Reply-To: <1265995747.45.0.532654407664.issue7918@psf.upfronthosting.co.za> Message-ID: <1409698046.94.0.26489698223.issue7918@psf.upfronthosting.co.za> Danek Duvall added the comment: Absolutely true that developers should have tests that would detect such bugs. However, the sooner you detect a bug, the more time you save. And by the time it reaches someone like me, who is just packaging up the module for distribution with an OS, it's just going to waste my time, too, with less benefit (because I'm still not going to have much of an incentive to write tests). Imagine if your C compiler only warned about code that wouldn't compile, and failed to produce the corresponding .o file without erroring out, and the linker failed to error out when that .o file was missing, and that you only noticed the problem when you ran your tests (or, if you're just shipping someone else's code, when your customer calls you to complain). Wouldn't you think that was stunningly broken? Again, I get that there are use cases for having broken code pass through unscathed, but it seems very odd to me (as someone with a long unix background) that this would have been a conscious default. Now that it is the default, I understand the need for caution, but caution needn't (and shouldn't) prevent bugs from getting fixed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 01:29:40 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 02 Sep 2014 23:29:40 +0000 Subject: [issue9694] argparse required arguments displayed under "optional arguments" In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za> Message-ID: <1409700580.7.0.427260047855.issue9694@psf.upfronthosting.co.za> R. David Murray added the comment: In unix parlance, they are arguments and options (or, sometimes, flags). And then required or not required. So, argparse follows unix precedent here, except that it calls them "optional arguments", because everything is added via add_argument. Which is why I suggested changing the label to just 'options'. But I could see using 'switches' instead, that's less ambiguous, and is the term used on Windows (albeit with a different standard syntax). However, every unix man page uses the term 'options'. I definitely think 'keywords' is not a good idea. That's crossing the streams (python parlance versus shell parlance). argparse is building a bridge to the shell world, and should use its terminology for the bits of shell stuff it is implementing...most especially in the default help display. Note that, reading the issue history, the argparse maintainer is urging a doc change only (how to fix the help if you run into this issue), not a behavior change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 02:26:08 2014 From: report at bugs.python.org (Llelan D.) Date: Wed, 03 Sep 2014 00:26:08 +0000 Subject: [issue22329] Windows installer can't recover partially installed state Message-ID: <1409703967.84.0.334306520264.issue22329@psf.upfronthosting.co.za> New submission from Llelan D.: Python v3.4.1 x64 on Windows 7 x64. If the python installation directory is deleted, the installer can not remove, change, or repair the installation. When I run the python-3.4.1.amd64.msi installer and choose Remove, it gives me a dialog saying a required file is missing about halfway through. It gives me no clue as to what this file is. If I choose Repair, it gives me a dialog saying "The specified account already exists" about halfway through. Totally cryptic. If I choose Change and either select that all features or no features will be installed, it gives me a dialog saying "The specified account already exists" about halfway through. It turns out that the installer is relying on both files in the installation directory and a Windows Intaller key. If the required files are missing, the installer refuses to either remove or repair. If the Windows Installer key still exists, the installer refuses to re-install. When this key is removed, an install can then be done. To be safe, a remove should then be done to clear up any problems and then another clean install. Both of these requirement violate good MSI practice. You are *NEVER* to use a Windows Installer key as an indication of the installed state because that list can be, and often is, easily corrupted. The installer should always be able to perform a complete repair and especially remove without requiring *ANY* installed files or registry keys. This installer desperately needs a complete re-write. It should use its own key to indicate whether the application is installed but should not depend on it in case of a partially installed/removed state, should not require any installed file or registry key to fully repair or remove the application, should be able to re-install no matter the state of a previous installation, and should query the user if any information required is missing from the installation or registry. In other words, the normal MSI installer guidelines. ---------- components: Installation messages: 226291 nosy: LlelanD, steve.dower priority: normal severity: normal status: open title: Windows installer can't recover partially installed state type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 02:44:36 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 03 Sep 2014 00:44:36 +0000 Subject: [issue22327] test_gdb failures on Ubuntu 14.10 In-Reply-To: <1409690431.38.0.272932349651.issue22327@psf.upfronthosting.co.za> Message-ID: <1409705076.36.0.684382804973.issue22327@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +dmalcolm _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 04:01:19 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 03 Sep 2014 02:01:19 +0000 Subject: [issue22329] Windows installer can't recover partially installed state In-Reply-To: <1409703967.84.0.334306520264.issue22329@psf.upfronthosting.co.za> Message-ID: <1409709679.58.0.653249192833.issue22329@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I and at least one other person reporting on python-list have had similar problems trying to update an installation. ---------- nosy: +terry.reedy stage: -> needs patch versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 04:44:07 2014 From: report at bugs.python.org (Steve Dower) Date: Wed, 03 Sep 2014 02:44:07 +0000 Subject: [issue22329] Windows installer can't recover partially installed state In-Reply-To: <1409703967.84.0.334306520264.issue22329@psf.upfronthosting.co.za> Message-ID: <1409712247.88.0.231821248747.issue22329@psf.upfronthosting.co.za> Steve Dower added the comment: I've been working on the rewrite for 3.5 already (progress at http://hg.python.org/sandbox/steve.dower) - redoing the installer completely was one of the conditions for when I signed on to own it. Martin is still responsible for 3.4, and I'm building 2.7 as required but not working on the installer at all. If this bug needs to be fixed in 3.4, it should be assigned to Martin. Otherwise, if it only needs to be fixed in 3.5, it can be assigned to me and I'll (try and) remember to make this scenario work. (Basically, uninstall may need to reinstall some files - this is probably the uninstall step for pip, but I'm not 100% sure.) To find out exactly what isn't working, you should be able to run the following command: msiexec /l*vx log.txt /x {D54842CB-F761-30BA-881F-1FF821DC44DF} log.txt can be a full path to any location - the UUID is the product code for 3.4.1 x64. You can attach it here and I'll take a look, or you can check it yourself for the error. Either way, I don't intend to fix it for 3.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 08:43:04 2014 From: report at bugs.python.org (Stefan Behnel) Date: Wed, 03 Sep 2014 06:43:04 +0000 Subject: [issue15237] Add capsule API to _decimal In-Reply-To: <1341136971.24.0.846129884923.issue15237@psf.upfronthosting.co.za> Message-ID: <1409726584.98.0.904206188285.issue15237@psf.upfronthosting.co.za> Stefan Behnel added the comment: Is this superseded by issue 22194 now or the other way round? ---------- nosy: +scoder versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 08:44:07 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 03 Sep 2014 06:44:07 +0000 Subject: [issue22324] Use PyUnicode_AsWideCharString() instead of PyUnicode_AsUnicode() In-Reply-To: <1409611190.39.0.820072774539.issue22324@psf.upfronthosting.co.za> Message-ID: <1409726647.48.0.773163801186.issue22324@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Will not this cause performance regression? When we hardly work with wchar_t-based API, it looks good to cache encoded value. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 08:45:13 2014 From: report at bugs.python.org (Stefan Behnel) Date: Wed, 03 Sep 2014 06:45:13 +0000 Subject: [issue7946] Convoy effect with I/O bound threads and New GIL In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za> Message-ID: <1409726713.6.0.714590364375.issue7946@psf.upfronthosting.co.za> Changes by Stefan Behnel : ---------- nosy: +scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 08:47:48 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 03 Sep 2014 06:47:48 +0000 Subject: [issue22271] Deprecate PyUnicode_AsUnicode(): emit a DeprecationWarning In-Reply-To: <1408930876.51.0.0157656751737.issue22271@psf.upfronthosting.co.za> Message-ID: <1409726868.02.0.929282191288.issue22271@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It would be better to emit a warning only at compile time. End user of compiled extension can't do anything with a warning emitted at run time, only its author can avoid it. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 09:03:36 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 03 Sep 2014 07:03:36 +0000 Subject: [issue22271] Deprecate PyUnicode_AsUnicode(): emit a DeprecationWarning In-Reply-To: <1408930876.51.0.0157656751737.issue22271@psf.upfronthosting.co.za> Message-ID: <1409727816.97.0.893682074853.issue22271@psf.upfronthosting.co.za> STINNER Victor added the comment: > It would be better to emit a warning only at compile time. End user of compiled extension can't do anything with a warning emitted at run time, only its author can avoid it. DeprecatedWarning warnings are silent by default. So it will not annoy users. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 09:10:36 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 03 Sep 2014 07:10:36 +0000 Subject: [issue22324] Use PyUnicode_AsWideCharString() instead of PyUnicode_AsUnicode() In-Reply-To: <1409611190.39.0.820072774539.issue22324@psf.upfronthosting.co.za> Message-ID: <1409728236.26.0.3865327258.issue22324@psf.upfronthosting.co.za> STINNER Victor added the comment: > Will not this cause performance regression? When we hardly work with wchar_t-based API, it looks good to cache encoded value. Yes, it will be slower. But I prefer slower code with a lower memory footprint. On UNIX, I don't think that anyone will notice the difference. My concern is that the cache is never released. If the conversion is only needed once at startup, the memory will stay until Python exits. It's not really efficient. On Windows, conversion to wchar_t* is common because Python uses the Windows wide character API ("W" API vs "A" ANSI code page API). For example, most access to the filesystem use wchar_t* type. On Python < 3.3, Python was compiled in narrow mode and so Unicode was already using wchar_t* internally to store characters. Since Python 3.3, Python uses a more compact representation. wchar_t* shares Unicode data only if sizeof(wchar_t*) == KIND where KIND is 1, 2 or 4 bytes per character. Examples: "\u20ac" on Windows (16 bits wchar_t) or "\U0010ffff" on Linux (32 bits wchar_t) . ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 09:32:41 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 03 Sep 2014 07:32:41 +0000 Subject: [issue22194] access to cdecimal / libmpdec API In-Reply-To: <1408022998.0.0.480794879626.issue22194@psf.upfronthosting.co.za> Message-ID: <1409729561.56.0.330617911725.issue22194@psf.upfronthosting.co.za> Larry Hastings added the comment: I think this is a duplicate of #15237. ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 09:32:51 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 03 Sep 2014 07:32:51 +0000 Subject: [issue15237] Add capsule API to _decimal In-Reply-To: <1341136971.24.0.846129884923.issue15237@psf.upfronthosting.co.za> Message-ID: <1409729571.45.0.481795218331.issue15237@psf.upfronthosting.co.za> Larry Hastings added the comment: I think #22194 is a duplicate issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 09:44:06 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 03 Sep 2014 07:44:06 +0000 Subject: [issue22043] Use a monotonic clock to compute timeouts In-Reply-To: <1406081401.66.0.461602325424.issue22043@psf.upfronthosting.co.za> Message-ID: <3hnxx12hnHz7LjQ@mail.python.org> Roundup Robot added the comment: New changeset 9deef14393d5 by Victor Stinner in branch 'default': Issue #22043: Fix pymonotonic(), use tv_usec=-1 as a marker to skip http://hg.python.org/cpython/rev/9deef14393d5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 09:59:00 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 03 Sep 2014 07:59:00 +0000 Subject: [issue22043] Use a monotonic clock to compute timeouts In-Reply-To: <1406081401.66.0.461602325424.issue22043@psf.upfronthosting.co.za> Message-ID: <1409731140.35.0.549333281295.issue22043@psf.upfronthosting.co.za> STINNER Victor added the comment: Thanks for the review Antoine. I pushed the new version pymonotonic-4.patch with a minor change: in debug mode, pymonotonic() also ensures that the clock never goes backward! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 11:04:29 2014 From: report at bugs.python.org (Masahiro Konishi) Date: Wed, 03 Sep 2014 09:04:29 +0000 Subject: [issue22330] PyOS_mystricmp is broken Message-ID: <1409735069.35.0.121112016094.issue22330@psf.upfronthosting.co.za> New submission from Masahiro Konishi: int x = PyOS_mystricmp("foo", "none"); expected: x < 0 actual: x == 0 while (*s1 && (tolower((unsigned)*s1++) == tolower((unsigned)*s2++))) { ; } return (tolower((unsigned)*s1) - tolower((unsigned)*s2)); The while-loop is finished when *s1 != *s2 (ex. *s1 == 'f', *s2 == 'n'), but s1 and s2 already point to next characters (ex. *s1 == 'o', *s2 == 'o'), so PyOS_mystricmp returns difference between these characters. ---------- components: Interpreter Core files: pystrcmp.c.patch keywords: patch messages: 226303 nosy: kakkoko priority: normal severity: normal status: open title: PyOS_mystricmp is broken type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file36529/pystrcmp.c.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 11:07:59 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 03 Sep 2014 09:07:59 +0000 Subject: [issue22194] access to cdecimal / libmpdec API In-Reply-To: <1408022998.0.0.480794879626.issue22194@psf.upfronthosting.co.za> Message-ID: <1409735279.66.0.601043963552.issue22194@psf.upfronthosting.co.za> Stefan Krah added the comment: Well, we have two issues now: 1) Make the _decimal API available via capsule. 2) Make the libmpdec symbols public (i.e. remove "GCC visibility push(hidden)" from Modules/_decimal/libmpdec/mpdecimal.h. The question here is now whether 2) is safe. Note that active symbol hiding has always only worked for gcc (but I think on Windows and AIX the symbols are hidden by default anyway). A third option is to make both the _decimal and libmpdec APIs available via capsule, which is a lot of work (300 functions). Also people would likely want the API to work on 2.7, which would mean that large parts of the cdecimal on PyPI (which uses the incompatible libmpdec-2.3) would need to be rewritten. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 11:08:39 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 03 Sep 2014 09:08:39 +0000 Subject: [issue22330] PyOS_mystricmp is broken In-Reply-To: <1409735069.35.0.121112016094.issue22330@psf.upfronthosting.co.za> Message-ID: <1409735319.13.0.439093704437.issue22330@psf.upfronthosting.co.za> STINNER Victor added the comment: I didn't know PyOS_mystrnicmp() and PyOS_mystricmp() functions! They are not used in Python source code. They are not documented, but they are exported in pystrcmp.h which is included in the main Python.h header. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 11:13:46 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 03 Sep 2014 09:13:46 +0000 Subject: [issue22330] PyOS_mystricmp is broken In-Reply-To: <1409735069.35.0.121112016094.issue22330@psf.upfronthosting.co.za> Message-ID: <1409735626.26.0.22211373468.issue22330@psf.upfronthosting.co.za> Stefan Krah added the comment: Also, they aren't safe with the Turkish "i". ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 11:15:55 2014 From: report at bugs.python.org (Masahiro Konishi) Date: Wed, 03 Sep 2014 09:15:55 +0000 Subject: [issue22330] PyOS_mystricmp is broken In-Reply-To: <1409735069.35.0.121112016094.issue22330@psf.upfronthosting.co.za> Message-ID: <1409735755.32.0.694960538893.issue22330@psf.upfronthosting.co.za> Masahiro Konishi added the comment: You can find PyOS_stricmp from here: https://docs.python.org/3/c-api/conversion.html And PyOS_stricmp is PyOS_mystricmp when MS_WINDOWS is not defined. Include/pystrcmp.h: #ifdef MS_WINDOWS #define PyOS_strnicmp strnicmp #define PyOS_stricmp stricmp #else #define PyOS_strnicmp PyOS_mystrnicmp #define PyOS_stricmp PyOS_mystricmp #endif ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 11:20:49 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 03 Sep 2014 09:20:49 +0000 Subject: [issue22330] PyOS_mystricmp is broken In-Reply-To: <1409735069.35.0.121112016094.issue22330@psf.upfronthosting.co.za> Message-ID: <1409736049.42.0.394726927558.issue22330@psf.upfronthosting.co.za> Stefan Krah added the comment: Unfortunately they seem to be part of the stable ABI (#18603). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 11:38:58 2014 From: report at bugs.python.org (Geoffrey Bache) Date: Wed, 03 Sep 2014 09:38:58 +0000 Subject: [issue15451] PATH is not honored in subprocess.Popen in win32 In-Reply-To: <1343264230.45.0.645552285699.issue15451@psf.upfronthosting.co.za> Message-ID: <1409737138.84.0.133922318966.issue15451@psf.upfronthosting.co.za> Changes by Geoffrey Bache : ---------- nosy: +gjb1002 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 14:20:28 2014 From: report at bugs.python.org (Radu Voicilas) Date: Wed, 03 Sep 2014 12:20:28 +0000 Subject: [issue16038] ftplib: unlimited readline() from connection In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za> Message-ID: <1409746828.37.0.79369226968.issue16038@psf.upfronthosting.co.za> Radu Voicilas added the comment: I'm a little confused about this patch. Please correct me if I'm wrong, but fp.readline([size + 1]) should return a line of length at most size + 1. This means that the check len(line) > size will always be true when reading a line that has a length greater than self.maxline. Also, wouldn't it make more sense to have the line that logs stuff in debugging mode be before raising a LineTooLong exception ? This way you have the option of actually seeing the line. ---------- nosy: +raduv _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 14:54:09 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 03 Sep 2014 12:54:09 +0000 Subject: [issue22194] access to cdecimal / libmpdec API In-Reply-To: <1408022998.0.0.480794879626.issue22194@psf.upfronthosting.co.za> Message-ID: <1409748849.21.0.747442222331.issue22194@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > large parts of the cdecimal on PyPI (which uses the incompatible libmpdec-2.3) would need to be rewritten. Ah, so it has an incompatible ABI? That will complicate things a bit :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 14:56:41 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 03 Sep 2014 12:56:41 +0000 Subject: [issue22194] access to cdecimal / libmpdec API In-Reply-To: <1408022998.0.0.480794879626.issue22194@psf.upfronthosting.co.za> Message-ID: <1409749001.07.0.671246206031.issue22194@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Note that active symbol hiding has always only worked for gcc (but I think on Windows and AIX the symbols are hidden by default anyway). Does it mean a separate Windows and AIX solution should be found? I think if we can't make the mpd symbols available in a cross-platform way, the incentive starts getting much lower :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 18:05:42 2014 From: report at bugs.python.org (Ben Hoyt) Date: Wed, 03 Sep 2014 16:05:42 +0000 Subject: [issue18577] lru_cache enhancement: lru_timestamp helper function In-Reply-To: <1375014771.52.0.855210720887.issue18577@psf.upfronthosting.co.za> Message-ID: <1409760342.36.0.012152331913.issue18577@psf.upfronthosting.co.za> Ben Hoyt added the comment: I really like this idea (and am needing this functionality), but I don't think this API (or implementation) is very nice: 1) It means you have to change your function signature to use the timeout feature. 2) Specifying the interval in minutes seems odd (most similar timeouts in Python are specified in seconds). I would love to see an optional timeout=seconds keyword arg to the lru_cache() decorator, or some other way to support this. Raymond, what do you think would be the simplest way to hook this in? One way I think would be nice (and also support other neat things) is to allow you to specify the dict-like object that's used for the cache (defaults to "dict", of course). So the lru_cache signature would change to: def lru_cache(maxsize=100, typed=False, cache=None): ... >From looking at the source, cache would need to support these methods: get, clear, __setitem__, __contains__, __len__, __delitem__ Would this just work? Or could there be a race condition if __contains__ (key in cache) returned True but then cache.get(key) returned False a bit later? In any case, this seems nice and general to me, and would mean you could implement a simple ExpiringDict() and then pass that as cache=ExpiringDict(expiry_time). Thoughts? ---------- nosy: +benhoyt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 18:33:21 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 03 Sep 2014 16:33:21 +0000 Subject: [issue22194] access to cdecimal / libmpdec API In-Reply-To: <1409748849.21.0.747442222331.issue22194@psf.upfronthosting.co.za> Message-ID: <20140903163320.GB18334@sleipnir.bytereef.org> Stefan Krah added the comment: Antoine Pitrou wrote: > > large parts of the cdecimal on PyPI (which uses the incompatible libmpdec-2.3) would need to be rewritten. > > Ah, so it has an incompatible ABI? That will complicate things a bit :-) Yes, cdecimal on PyPI is slower, has a different ABI, uses libmpdec-2.3, has subtle differences in the context handling, cannot subclass the context, ... ;) I think a common C API for 2.7 is only possible with a real backport. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 18:54:29 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 03 Sep 2014 16:54:29 +0000 Subject: [issue15451] PATH is not honored in subprocess.Popen in win32 In-Reply-To: <1343264230.45.0.645552285699.issue15451@psf.upfronthosting.co.za> Message-ID: <1409763269.45.0.568001182735.issue15451@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 19:00:14 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 03 Sep 2014 17:00:14 +0000 Subject: [issue22194] access to cdecimal / libmpdec API In-Reply-To: <20140903163320.GB18334@sleipnir.bytereef.org> Message-ID: <54074919.9050309@free.fr> Antoine Pitrou added the comment: Le 03/09/2014 18:33, Stefan Krah a ?crit : > > > Yes, cdecimal on PyPI is slower, has a different ABI, uses libmpdec-2.3, > has subtle differences in the context handling, cannot subclass the > context, ... ;) > > I think a common C API for 2.7 is only possible with a real backport. Ok, so let's ignore that and focus on 3.5? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 21:01:48 2014 From: report at bugs.python.org (leonard gerard) Date: Wed, 03 Sep 2014 19:01:48 +0000 Subject: [issue15112] argparse: nargs='*' positional argument doesn't accept any items if preceded by an option and another positional In-Reply-To: <1340165747.87.0.563099760163.issue15112@psf.upfronthosting.co.za> Message-ID: <1409770908.96.0.623690775574.issue15112@psf.upfronthosting.co.za> leonard gerard added the comment: In my opinion this is a bug or it should be explicitly stated in the generated usage help string. ---------- nosy: +leonard.gerard _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 21:02:35 2014 From: report at bugs.python.org (leonard gerard) Date: Wed, 03 Sep 2014 19:02:35 +0000 Subject: [issue15112] argparse: nargs='*' positional argument doesn't accept any items if preceded by an option and another positional In-Reply-To: <1340165747.87.0.563099760163.issue15112@psf.upfronthosting.co.za> Message-ID: <1409770955.32.0.326679416068.issue15112@psf.upfronthosting.co.za> leonard gerard added the comment: It seems that delaying positional argument parsing after all optional arguments are parsed would be clean and robust. My understanding is that optional arguments aren't ambiguous and should be processed first and removed from the arguments. Then the current pattern matching done for positional arguments would work well (in one try). If you think this would be a better patch I can give it a try. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 21:37:18 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 03 Sep 2014 19:37:18 +0000 Subject: [issue22194] access to cdecimal / libmpdec API In-Reply-To: <54074919.9050309@free.fr> Message-ID: <20140903193718.GA20348@sleipnir.bytereef.org> Stefan Krah added the comment: Sure, if there are people who write python3-only C modules (I can't think of one right now). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 22:08:25 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 03 Sep 2014 20:08:25 +0000 Subject: [issue22194] access to cdecimal / libmpdec API In-Reply-To: <1408022998.0.0.480794879626.issue22194@psf.upfronthosting.co.za> Message-ID: <1409774905.9.0.753572929699.issue22194@psf.upfronthosting.co.za> Antoine Pitrou added the comment: If there aren't today, there will be in a few years time, and they'll be glad they can support Python 3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 22:19:00 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 03 Sep 2014 20:19:00 +0000 Subject: [issue21933] Allow the user to change font sizes with the text pane of turtledemo In-Reply-To: <1404746295.5.0.877343308699.issue21933@psf.upfronthosting.co.za> Message-ID: <3hpGh366Brz7LjQ@mail.python.org> Roundup Robot added the comment: New changeset ce14092430b6 by Terry Jan Reedy in branch '3.4': Issue #21933: Users can now change the font size for example code. http://hg.python.org/cpython/rev/ce14092430b6 New changeset e2e0c9f90a81 by Terry Jan Reedy in branch 'default': Issue #21933: Merge with 3.4 http://hg.python.org/cpython/rev/e2e0c9f90a81 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 22:45:33 2014 From: report at bugs.python.org (paul j3) Date: Wed, 03 Sep 2014 20:45:33 +0000 Subject: [issue15112] argparse: nargs='*' positional argument doesn't accept any items if preceded by an option and another positional In-Reply-To: <1340165747.87.0.563099760163.issue15112@psf.upfronthosting.co.za> Message-ID: <1409777133.38.0.891338047077.issue15112@psf.upfronthosting.co.za> paul j3 added the comment: http://bugs.python.org/issue14191 'argparse doesn't allow optionals within positionals' implements a 'parse_intermixed_args()' method, which parses all of the optionals with one pass, followed by a second pass that handles the positionals. It does this by temporarily deactivating the positionals for the first pass. It emulates the optparse behavior (with the added ability to parse positionals). This is too big of a change to ever become the default behavior for argparse. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 22:48:08 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 03 Sep 2014 20:48:08 +0000 Subject: [issue21933] Allow the user to change font sizes with the text pane of turtledemo In-Reply-To: <1404746295.5.0.877343308699.issue21933@psf.upfronthosting.co.za> Message-ID: <1409777288.39.0.865547220961.issue21933@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I refactored the callbacks to eliminate duplication. I had to redo the menu addition to work with the new menu. This works great on Windows. I am confident I did not change the logic, but it would still be good if someone tried font changing again on linux and mac. I am not going to backport this to the 2.7 Demo version, as backporting has always been a nuisance and now the help and menu redesigns have also not been backported. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 22:48:17 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 03 Sep 2014 20:48:17 +0000 Subject: [issue22194] access to cdecimal / libmpdec API In-Reply-To: <1408022998.0.0.480794879626.issue22194@psf.upfronthosting.co.za> Message-ID: <1409777297.85.0.299352965576.issue22194@psf.upfronthosting.co.za> Larry Hastings added the comment: Are there any other modules where the capsule API works in both CPython and PyPy? I thought capsule APIs were decidedly implementation-specific. Not that I'm not for it in theory. But this is some crazy uncharted hyper-compatibility territory we're talking about here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 22:58:14 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 03 Sep 2014 20:58:14 +0000 Subject: [issue22194] access to cdecimal / libmpdec API In-Reply-To: <1408022998.0.0.480794879626.issue22194@psf.upfronthosting.co.za> Message-ID: <1409777894.07.0.526523010178.issue22194@psf.upfronthosting.co.za> Stefan Krah added the comment: The compatibility discussion was for the cdecimal-2.3 package that's hosted on PyPI and used for Python 2.7. IOW, will people use a capsule API that's Python-3 only? Compatibility with pypy would be esoteric indeed. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 22:58:57 2014 From: report at bugs.python.org (paul j3) Date: Wed, 03 Sep 2014 20:58:57 +0000 Subject: [issue11588] Add "necessarily inclusive" groups to argparse In-Reply-To: <1300377092.03.0.159307937388.issue11588@psf.upfronthosting.co.za> Message-ID: <1409777937.18.0.614599529823.issue11588@psf.upfronthosting.co.za> paul j3 added the comment: http://stackoverflow.com/questions/25626109/python-argparse-conditionally-required-arguments asks about implementing a 'conditionally-required-arguments' case in `argparse`. The post-parsing test is simple enough: if args.argument and (args.a is None or args.b is None): # raise argparse error here I believe the clearest and shortest expression using Groups is: p = ArgumentParser(formatter_class=UsageGroupHelpFormatter) g1 = p.add_usage_group(kind='nand', dest='nand1') g1.add_argument('--arg', metavar='C') g11 = g1.add_usage_group(kind='nand', dest='nand2') g11.add_argument('-a') g11.add_argument('-b') The usage is (using !() to mark a 'nand' test): usage: issue25626109.py [-h] !(--arg C & !(-a A & -b B)) This uses a 'nand' group, with a 'not-all' test (False if all its actions are present, True otherwise). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 23:21:54 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 03 Sep 2014 21:21:54 +0000 Subject: [issue21933] Allow the user to change font sizes with the text pane of turtledemo In-Reply-To: <1404746295.5.0.877343308699.issue21933@psf.upfronthosting.co.za> Message-ID: <1409779314.67.0.438985875356.issue21933@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Lita, thank you for sticking with this. #17642 is about doing something similar for Idle. The issue is necessarily more complicated, but what we learned here about system difference and tk behavior oddities will be needed for Idle too. I am making 'what we learned' comments there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 23:31:48 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 03 Sep 2014 21:31:48 +0000 Subject: [issue22331] test_io.test_interrupted_write_text() hangs on the buildbot FreeBSD 7.2 Message-ID: <1409779908.87.0.4046116696.issue22331@psf.upfronthosting.co.za> New submission from STINNER Victor: http://buildbot.python.org/all/builders/x86%20FreeBSD%207.2%203.4/builds/332/steps/test/logs/stdio Log: --- [157/389/1] test_io Timeout (1:00:00)! Thread 0x2a4f0790 (most recent call first): File "/usr/home/db3l/buildarea/3.4.bolen-freebsd7/build/Lib/test/test_io.py", line 3257 in _read File "/usr/home/db3l/buildarea/3.4.bolen-freebsd7/build/Lib/threading.py", line 869 in run File "/usr/home/db3l/buildarea/3.4.bolen-freebsd7/build/Lib/threading.py", line 921 in _bootstrap_inner File "/usr/home/db3l/buildarea/3.4.bolen-freebsd7/build/Lib/threading.py", line 889 in _bootstrap Thread 0x28401040 (most recent call first): File "/usr/home/db3l/buildarea/3.4.bolen-freebsd7/build/Lib/threading.py", line 1077 in _wait_for_tstate_lock File "/usr/home/db3l/buildarea/3.4.bolen-freebsd7/build/Lib/threading.py", line 1061 in join File "/usr/home/db3l/buildarea/3.4.bolen-freebsd7/build/Lib/test/test_io.py", line 3278 in check_interrupted_write File "/usr/home/db3l/buildarea/3.4.bolen-freebsd7/build/Lib/test/test_io.py", line 3302 in test_interrupted_write_text File "/usr/home/db3l/buildarea/3.4.bolen-freebsd7/build/Lib/unittest/case.py", line 577 in run File "/usr/home/db3l/buildarea/3.4.bolen-freebsd7/build/Lib/unittest/case.py", line 625 in __call__ File "/usr/home/db3l/buildarea/3.4.bolen-freebsd7/build/Lib/unittest/suite.py", line 125 in run File "/usr/home/db3l/buildarea/3.4.bolen-freebsd7/build/Lib/unittest/suite.py", line 87 in __call__ File "/usr/home/db3l/buildarea/3.4.bolen-freebsd7/build/Lib/unittest/suite.py", line 125 in run File "/usr/home/db3l/buildarea/3.4.bolen-freebsd7/build/Lib/unittest/suite.py", line 87 in __call__ File "/usr/home/db3l/buildarea/3.4.bolen-freebsd7/build/Lib/unittest/suite.py", line 125 in run File "/usr/home/db3l/buildarea/3.4.bolen-freebsd7/build/Lib/unittest/suite.py", line 87 in __call__ File "/usr/home/db3l/buildarea/3.4.bolen-freebsd7/build/Lib/unittest/runner.py", line 168 in run File "/usr/home/db3l/buildarea/3.4.bolen-freebsd7/build/Lib/test/support/__init__.py", line 1750 in _run_suite File "/usr/home/db3l/buildarea/3.4.bolen-freebsd7/build/Lib/test/support/__init__.py", line 1784 in run_unittest File "/usr/home/db3l/buildarea/3.4.bolen-freebsd7/build/Lib/test/regrtest.py", line 1279 in test_runner File "/usr/home/db3l/buildarea/3.4.bolen-freebsd7/build/Lib/test/regrtest.py", line 1280 in runtest_inner File "/usr/home/db3l/buildarea/3.4.bolen-freebsd7/build/Lib/test/regrtest.py", line 967 in runtest File "/usr/home/db3l/buildarea/3.4.bolen-freebsd7/build/Lib/test/regrtest.py", line 763 in main File "/usr/home/db3l/buildarea/3.4.bolen-freebsd7/build/Lib/test/regrtest.py", line 1564 in main_in_temp_cwd File "/usr/home/db3l/buildarea/3.4.bolen-freebsd7/build/Lib/test/__main__.py", line 3 in File "/usr/home/db3l/buildarea/3.4.bolen-freebsd7/build/Lib/runpy.py", line 85 in _run_code File "/usr/home/db3l/buildarea/3.4.bolen-freebsd7/build/Lib/runpy.py", line 170 in _run_module_as_main --- See also the issue #11859 (fixed). ---------- components: Tests keywords: buildbot messages: 226326 nosy: haypo priority: normal severity: normal status: open title: test_io.test_interrupted_write_text() hangs on the buildbot FreeBSD 7.2 versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 23:33:53 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 03 Sep 2014 21:33:53 +0000 Subject: [issue22331] test_io.test_interrupted_write_text() hangs on the buildbot FreeBSD 7.2 In-Reply-To: <1409779908.87.0.4046116696.issue22331@psf.upfronthosting.co.za> Message-ID: <3hpJLT1lyhz7LjP@mail.python.org> Roundup Robot added the comment: New changeset baa372eb731c by Victor Stinner in branch '3.4': Issue #22331: Skip test_interrupted_write_text() on FreeBSD older than 8.0 http://hg.python.org/cpython/rev/baa372eb731c New changeset 340d48347295 by Victor Stinner in branch 'default': (Merge 3.4) Issue #22331: Skip test_interrupted_write_text() on FreeBSD older http://hg.python.org/cpython/rev/340d48347295 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 23:42:54 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 03 Sep 2014 21:42:54 +0000 Subject: [issue17642] IDLE add font resizing hot keys In-Reply-To: <1365228385.87.0.236246362772.issue17642@psf.upfronthosting.co.za> Message-ID: <1409780574.39.0.320560240028.issue17642@psf.upfronthosting.co.za> Terry J. Reedy added the comment: #21933 added font resizing hotkeys to turtle demo: Control/Command minus, underscore, equal, minus. The OS difference was handled by defining the prefix for the system. shortcut = 'Command' if darwin else 'Control' widget.bind_all('<%s-minus>' % shortcut, self._decreaseFont) The patch also added including control-mousewheel. The discussion there revealed that Control-mousewheel up/down generates a event with event.delta of +120/-120 on Windows, -1/+1 on Darwin, and / events on X11. Control-mousewheel has a tk glitch in that it also generates ordinary mousewheel (scrolling) events. For turtledemo's read-only window of relatively short files, we decided not to worry. Moving the cursor in edit windows would be a worry. But Saimadhave and I discovered with line-numbering that this is also a problem with font resizing even without scrolling. Text widgets send scroll up and down and back to start position commands to the scroll bar on font-resizing. See #17535, my tkfontsize.py test file, and the discussion thereof. Also, the fontsize needs a minimum since tk (at least on Mac) treats negative sizes as positive sizes, so that decreasing past 0 increases. This issue is *not* easy. >From the discussion (I have not read the patches yet), I am not sure whether the hotkey is intended to affect just the one window, like Context (and probably line numbering) or all, I think it should just be the one window. ---------- keywords: -easy versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 23:44:43 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 03 Sep 2014 21:44:43 +0000 Subject: [issue22332] test_multiprocessing_main_handling fail on buildbot "x86 FreeBSD 6.4 3.x" Message-ID: <1409780683.92.0.966783842009.issue22332@psf.upfronthosting.co.za> New submission from STINNER Victor: The test requires SemLock which is not supported on FreeBSD 6.4. The whole test_multiprocessing_main_handling should be skipped on this platform. http://buildbot.python.org/all/builders/x86%20FreeBSD%206.4%203.x/builds/5010/steps/test/logs/stdio ====================================================================== FAIL: test_zipfile (test.test_multiprocessing_main_handling.SpawnCmdLineTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_multiprocessing_main_handling.py", line 213, in test_zipfile self._check_script(zip_name) File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_multiprocessing_main_handling.py", line 153, in _check_script rc, out, err = assert_python_ok(*run_args, __isolated=False) File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/script_helper.py", line 69, in assert_python_ok return _assert_python(True, *args, **env_vars) File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/script_helper.py", line 55, in _assert_python "stderr follows:\n%s" % (rc, err.decode('ascii', 'ignore'))) AssertionError: Process return code is 1, stderr follows: Traceback (most recent call last): File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/multiprocessing/synchronize.py", line 29, in from _multiprocessing import SemLock, sem_unlink ImportError: 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/runpy.py", line 170, in _run_module_as_main "__main__", mod_spec) File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/runpy.py", line 85, in _run_code exec(code, run_globals) File "/tmp/tmpwgjabqgk/test_zip.zip/__main__.py", line 16, in File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/multiprocessing/context.py", line 118, in Pool context=self.get_context()) File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/multiprocessing/pool.py", line 150, in __init__ self._setup_queues() File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/multiprocessing/pool.py", line 243, in _setup_queues self._inqueue = self._ctx.SimpleQueue() File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/multiprocessing/context.py", line 111, in SimpleQueue return SimpleQueue(ctx=self.get_context()) File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/multiprocessing/queues.py", line 319, in __init__ self._rlock = ctx.Lock() File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/multiprocessing/context.py", line 65, in Lock from .synchronize import Lock File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/multiprocessing/synchronize.py", line 34, 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. ---------- components: Tests keywords: buildbot messages: 226329 nosy: haypo priority: normal severity: normal status: open title: test_multiprocessing_main_handling fail on buildbot "x86 FreeBSD 6.4 3.x" versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 3 23:48:54 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 03 Sep 2014 21:48:54 +0000 Subject: [issue22332] test_multiprocessing_main_handling fail on buildbot "x86 FreeBSD 6.4 3.x" In-Reply-To: <1409780683.92.0.966783842009.issue22332@psf.upfronthosting.co.za> Message-ID: <3hpJgn7063z7LjN@mail.python.org> Roundup Robot added the comment: New changeset db9eb9cba1ec by Victor Stinner in branch '3.4': Issue #22332: test_multiprocessing_main_handling is now skipped if sem_open http://hg.python.org/cpython/rev/db9eb9cba1ec New changeset 2f21d920d00d by Victor Stinner in branch 'default': (Merge 3.4) Issue #22332: test_multiprocessing_main_handling is now skipped if http://hg.python.org/cpython/rev/2f21d920d00d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 00:36:26 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 03 Sep 2014 22:36:26 +0000 Subject: [issue20957] test_smptnet Fail instead of Skip if SSL-port is unavailable In-Reply-To: <1395060965.42.0.624328393078.issue20957@psf.upfronthosting.co.za> Message-ID: <3hpKkd5X7Nz7LkM@mail.python.org> Roundup Robot added the comment: New changeset b7200cde1b68 by Victor Stinner in branch '3.4': Issue #20957: test_smtpnet now uses support.transient_internet() to call http://hg.python.org/cpython/rev/b7200cde1b68 New changeset 85511d4a846e by Victor Stinner in branch 'default': (Merge 3.4) Issue #20957: test_smtpnet now uses support.transient_internet() to http://hg.python.org/cpython/rev/85511d4a846e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 00:37:42 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 03 Sep 2014 22:37:42 +0000 Subject: [issue20957] test_smptnet Fail instead of Skip if SSL-port is unavailable In-Reply-To: <1395060965.42.0.624328393078.issue20957@psf.upfronthosting.co.za> Message-ID: <1409783862.91.0.570911003816.issue20957@psf.upfronthosting.co.za> STINNER Victor added the comment: Thanks for the report. I wrote a different patch to rely on support.transient_internet() instead. ---------- nosy: +haypo resolution: -> fixed status: open -> closed versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 00:54:01 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 03 Sep 2014 22:54:01 +0000 Subject: [issue21440] Use support.rmtree in test_zipfile In-Reply-To: <1399310530.32.0.0955350320497.issue21440@psf.upfronthosting.co.za> Message-ID: <3hpL6x0Xdgz7LjR@mail.python.org> Roundup Robot added the comment: New changeset 706ec07100d6 by Victor Stinner in branch '3.4': Issue #21440: Backport changeset 4ebf97299b18 to branch 3.4, use http://hg.python.org/cpython/rev/706ec07100d6 New changeset 6b4d31641109 by Victor Stinner in branch '3.4': Issue #21440: test_zipfile: replace last direct calls to os.remove() with http://hg.python.org/cpython/rev/6b4d31641109 New changeset 73ce1afc6ee2 by Victor Stinner in branch 'default': (Merge 3.4) Issue #21440: test_zipfile: replace last direct calls to http://hg.python.org/cpython/rev/73ce1afc6ee2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 01:00:06 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 03 Sep 2014 23:00:06 +0000 Subject: [issue19690] test_logging test_race failed with PermissionError In-Reply-To: <1385105475.94.0.253645069216.issue19690@psf.upfronthosting.co.za> Message-ID: <1409785206.2.0.120147707352.issue19690@psf.upfronthosting.co.za> STINNER Victor added the comment: What is the status of this issue? The failure is still common on the buildbot: http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.4/builds/458/steps/test/logs/stdio ====================================================================== ERROR: test_race (test.test_logging.HandlerTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/buildbot/buildarea/3.4.murray-snowleopard/build/Lib/test/test_logging.py", line 618, in test_race h.handle(r) File "/Users/buildbot/buildarea/3.4.murray-snowleopard/build/Lib/logging/__init__.py", line 852, in handle self.emit(record) File "/Users/buildbot/buildarea/3.4.murray-snowleopard/build/Lib/logging/handlers.py", line 468, in emit self.stream = self._open() File "/Users/buildbot/buildarea/3.4.murray-snowleopard/build/Lib/logging/__init__.py", line 1029, in _open return open(self.baseFilename, self.mode, encoding=self.encoding) PermissionError: [Errno 1] Operation not permitted: '/tmp/test_logging-3-vrpj_wts.log' ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 01:29:58 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 03 Sep 2014 23:29:58 +0000 Subject: [issue22051] Turtledemo: stop reloading demos In-Reply-To: <1406145466.97.0.661318262793.issue22051@psf.upfronthosting.co.za> Message-ID: <3hpLwP2R36z7Lky@mail.python.org> Roundup Robot added the comment: New changeset b76d854f580e by Terry Jan Reedy in branch '2.7': Issue #22051: remove unneeded reload that allowed bad code. http://hg.python.org/cpython/rev/b76d854f580e New changeset 55d4f6c2be2d by Terry Jan Reedy in branch '3.4': Issue #22051: remove unneeded reload that allowed bad code. http://hg.python.org/cpython/rev/55d4f6c2be2d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 08:16:24 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 04 Sep 2014 06:16:24 +0000 Subject: [issue21933] Allow the user to change font sizes with the text pane of turtledemo In-Reply-To: <1404746295.5.0.877343308699.issue21933@psf.upfronthosting.co.za> Message-ID: <1409811384.2.0.635317194104.issue21933@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Unfortunately the bug on X11 is still here. Ctrl+mouse wheel not only changes font, but scrolls a text. ---------- resolution: fixed -> stage: resolved -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 08:27:13 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 04 Sep 2014 06:27:13 +0000 Subject: [issue22258] set_inheritable(): ioctl(FIOCLEX) is available but fails with ENOTTY on Illumos In-Reply-To: <1408800024.14.0.0329688839383.issue22258@psf.upfronthosting.co.za> Message-ID: <1409812033.39.0.1407836183.issue22258@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > +- Issue #22258: Fix the the internal function set_inheritable() on Illumos. "the the" ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 09:04:36 2014 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 04 Sep 2014 07:04:36 +0000 Subject: [issue19690] test_logging test_race failed with PermissionError In-Reply-To: <1385105475.94.0.253645069216.issue19690@psf.upfronthosting.co.za> Message-ID: <1409814276.55.0.799260027163.issue19690@psf.upfronthosting.co.za> Vinay Sajip added the comment: > What is the status of this issue? Sorry, it's been off my radar - I wonder if it has become more common recently. It's hard to reproduce, and tweaking timeouts might make it disappear, but it's a trial-and-error situation because I can hardly ever get the error to occur. The base race condition can't be eliminated, unfortunately. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 09:29:48 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 04 Sep 2014 07:29:48 +0000 Subject: [issue22258] set_inheritable(): ioctl(FIOCLEX) is available but fails with ENOTTY on Illumos In-Reply-To: <1408800024.14.0.0329688839383.issue22258@psf.upfronthosting.co.za> Message-ID: <3hpYZ35LK9z7Lk2@mail.python.org> Roundup Robot added the comment: New changeset 9d5386a22e68 by Victor Stinner in branch 'default': Issue #22258: Fix typo in Misc/NEWS http://hg.python.org/cpython/rev/9d5386a22e68 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 09:30:27 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 04 Sep 2014 07:30:27 +0000 Subject: [issue22258] set_inheritable(): ioctl(FIOCLEX) is available but fails with ENOTTY on Illumos In-Reply-To: <1408800024.14.0.0329688839383.issue22258@psf.upfronthosting.co.za> Message-ID: <1409815827.66.0.82320172555.issue22258@psf.upfronthosting.co.za> STINNER Victor added the comment: > "the the" Oh, thanks for the report. It's now fixed. It would be better to have the Misc/NEWS entry in the patch directly :-( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 09:32:41 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 04 Sep 2014 07:32:41 +0000 Subject: [issue22333] test_threaded_import.test_parallel_meta_path() failed on x86 Windows7 3.x Message-ID: <1409815961.59.0.0325236414674.issue22333@psf.upfronthosting.co.za> New submission from STINNER Victor: ====================================================================== FAIL: test_parallel_meta_path (test.test_threaded_import.ThreadedImportTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_threaded_import.py", line 133, in test_parallel_meta_path self.check_parallel_module_init() File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_threaded_import.py", line 121, in check_parallel_module_init self.assertTrue(done.wait(60)) AssertionError: False is not true ---------- components: Tests keywords: buildbot messages: 226341 nosy: haypo priority: normal severity: normal status: open title: test_threaded_import.test_parallel_meta_path() failed on x86 Windows7 3.x versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 09:38:55 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 04 Sep 2014 07:38:55 +0000 Subject: [issue22333] test_threaded_import.test_parallel_meta_path() failed on x86 Windows7 3.x In-Reply-To: <1409815961.59.0.0325236414674.issue22333@psf.upfronthosting.co.za> Message-ID: <3hpYmZ2F9Nz7Lk2@mail.python.org> Roundup Robot added the comment: New changeset f8d2834e1269 by Victor Stinner in branch 'default': Issue #22333: Add debug traces to test_threaded_import http://hg.python.org/cpython/rev/f8d2834e1269 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 09:52:44 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 04 Sep 2014 07:52:44 +0000 Subject: [issue22334] test_tcl.test_split() fails on "x86 FreeBSD 7.2 3.x" buildbot Message-ID: <1409817164.01.0.942615937948.issue22334@psf.upfronthosting.co.za> New submission from STINNER Victor: The test was added by the issue #18101 (changeset 9486c07929a1). On FreeBSD 7.2, Tcl version is 8.6b1 (seen in the test output). http://buildbot.python.org/all/builders/x86%20FreeBSD%207.2%203.x/builds/5560/steps/test/logs/stdio ====================================================================== FAIL: test_split (test.test_tcl.TclTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_tcl.py", line 563, in test_split self.assertEqual(split(arg), res, msg=arg) AssertionError: Tuples differ: (12, '\u20ac', b'\xe2\x82\xac', (3.4,)) != ('12', '\u20ac', '\xe2\x82\xac', '3.4') First differing element 0: 12 12 - (12, '\u20ac', b'\xe2\x82\xac', (3.4,)) + ('12', '\u20ac', '\xe2\x82\xac', '3.4') : 12 \u20ac \xe2\x82\xac 3.4 ====================================================================== FAIL: test_splitlist (test.test_tcl.TclTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_tcl.py", line 513, in test_splitlist self.assertEqual(splitlist(arg), res, msg=arg) AssertionError: Tuples differ: (12, '\u20ac', b'\xe2\x82\xac', (3.4,)) != ('12', '\u20ac', '\xe2\x82\xac', '3.4') First differing element 0: 12 12 - (12, '\u20ac', b'\xe2\x82\xac', (3.4,)) + ('12', '\u20ac', '\xe2\x82\xac', '3.4') : 12 \u20ac \xe2\x82\xac 3.4 ---------- components: Tests, Tkinter keywords: buildbot messages: 226343 nosy: haypo, serhiy.storchaka priority: normal severity: normal status: open title: test_tcl.test_split() fails on "x86 FreeBSD 7.2 3.x" buildbot _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 09:53:31 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 04 Sep 2014 07:53:31 +0000 Subject: [issue22334] test_tcl.test_split() fails on "x86 FreeBSD 7.2 3.x" buildbot In-Reply-To: <1409817164.01.0.942615937948.issue22334@psf.upfronthosting.co.za> Message-ID: <3hpZ5Q6H6Wz7Lk9@mail.python.org> Roundup Robot added the comment: New changeset e6cfbc3e2ed9 by Victor Stinner in branch 'default': Issue #22334: Add debug traces to test_tcl http://hg.python.org/cpython/rev/e6cfbc3e2ed9 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 09:59:05 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 04 Sep 2014 07:59:05 +0000 Subject: [issue21951] tcl test change crashes AIX In-Reply-To: <1405013926.74.0.877232363604.issue21951@psf.upfronthosting.co.za> Message-ID: <1409817545.75.0.172684796491.issue21951@psf.upfronthosting.co.za> STINNER Victor added the comment: The failing assertion means that the method raised an exception and returned a result, or failed but didn't raised an exception. According to the gdb trace, the function failed (res is NULL). You can display the current exception in gdb using: "print PyErr_Occurred()" (NULL if there is no exception). Please run test_tcl on AIX with attached test_tkinter.patch applied. ---------- Added file: http://bugs.python.org/file36530/tkinter_debug.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 10:06:03 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 04 Sep 2014 08:06:03 +0000 Subject: [issue6639] turtle: _tkinter.TclError: invalid command name ".10170160" In-Reply-To: <1249344565.24.0.634557720335.issue6639@psf.upfronthosting.co.za> Message-ID: <1409817963.66.0.865594005843.issue6639@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is more complete patch. ---------- Added file: http://bugs.python.org/file36531/turtledemo_destroy.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 10:11:45 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 04 Sep 2014 08:11:45 +0000 Subject: [issue21933] Allow the user to change font sizes with the text pane of turtledemo In-Reply-To: <1404746295.5.0.877343308699.issue21933@psf.upfronthosting.co.za> Message-ID: <1409818305.77.0.412034640033.issue21933@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I am aware of this because the Windows has the same behavior. As I noted in my post to #17642, I consider this behavior a tolerable glitch rather than a patch-blocking bug for turtledemo because the text is relatively short and read only, so there is no issue of needing to keep a cursor in place and visible. The issue would be different for Idle if indeed this is a tk rather than turtle problem. Also, people would typically only move a few clicks up or down, and scrolling up when already at the top of the file has no effect. So I do not regard this as a bug for this issue and regard this as still closed unless you happen to have thought of a workaround. If you don't have a fix now, you could open a separate issue to investigate whether the linkage is a tk, tkinter, or turtle bug. As part of #17535, I discovered that when a Text widgets change the font size, they scroll up, down too far (or down and up too far), and back to where they should be. This is not visible with small files like the turtle examples, but is with 3000-line files like idlelib/EditorWindow.py, especially when line numbers are enabled. My test script attached to #17535 shows that Text indeed calls scrollbar.set 3 times. I regard this as a tk bug. My point here is that Text widget font size changes are a bit flaky even without the mousewheel issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 10:29:44 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 04 Sep 2014 08:29:44 +0000 Subject: [issue22334] test_tcl.test_split() fails on "x86 FreeBSD 7.2 3.x" buildbot In-Reply-To: <1409817164.01.0.942615937948.issue22334@psf.upfronthosting.co.za> Message-ID: <1409819384.23.0.00859475613922.issue22334@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: More likely there is a bug in Tcl 8.6b1 (as in Tcl before 8.5.5). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 10:36:42 2014 From: report at bugs.python.org (Ned Deily) Date: Thu, 04 Sep 2014 08:36:42 +0000 Subject: [issue22334] test_tcl.test_split() fails on "x86 FreeBSD 7.2 3.x" buildbot In-Reply-To: <1409817164.01.0.942615937948.issue22334@psf.upfronthosting.co.za> Message-ID: <1409819802.4.0.595604922156.issue22334@psf.upfronthosting.co.za> Ned Deily added the comment: Perhaps David B can update Tcl and Tk on the buildbot? Note, Tcl/Tk 8.6.2 (and 8.5.16) were just released a few days ago. ---------- nosy: +db3l, ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 10:42:48 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 04 Sep 2014 08:42:48 +0000 Subject: [issue19546] configparser leaks implementation detail In-Reply-To: <1384103812.47.0.904880324738.issue19546@psf.upfronthosting.co.za> Message-ID: <3hpbBH5Xv3z7Ljn@mail.python.org> Roundup Robot added the comment: New changeset 2b14665b7bce by ?ukasz Langa in branch 'default': Fix #19546: onfigparser exceptions expose implementation details. Patch by Claudiu Popa. http://hg.python.org/cpython/rev/2b14665b7bce New changeset 554ead559f24 by ?ukasz Langa in branch 'default': Merge fix for #19546: configparser exceptions leak implementation details http://hg.python.org/cpython/rev/554ead559f24 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 10:43:53 2014 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Thu, 04 Sep 2014 08:43:53 +0000 Subject: [issue19546] configparser leaks implementation detail In-Reply-To: <1384103812.47.0.904880324738.issue19546@psf.upfronthosting.co.za> Message-ID: <1409820233.72.0.0475505431992.issue19546@psf.upfronthosting.co.za> Changes by ?ukasz Langa : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 10:44:18 2014 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Thu, 04 Sep 2014 08:44:18 +0000 Subject: [issue19546] configparser leaks implementation detail In-Reply-To: <1384103812.47.0.904880324738.issue19546@psf.upfronthosting.co.za> Message-ID: <1409820258.31.0.655776212398.issue19546@psf.upfronthosting.co.za> ?ukasz Langa added the comment: Thank you Claudiu for your patch, sorry it took so long to respond. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 10:45:13 2014 From: report at bugs.python.org (Claudiu Popa) Date: Thu, 04 Sep 2014 08:45:13 +0000 Subject: [issue19546] configparser leaks implementation detail In-Reply-To: <1384103812.47.0.904880324738.issue19546@psf.upfronthosting.co.za> Message-ID: <1409820313.8.0.907169307482.issue19546@psf.upfronthosting.co.za> Claudiu Popa added the comment: No problem, thank you for committing it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 10:49:42 2014 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Thu, 04 Sep 2014 08:49:42 +0000 Subject: [issue21186] RawConfigParser __name__ option handling inconsistent In-Reply-To: <1397033583.06.0.34789258522.issue21186@psf.upfronthosting.co.za> Message-ID: <1409820582.64.0.347166884574.issue21186@psf.upfronthosting.co.za> ?ukasz Langa added the comment: Thanks for your report and sorry it took so long to respond! You are absolutely right that __name__ was a broken feature, which is why we removed it in Python 3.2. See issue #10489. For Python 2.7 you can use the backport, available on PyPI. ---------- resolution: -> fixed stage: -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 11:25:14 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 04 Sep 2014 09:25:14 +0000 Subject: [issue22334] test_tcl.test_split() fails on "x86 FreeBSD 7.2 3.x" buildbot In-Reply-To: <1409817164.01.0.942615937948.issue22334@psf.upfronthosting.co.za> Message-ID: <1409822714.02.0.020795921166.issue22334@psf.upfronthosting.co.za> STINNER Victor added the comment: > More likely there is a bug in Tcl 8.6b1 (as in Tcl before 8.5.5). If the bug is not present in Tcl 8.6.2, we can skip the test on the version Tcl 8.6b1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 12:36:59 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 04 Sep 2014 10:36:59 +0000 Subject: [issue21356] Support LibreSSL (instead of OpenSSL): make RAND_egd optional In-Reply-To: <1398522096.15.0.100207892067.issue21356@psf.upfronthosting.co.za> Message-ID: <1409827019.25.0.0439534441455.issue21356@psf.upfronthosting.co.za> STINNER Victor added the comment: > The PyPy patch (and some discussion) is here: Your patch checks at runtime if libssl comes with RAND_egd: HAVE_OPENSSL_RAND_EGD = rffi_platform.Has('RAND_egd') In CPython, the _ssl module is compiled in C. How can we check if libssl provides RAND_egd() or not at compile time? Is there a way to check if libssl is OpenSSL or LibreSSL? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 12:38:57 2014 From: report at bugs.python.org (swanson) Date: Thu, 04 Sep 2014 10:38:57 +0000 Subject: [issue22335] Python 3: Segfault instead of MemoryError when bytearray too big Message-ID: <1409827137.12.0.977974506247.issue22335@psf.upfronthosting.co.za> New submission from swanson: On Python 3, but not Python 2, you crash with a Segmentation Fault instead of getting a MemoryError as expected. It seems to only be a problem with bytearray, not with other things like tuple: $ python3 Python 3.4.0 (default, Apr 11 2014, 13:05:18) [GCC 4.8.2] on linux Type "help", "copyright", "credits" or "license" for more information. >>> bytearray(0x7FFFFFFF) Segmentation fault (core dumped) $ compare to: $ python Python 2.7.6 (default, Mar 22 2014, 22:59:38) [GCC 4.8.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> bytearray(0x7FFFFFFF) Traceback (most recent call last): File "", line 1, in MemoryError >>> $ python3 Python 3.4.0 (default, Apr 11 2014, 13:05:18) [GCC 4.8.2] on linux Type "help", "copyright", "credits" or "license" for more information. >>> (0,)*0x7FFFFFFF Traceback (most recent call last): File "", line 1, in MemoryError >>> ---------- messages: 226356 nosy: swanson priority: normal severity: normal status: open title: Python 3: Segfault instead of MemoryError when bytearray too big type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 12:44:23 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 04 Sep 2014 10:44:23 +0000 Subject: [issue21356] Support LibreSSL (instead of OpenSSL): make RAND_egd optional In-Reply-To: <1398522096.15.0.100207892067.issue21356@psf.upfronthosting.co.za> Message-ID: <1409827463.15.0.484014629459.issue21356@psf.upfronthosting.co.za> STINNER Victor added the comment: Related discussion: http://marc.info/?l=openbsd-tech&m=140512043210089&w=2 The answer for Python is: "your package maintainers and ask them to configure these software without egd support." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 12:47:28 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 04 Sep 2014 10:47:28 +0000 Subject: [issue22323] Rewrite PyUnicode_AsWideChar() and PyUnicode_AsWideCharString() In-Reply-To: <1409607134.14.0.210351686888.issue22323@psf.upfronthosting.co.za> Message-ID: <1409827648.21.0.0406026076918.issue22323@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 13:57:10 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 04 Sep 2014 11:57:10 +0000 Subject: [issue22335] Python 3: Segfault instead of MemoryError when bytearray too big In-Reply-To: <1409827137.12.0.977974506247.issue22335@psf.upfronthosting.co.za> Message-ID: <1409831830.2.0.808266878058.issue22335@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Looks as integer overflow introduced in issue19087. + if (size + logical_offset + 1 < alloc) { ---------- nosy: +pitrou, serhiy.storchaka stage: -> needs patch versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 13:57:58 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 04 Sep 2014 11:57:58 +0000 Subject: [issue22335] Python 3: Segfault instead of MemoryError when bytearray too big In-Reply-To: <1409827137.12.0.977974506247.issue22335@psf.upfronthosting.co.za> Message-ID: <1409831878.67.0.0936293519566.issue22335@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 14:00:45 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 04 Sep 2014 12:00:45 +0000 Subject: [issue21951] tcl test change crashes AIX In-Reply-To: <1405013926.74.0.877232363604.issue21951@psf.upfronthosting.co.za> Message-ID: <1409832045.81.0.0946319655855.issue21951@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: As far as I remember, both res and PyErr_Occurred() were NULL. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 16:09:04 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 04 Sep 2014 14:09:04 +0000 Subject: [issue21933] Allow the user to change font sizes with the text pane of turtledemo In-Reply-To: <1404746295.5.0.877343308699.issue21933@psf.upfronthosting.co.za> Message-ID: <1409839744.69.0.451627541241.issue21933@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch which should fix this bug. In additional it fixes a bug on MacOS: mouse wheel only increased font size. ---------- Added file: http://bugs.python.org/file36532/turtledemo_change_font_size.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 16:22:11 2014 From: report at bugs.python.org (David Edelsohn) Date: Thu, 04 Sep 2014 14:22:11 +0000 Subject: [issue21951] tcl test change crashes AIX In-Reply-To: <1405013926.74.0.877232363604.issue21951@psf.upfronthosting.co.za> Message-ID: <1409840531.55.0.643785254582.issue21951@psf.upfronthosting.co.za> David Edelsohn added the comment: When the failing test is re-enabled, the _tkinter patch produces the following output: test_user_command (test.test_tcl.TclTest) ... Assertion failed: __EX, file /home/dje/src/cpython/Modules/_tkinter.c, line 1277 Fatal Python error: Aborted Current thread 0x00000001 (most recent call first): File "/home/dje/src/cpython/Lib/test/test_tcl.py", line 435 in check File "/home/dje/src/cpython/Lib/test/test_tcl.py", line 468 in test_user_command File "/home/dje/src/cpython/Lib/unittest/case.py", line 577 in run File "/home/dje/src/cpython/Lib/unittest/case.py", line 625 in __call__ File "/home/dje/src/cpython/Lib/unittest/suite.py", line 125 in run File "/home/dje/src/cpython/Lib/unittest/suite.py", line 87 in __call__ File "/home/dje/src/cpython/Lib/unittest/suite.py", line 125 in run File "/home/dje/src/cpython/Lib/unittest/suite.py", line 87 in __call__ File "/home/dje/src/cpython/Lib/unittest/runner.py", line 168 in run File "/home/dje/src/cpython/Lib/test/support/__init__.py", line 1750 in _run_suite File "/home/dje/src/cpython/Lib/test/support/__init__.py", line 1784 in run_unittest File "/home/dje/src/cpython/Lib/test/test_tcl.py", line 615 in test_main File "/home/dje/src/cpython/Lib/test/regrtest.py", line 1280 in runtest_inner File "/home/dje/src/cpython/Lib/test/regrtest.py", line 978 in runtest File "/home/dje/src/cpython/Lib/test/regrtest.py", line 763 in main File "/home/dje/src/cpython/Lib/test/regrtest.py", line 1564 in main_in_temp_cwd File "/home/dje/src/cpython/Lib/test/__main__.py", line 3 in File "/home/dje/src/cpython/Lib/runpy.py", line 85 in _run_code File "/home/dje/src/cpython/Lib/runpy.py", line 170 in _run_module_as_main IOT/Abort trap (core dumped) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 17:30:33 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 04 Sep 2014 15:30:33 +0000 Subject: [issue21951] tcl test change crashes AIX In-Reply-To: <1405013926.74.0.877232363604.issue21951@psf.upfronthosting.co.za> Message-ID: <3hpmDm5qTXz7LjS@mail.python.org> Roundup Robot added the comment: New changeset 9ab404cdcaa1 by Victor Stinner in branch 'default': Issue #21951: Fix AsObj() of the _tkinter module: raise MemoryError on memory http://hg.python.org/cpython/rev/9ab404cdcaa1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 17:46:11 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 04 Sep 2014 15:46:11 +0000 Subject: [issue22336] _tkinter should use Python PyMem_Malloc() instead of Tcl ckalloc() Message-ID: <1409845570.99.0.729089959618.issue22336@psf.upfronthosting.co.za> New submission from STINNER Victor: The PyMem_Malloc(size) function has a well defined behaviour: if size is 0, a pointer different than NULL is returned. It looks like ckalloc(size) returns NULL if the size is NULL: see issue #21951 (bug on AIX). Moreover, memory allocated by ckalloc() is not traced by the new tracemalloc module! Attached patch replaces calls to ckalloc() and ckfree() with PyMem_Malloc() and PyMem_Free(). It may fix the issue #21951 on AIX. There is still a call to ckfree() in Tkapp_SplitList(). This memory block is allocated internally by Tcl, not directly by _tkinter.c. ---------- files: pymem.patch keywords: patch messages: 226363 nosy: David.Edelsohn, haypo, serhiy.storchaka priority: normal severity: normal status: open title: _tkinter should use Python PyMem_Malloc() instead of Tcl ckalloc() type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file36533/pymem.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 17:46:15 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 04 Sep 2014 15:46:15 +0000 Subject: [issue22336] _tkinter should use Python PyMem_Malloc() instead of Tcl ckalloc() In-Reply-To: <1409845570.99.0.729089959618.issue22336@psf.upfronthosting.co.za> Message-ID: <1409845575.75.0.235608391214.issue22336@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- components: +Tkinter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 17:47:22 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 04 Sep 2014 15:47:22 +0000 Subject: [issue21951] tcl test change crashes AIX In-Reply-To: <1405013926.74.0.877232363604.issue21951@psf.upfronthosting.co.za> Message-ID: <1409845642.27.0.160372248846.issue21951@psf.upfronthosting.co.za> STINNER Victor added the comment: > When the failing test is re-enabled, the _tkinter patch produces the following output: Thanks. I found and fixed a bug in AsObj() for tuple and list. It looks like ckalloc(size) returns NULL if size is 0. Please update Python, compile and run test_tcl to see if you get a MemoryError exception instead of a crash. I just created the issue #22336 which may fix this issue if my analysis was correct. It uses PyMem_Malloc(size) which has a well-defined behaviour when size is 0. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 17:51:51 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 04 Sep 2014 15:51:51 +0000 Subject: [issue22336] _tkinter should use Python PyMem_Malloc() instead of Tcl ckalloc() In-Reply-To: <1409845570.99.0.729089959618.issue22336@psf.upfronthosting.co.za> Message-ID: <1409845911.54.0.66847597499.issue22336@psf.upfronthosting.co.za> STINNER Victor added the comment: > PyMem_Free(FREECAST argv); FREECAST can be dropped here, PyMem_Free() always takes a void* pointer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 19:08:02 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 04 Sep 2014 17:08:02 +0000 Subject: [issue22336] _tkinter should use Python PyMem_Malloc() instead of Tcl ckalloc() In-Reply-To: <1409845570.99.0.729089959618.issue22336@psf.upfronthosting.co.za> Message-ID: <1409850482.95.0.786389048763.issue22336@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Event structs (Tkapp_CallEvent, VarEvent, CommandEvent) must have been allocated by the caller using Tcl_Alloc or ckalloc (see man Tcl_ThreadQueueEvent). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 19:19:41 2014 From: report at bugs.python.org (David Edelsohn) Date: Thu, 04 Sep 2014 17:19:41 +0000 Subject: [issue21951] tcl test change crashes AIX In-Reply-To: <1405013926.74.0.877232363604.issue21951@psf.upfronthosting.co.za> Message-ID: <1409851181.85.0.275178576479.issue21951@psf.upfronthosting.co.za> David Edelsohn added the comment: $ ./python -m test -v test_tcl == CPython 3.5.0a0 (default:9ab404cdcaa1+, Sep 4 2014, 10:06:33) [GCC 4.8.1] == AIX-1-00F84C0C4C00-powerpc-32bit big-endian == hash algorithm: siphash24 32bit == /home/dje/src/cpython/build/test_python_48694044 Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0) [1/1] test_tcl patchlevel = 8.4.7 testCall (test.test_tcl.TclTest) ... ok testCallException (test.test_tcl.TclTest) ... ok testCallException2 (test.test_tcl.TclTest) ... ok testEval (test.test_tcl.TclTest) ... ok testEvalException (test.test_tcl.TclTest) ... ok testEvalException2 (test.test_tcl.TclTest) ... ok testEvalFile (test.test_tcl.TclTest) ... ok testEvalFileException (test.test_tcl.TclTest) ... ok testGetVar (test.test_tcl.TclTest) ... ok testGetVarArray (test.test_tcl.TclTest) ... ok testGetVarArrayException (test.test_tcl.TclTest) ... ok testGetVarException (test.test_tcl.TclTest) ... ok testLoadWithUNC (test.test_tcl.TclTest) ... skipped 'Requires Windows' testPackageRequireException (test.test_tcl.TclTest) ... ok testSetVar (test.test_tcl.TclTest) ... ok testSetVarArray (test.test_tcl.TclTest) ... ok testUnsetVar (test.test_tcl.TclTest) ... ok testUnsetVarArray (test.test_tcl.TclTest) ... ok testUnsetVarException (test.test_tcl.TclTest) ... ok test_eval_null_in_result (test.test_tcl.TclTest) ... ok test_evalfile_null_in_result (test.test_tcl.TclTest) ... ok test_exprboolean (test.test_tcl.TclTest) ... ok test_exprdouble (test.test_tcl.TclTest) ... ok test_exprlong (test.test_tcl.TclTest) ... ok test_exprstring (test.test_tcl.TclTest) ... ok test_getboolean (test.test_tcl.TclTest) ... ok test_getdouble (test.test_tcl.TclTest) ... ok test_getint (test.test_tcl.TclTest) ... ok test_passing_values (test.test_tcl.TclTest) ... ok test_split (test.test_tcl.TclTest) ... ok test_splitlist (test.test_tcl.TclTest) ... ok test_user_command (test.test_tcl.TclTest) ... ERROR testFlattenLen (test.test_tcl.TkinterTest) ... ok test_huge_string_builtins (test.test_tcl.BigmemTclTest) ... skipped 'needs UINT_MAX < SIZE_MAX' test_huge_string_call (test.test_tcl.BigmemTclTest) ... skipped 'needs UINT_MAX < SIZE_MAX' ====================================================================== ERROR: test_user_command (test.test_tcl.TclTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/dje/src/cpython/Lib/test/test_tcl.py", line 468, in test_user_command check((), '') File "/home/dje/src/cpython/Lib/test/test_tcl.py", line 435, in check r = self.interp.call('testfunc', value) MemoryError ---------------------------------------------------------------------- Ran 35 tests in 0.133s FAILED (errors=1, skipped=3) test test_tcl failed 1 test failed: test_tcl ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 19:53:52 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 04 Sep 2014 17:53:52 +0000 Subject: [issue21933] Allow the user to change font sizes with the text pane of turtledemo In-Reply-To: <1404746295.5.0.877343308699.issue21933@psf.upfronthosting.co.za> Message-ID: <1409853232.22.0.231359203758.issue21933@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Great. That works better on Windows too. Attached is an augmented patch to also move the other size bindings to text (I verified that 'bind_all' is needed), move the resize binding back to where it was, delete the now-empty binding function, and add a not to the docstring that the mousewheel only resizes when the mouse is over the text. Please verify that this also works for non-windows. ---------- Added file: http://bugs.python.org/file36534/turtledemo_change_font_size2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 20:33:17 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 04 Sep 2014 18:33:17 +0000 Subject: [issue21933] Allow the user to change font sizes with the text pane of turtledemo In-Reply-To: <1404746295.5.0.877343308699.issue21933@psf.upfronthosting.co.za> Message-ID: <1409855597.36.0.211590247738.issue21933@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This works on X11 (Linux). Actually it doesn't matter for what widget you call bind_all(). It works globally. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 21:00:18 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 04 Sep 2014 19:00:18 +0000 Subject: [issue20421] expose SSL socket protocol version In-Reply-To: <1390927014.41.0.169425093715.issue20421@psf.upfronthosting.co.za> Message-ID: <3hprtn4Tpyz7Llp@mail.python.org> Roundup Robot added the comment: New changeset 648685f8d5e9 by Antoine Pitrou in branch 'default': Issue #20421: Add a .version() method to SSL sockets exposing the actual protocol version in use. http://hg.python.org/cpython/rev/648685f8d5e9 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 21:02:06 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 04 Sep 2014 19:02:06 +0000 Subject: [issue20421] expose SSL socket protocol version In-Reply-To: <1390927014.41.0.169425093715.issue20421@psf.upfronthosting.co.za> Message-ID: <1409857326.65.0.415365202692.issue20421@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Pushed to default. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 21:03:14 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 04 Sep 2014 19:03:14 +0000 Subject: [issue17535] IDLE: Add an option to show line numbers along the left side of the editor window, and have it enabled by default. In-Reply-To: <1364102013.73.0.373085073641.issue17535@psf.upfronthosting.co.za> Message-ID: <1409857394.01.0.0572936647551.issue17535@psf.upfronthosting.co.za> Terry J. Reedy added the comment: And if you enable code context in the other window, neither will have the checkmark. As I said, the one button is being used to toggle two things: the state of the current window and the default for future windows, and the checkmark only indicates the second. I agree that this is confusing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 21:18:56 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 04 Sep 2014 19:18:56 +0000 Subject: [issue13179] IDLE uses common tkinter variables across all editor windows In-Reply-To: <1318607548.28.0.391563618977.issue13179@psf.upfronthosting.co.za> Message-ID: <1409858336.17.0.368480553678.issue13179@psf.upfronthosting.co.za> Terry J. Reedy added the comment: There has been more discussion of code context toggling in #17535, msg225411 2014-8-16 and following messages. The code context button toggles both the state of the current window and the default for new windows. PEP 434 ratified my comment about new Idle features not having to wait. #3068 is about adding an extension configuration dialog that will be needed to uncouple the local and global effects of option buttons for extension features. ---------- versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 21:41:28 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 04 Sep 2014 19:41:28 +0000 Subject: [issue21951] tcl test change crashes AIX In-Reply-To: <1405013926.74.0.877232363604.issue21951@psf.upfronthosting.co.za> Message-ID: <1409859688.14.0.570775161396.issue21951@psf.upfronthosting.co.za> STINNER Victor added the comment: Thanks David! Your ouput confirms my analysis. asobj_empty_sequence.patch should fix the test on AIX. I read Tcl source code, Tcl_NewListObj() doesn't use the second parameter if the first parameter (length) is zero. ---------- Added file: http://bugs.python.org/file36535/asobj_empty_sequence.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 21:47:57 2014 From: report at bugs.python.org (Alex Gaynor) Date: Thu, 04 Sep 2014 19:47:57 +0000 Subject: [issue20421] expose SSL socket protocol version In-Reply-To: <1390927014.41.0.169425093715.issue20421@psf.upfronthosting.co.za> Message-ID: <1409860077.35.0.227242501594.issue20421@psf.upfronthosting.co.za> Alex Gaynor added the comment: Should this be backported to 2.7.9? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 21:55:01 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 04 Sep 2014 19:55:01 +0000 Subject: [issue20421] expose SSL socket protocol version In-Reply-To: <1390927014.41.0.169425093715.issue20421@psf.upfronthosting.co.za> Message-ID: <1409860501.7.0.0737617996839.issue20421@psf.upfronthosting.co.za> Antoine Pitrou added the comment: It's as you want, now. I don't think this is really important, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 22:16:21 2014 From: report at bugs.python.org (Alex Gaynor) Date: Thu, 04 Sep 2014 20:16:21 +0000 Subject: [issue20421] expose SSL socket protocol version In-Reply-To: <1390927014.41.0.169425093715.issue20421@psf.upfronthosting.co.za> Message-ID: <1409861781.31.0.621611546299.issue20421@psf.upfronthosting.co.za> Alex Gaynor added the comment: Attached patch backports it (only change is the use of `closing()` and resolving the conflict in Misc/NEWS). I'll leave it up to benjamin whether he wants to commit (input from others welcome). My view is to prefer backporting stuff since it helps keep the diff small. ---------- nosy: +benjamin.peterson Added file: http://bugs.python.org/file36536/backport-version.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 22:28:19 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 04 Sep 2014 20:28:19 +0000 Subject: [issue4180] warnings.simplefilter("always") does not make warnings always show up In-Reply-To: <1224712172.47.0.998538899646.issue4180@psf.upfronthosting.co.za> Message-ID: <1409862498.98.0.273604754273.issue4180@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Brett, do you want to review this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 22:33:36 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 04 Sep 2014 20:33:36 +0000 Subject: [issue20421] expose SSL socket protocol version In-Reply-To: <1390927014.41.0.169425093715.issue20421@psf.upfronthosting.co.za> Message-ID: <3hptyR3v7Wz7Ljf@mail.python.org> Roundup Robot added the comment: New changeset 16c86a6bdbe2 by Alex Gaynor in branch '2.7': Issue #20421: Add a .version() method to SSL sockets exposing the actual protocol version in use. http://hg.python.org/cpython/rev/16c86a6bdbe2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 23:25:23 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 04 Sep 2014 21:25:23 +0000 Subject: [issue22334] test_tcl.test_split() fails on "x86 FreeBSD 7.2 3.x" buildbot In-Reply-To: <1409817164.01.0.942615937948.issue22334@psf.upfronthosting.co.za> Message-ID: <1409865923.84.0.652078374441.issue22334@psf.upfronthosting.co.za> STINNER Victor added the comment: Debug trace from x86 FreeBSD 6.4 3.x: ====================================================================== FAIL: test_splitlist (test.test_tcl.TclTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_tcl.py", line 517, in test_splitlist 'arg=%a, %s' % (arg, dbg_info)) AssertionError: Tuples differ: (12, '\u20ac', b'\xe2\x82\xac', (3.4,)) != ('12', '\u20ac', '\xe2\x82\xac', '3.4') First differing element 0: 12 12 - (12, '\u20ac', b'\xe2\x82\xac', (3.4,)) + ('12', '\u20ac', '\xe2\x82\xac', '3.4') : arg=, want objects? True, Tcl version: (8, 5), Tk patchlevel: (8, 5, 4) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 23:40:20 2014 From: report at bugs.python.org (DenisCrnic) Date: Thu, 04 Sep 2014 21:40:20 +0000 Subject: [issue22337] Modulus not returning proper remainder Message-ID: <1409866820.23.0.262547020156.issue22337@psf.upfronthosting.co.za> New submission from DenisCrnic: Modulus is returning wrong remainder when working with negative numbers. For example 34%-3 should return 1, but it returns -2. 34/-3=-11, remainder: 1, proof: -11*(-3)+1=34 <--- Math logic (works in Java for example) but python goes like that: 34/-3=12, remainder: -2. proof: -12*(-3)+(-2)=34 <--- Python logic (works) I know that python is looking for the int which is the closest to the a (a%b), and is divisible with it, but in this case that's not right. it should seek for the closest integer, which is lower than a, in this case 33 If explanation is not clear enough, reply me, i'll take more time to make it clear. maybe my theory is wrong, and python syntax works better than in Java. ---------- files: Screenshot_1.png messages: 226381 nosy: DenisCrnic priority: normal severity: normal status: open title: Modulus not returning proper remainder type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file36537/Screenshot_1.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 4 23:50:23 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 04 Sep 2014 21:50:23 +0000 Subject: [issue22334] test_tcl.test_split() fails on "x86 FreeBSD 7.2 3.x" buildbot In-Reply-To: <1409817164.01.0.942615937948.issue22334@psf.upfronthosting.co.za> Message-ID: <1409867423.55.0.334022807051.issue22334@psf.upfronthosting.co.za> STINNER Victor added the comment: Debug trace on FreeBSD 7.2: ====================================================================== FAIL: test_splitlist (test.test_tcl.TclTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_tcl.py", line 517, in test_splitlist 'arg=%a, %s' % (arg, dbg_info)) AssertionError: Tuples differ: (12, '\u20ac', b'\xe2\x82\xac', (3.4,)) != ('12', '\u20ac', '\xe2\x82\xac', '3.4') First differing element 0: 12 12 - (12, '\u20ac', b'\xe2\x82\xac', (3.4,)) + ('12', '\u20ac', '\xe2\x82\xac', '3.4') : arg=, want objects? True, Tcl version: (8, 6), Tk patchlevel: (8, -1) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 00:01:31 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 04 Sep 2014 22:01:31 +0000 Subject: [issue22337] Modulus not returning proper remainder In-Reply-To: <1409866820.23.0.262547020156.issue22337@psf.upfronthosting.co.za> Message-ID: <1409868091.23.0.405109661635.issue22337@psf.upfronthosting.co.za> R. David Murray added the comment: This is, indeed, the way Python works. See https://docs.python.org/3/reference/expressions.html where you will find: The modulo operator always yields a result with the same sign as its second operand (or zero); the absolute value of the result is strictly smaller than the absolute value of the second operand ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 00:18:10 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 04 Sep 2014 22:18:10 +0000 Subject: [issue22117] Rewrite pytime.h to work on nanoseconds In-Reply-To: <1406848093.52.0.5184372094.issue22117@psf.upfronthosting.co.za> Message-ID: <1409869090.75.0.508744175656.issue22117@psf.upfronthosting.co.za> STINNER Victor added the comment: And now, something completly different. nanosec-wip.patch is a work-in-progress patch to use a unified (64 bits) integer type to store a timestamp: _PyTime_t. The type is written to be opaque, the unit is undefined, you must use functions to convert from and to this type. Well, in fact it's just a number of nanoseconds. The patch is large: Include/pytime.h | 125 ++++++----- Modules/_datetimemodule.c | 43 ++-- Modules/_testcapimodule.c | 25 +- Modules/_threadmodule.c | 156 +++++++------- Modules/gcmodule.c | 12 - Modules/posixmodule.c | 29 +- Modules/selectmodule.c | 33 --- Modules/signalmodule.c | 20 - Modules/socketmodule.c | 151 ++++++++------ Modules/socketmodule.h | 2 Modules/timemodule.c | 40 ++- Python/pytime.c | 480 +++++++++++++++++++++++++++++----------------- 12 files changed, 645 insertions(+), 471 deletions(-) Conversion functions require a rounding mode. I didn't update all tests yet. For example, test_datetime crash, test_time and test_threading fail. There are also 3 remaining FIXME for myself in pytime.c. ---------- Added file: http://bugs.python.org/file36538/nanosec-wip.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 00:25:42 2014 From: report at bugs.python.org (=?utf-8?q?Evens_Fortun=C3=A9?=) Date: Thu, 04 Sep 2014 22:25:42 +0000 Subject: [issue21228] Missing enumeration of HTTPResponse Objects methods of urllib.request.urlopen's http.client.HTTPResponse? In-Reply-To: <1397520483.48.0.224250148615.issue21228@psf.upfronthosting.co.za> Message-ID: <1409869542.46.0.355938912343.issue21228@psf.upfronthosting.co.za> Evens Fortun? added the comment: Hi, >From my limited experience reporting documentation issues, I see that it's better to submit a patch than to only report an issue. So, I've tried to look into the source code to figure out what was going on. I have attached a patch that I'm submitting to you for review hoping I doing everything right. What was reported as ambiguous in this issue is the description of the return value of the function urllib.request.urlopen() for http and https URLs. It was mentionned that it should be an http.client.HTTPResponse object but it implied that something may have been different about this object. To understand why I'm may now be able to assert what's being said in that patch, follow me in the source code. It's based on revision c499cc2c4a06. If you don't care about all the walkthrough you can skip to step 9. 1. We want to describe the return value of the urllib.request.urlopen() for http and https URLs 2. The urlopen() function is defined in Lib/urllib/request.py starting on line 138. Its return value is the return value function of the opener.open() method (line 153) * This opener object is defined in one of these locations: * On line 150 as the return value of the module function build_opener() (this return value is cached in the _opener module variable) * On line 152 as the value cached in the _opener module variable * On line 148 still as the return value of the module function build_opener() in the case if you want to access an HTTPS URL and you provide a cafile, capath or cadefault argument * So either way, the opener object come from the build_opener directly or indirectly. 3. The build_opener() function is defined starting on line 505. Its return value (line 539) is an instance of the OpenerDirector class (line 514). The OpenerDirector class is defined starting on line 363. a. Before returning its return value, after some checks (lines 522-530, 535-536), build_opener() calls the OpenerDirector().add_handler() with an instance of some of the classes defined in the default_classes list (line 515-518). What matters to us is the HTTPHandler class and the HTTPSHandler class (line 520). b. The OpenerDirector().add_handler() method (line 375) takes the HTTPHandler class (line 1196) and: * Insert the HTTPHandler.http_open() method in the list stored as the value of OpenerDirector().handle_open['http']. * Insert the HTTPHandler.http_request() method in the list stored as the value of OpenerDirector().process_request['http']. c. For HTTPSHandler (line 1203) is the same thing but : * HTTPSHandler.https_open() for OpenerDirector().handle_open['https'] * HTTPSHandler.https_request() for OpenerDirector().process_request['https'] 4. I remind you that we are looking for the return value of the method open() of an instance of the OpenerDirector class (see point number 2). This method is defined starting on line 437. 5. The OpenDirector.open() method's return value is the response variable (line 463) 6. This variable is defined on lines 461 and 455. a. The loop on lines 458-461 tries to find in his handlers (the OpenerDirector().process_response dictionary) a response processor (a XXX.http_response() method) which isn't defined in HTTPHandler or HTTPSHandler. (a http_response() method is defined in HTTPErrorProcessor [line 564] and in HTTPCookieProcessor [line 1231] but in each of these cases, these classes don't modify the response value) b. So response variable's value is the return value of OpenerDirector()._open(req, data) on line 455. * The req argument is a Request instance (line 440) or something that has the same interface, I guess (line 442). The Request class is defined on line 253. * The data argument is included in the constructor of the Request instance (line 440 and then on line 262) or added to the object provided (line 444). Afterwards, it won't be used directly?(OpenerDirector()._open() receives it as an argument but won't use it in its body) 7. OpenerDirector()._open() is defined on line 465. It will call OpenerDirector()._call_chain() up to three times depending on whether a result has been found (lines 468-469, 474-475). * OpenerDirector()._call_chain() is defined on line 426. All it does is calling the handlers registered in the dictionnary provided (the chain argument) until one returns something else than None and returns it. * In our case (retrieving http and http resources): a. The first call (line 466) will return None since HTTPHandler or HTTPSHandler don't have a default_open() method (in fact, no handler defined in this file has a default_open() method) b. The second call will work since HTTPHandler.http_open() (line 1198) and HTTPSHandler.https_open() (line 1212) exists. Their return values will be enventually what we are looking for. 8. HTTPHandler.http_open() and HTTPSHandler.https_open() returns the return value of do_open() method defined (on line 1134) in their mutual superclass AbstractHTTPHandler (line 1086). They will call it with http.client.HTTPConnection and req in the case of HTTPHandler and http.client.HTTPSConnection and req in the case of HTTPSHandler with a few other arguments. 9. OpenerDirector().do_open() creates a http.client.HTTPSConnection object (line 1144) and calls its request() method (line 1173) and if it works, calls its getreponse() method (line 1178). This return value is the HTTPResponse object we are looking for. 10. Finally we get our answer: * On line 1186, an url attribute is added to this HTTPResponse object * On line 1192, the msg attribute is replaced by the reason attribute I hope this is what was needed to close this issue. Otherwise, just tell me what is missing. Oh and there seems that there are be many things that could be refactored. Can I do it and open issues about them?? ---------- keywords: +patch Added file: http://bugs.python.org/file36539/issue21228.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 00:37:10 2014 From: report at bugs.python.org (Marcin Wojdyr) Date: Thu, 04 Sep 2014 22:37:10 +0000 Subject: [issue4130] Intel icc 9.1 does not support __int128_t used by ctypes In-Reply-To: <1224103336.6.0.753228794094.issue4130@psf.upfronthosting.co.za> Message-ID: <1409870230.16.0.163352101509.issue4130@psf.upfronthosting.co.za> Marcin Wojdyr added the comment: I just came across this issue when compiling 2.7.8 with ICC 15.0. But apparently it's been fixed in the meantime by updating libffi to v3.1 (r92061 for 2.7). ---------- nosy: +wojdyr _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 01:01:51 2014 From: report at bugs.python.org (David Bolen) Date: Thu, 04 Sep 2014 23:01:51 +0000 Subject: [issue21907] Update Windows build batch scripts In-Reply-To: <1404328602.32.0.540869349126.issue21907@psf.upfronthosting.co.za> Message-ID: <1409871711.32.0.752871116269.issue21907@psf.upfronthosting.co.za> David Bolen added the comment: While troubleshooting an issue with test_distutils consistently failing on my XP buildbot, I narrowed it down to the test.bat change to use run_tests.py. I don't yet know fully what's happening, but after replacing the new test.bat with the older version (that calls rt.bat) everything works fine. Doing so also appears to clean up the stdin encoding problem (which was causing a consistent failure in test_capi). As suggested by Zachary in msg222621, and given the status of XP going forward, I think it may be best, at least for now, to revert back to the traditional test.bat/rt.bat combination under XP, which has been stable for a long time. At least until some further work can be done to discover what's happening with the new approach, assuming it's desired at some point under XP. Attached is a simple test.bat update that reverts to the older rt.bat approach but only under XP. ---------- Added file: http://bugs.python.org/file36540/test.bat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 01:11:36 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 04 Sep 2014 23:11:36 +0000 Subject: [issue22290] "AMD64 OpenIndiana 3.x" buildbot: assertion failed in PyObject_Call() in test_subprocess.test_preexec() In-Reply-To: <1409145083.35.0.252869476366.issue22290@psf.upfronthosting.co.za> Message-ID: <1409872296.75.0.697798580744.issue22290@psf.upfronthosting.co.za> STINNER Victor added the comment: I reproduced the crash with pyfailmalloc. The problem is that _posixsubprocess.fork_exec() calls gc.enable() on error when preexec_fn is set and the garbage collector was disabled (by fork_exec). Calling a function with an exception set is forbidden. Attached patch fixes this issue, but fix also error handling in fork_exec() and add some unit tests. ---------- keywords: +patch Added file: http://bugs.python.org/file36541/fork_exec.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 01:16:43 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 04 Sep 2014 23:16:43 +0000 Subject: [issue22290] "AMD64 OpenIndiana 3.x" buildbot: assertion failed in PyObject_Call() in test_subprocess.test_preexec() In-Reply-To: <1409145083.35.0.252869476366.issue22290@psf.upfronthosting.co.za> Message-ID: <3hpyZf6Qdqz7LjT@mail.python.org> Roundup Robot added the comment: New changeset 16e3d240456f by Victor Stinner in branch 'default': Issue #22290: PyObject_Call() now fails with an assertion error when called http://hg.python.org/cpython/rev/16e3d240456f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 01:27:17 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 04 Sep 2014 23:27:17 +0000 Subject: [issue22338] test_json crash on memory allocation failure Message-ID: <1409873237.86.0.801776520079.issue22338@psf.upfronthosting.co.za> New submission from STINNER Victor: Using pyfailmalloc, I'm able to reproduce the crash seen on a buildbot. Attached patch fixes two bugs in error handlers. http://buildbot.python.org/all/builders/AMD64%20OpenIndiana%203.x/builds/8557/steps/test/logs/stdio [191/390] test_urllib2net Fatal Python error: Segmentation fault Current thread 0x0000000000000001 (most recent call first): File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 317 in _iterencode_list File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 420 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 430 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 317 in _iterencode_list File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 420 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 430 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 317 in _iterencode_list File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 420 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 430 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 317 in _iterencode_list File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 420 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 430 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 317 in _iterencode_list File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 420 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 430 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 317 in _iterencode_list File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 420 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 430 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 317 in _iterencode_list File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 420 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 430 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 317 in _iterencode_list File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 420 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 430 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 317 in _iterencode_list File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 420 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 430 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 317 in _iterencode_list File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 420 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 430 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 317 in _iterencode_list File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 420 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 430 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 317 in _iterencode_list File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 420 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 430 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 317 in _iterencode_list File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 420 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 430 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 317 in _iterencode_list File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 420 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 430 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 317 in _iterencode_list File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 420 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 430 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 317 in _iterencode_list File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 420 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 430 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 317 in _iterencode_list File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 420 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 430 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 317 in _iterencode_list File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 420 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 430 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 317 in _iterencode_list File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 420 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 430 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 317 in _iterencode_list File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 420 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 430 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 317 in _iterencode_list File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 420 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 430 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 317 in _iterencode_list File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 420 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 430 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 317 in _iterencode_list File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 420 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 430 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 317 in _iterencode_list File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 420 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line[192/390] test_json 430 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 317 in _iterencode_list File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 420 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 430 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 317 in _iterencode_list File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 420 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 430 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 317 in _iterencode_list File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 420 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 430 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 317 in _iterencode_list File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 420 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 430 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 317 in _iterencode_list File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 420 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 430 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 317 in _iterencode_list File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 420 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 430 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 317 in _iterencode_list File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 420 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 430 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 317 in _iterencode_list File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 420 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 430 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 317 in _iterencode_list File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 420 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 430 in _iterencode File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/json/encoder.py", line 317 in _iterencode_list ... Traceback (most recent call last): File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/runpy.py", line 170, in _run_module_as_main "__main__", mod_spec) File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/runpy.py", line 85, in _run_code exec(code, run_globals) File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/__main__.py", line 3, in regrtest.main_in_temp_cwd() File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/regrtest.py", line 1564, in main_in_temp_cwd main() File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/regrtest.py", line 738, in main raise Exception("Child error on {}: {}".format(test, result[1])) Exception: Child error on test_json: Exit code -11 make: *** [buildbottest] Error 1 program finished with exit code 2 ---------- files: json.patch keywords: patch messages: 226390 nosy: haypo priority: normal severity: normal status: open title: test_json crash on memory allocation failure Added file: http://bugs.python.org/file36542/json.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 01:27:29 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 04 Sep 2014 23:27:29 +0000 Subject: [issue22338] test_json crash on memory allocation failure In-Reply-To: <1409873237.86.0.801776520079.issue22338@psf.upfronthosting.co.za> Message-ID: <1409873249.02.0.676652731142.issue22338@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- type: -> crash versions: +Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 01:28:19 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 04 Sep 2014 23:28:19 +0000 Subject: [issue22290] "AMD64 OpenIndiana 3.x" buildbot: assertion failed in PyObject_Call() in test_subprocess.test_preexec() In-Reply-To: <1409145083.35.0.252869476366.issue22290@psf.upfronthosting.co.za> Message-ID: <1409873299.65.0.323315451446.issue22290@psf.upfronthosting.co.za> STINNER Victor added the comment: > For example, test_json crashed with SIGSEGV in this build, probably because of an unhandled MemoryError exception: I created an issue for this bug: issue #22338. I proposed a fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 02:50:11 2014 From: report at bugs.python.org (=?utf-8?q?Kiss_Gy=C3=B6rgy?=) Date: Fri, 05 Sep 2014 00:50:11 +0000 Subject: [issue22339] Incorrect behavior when subclassing enum.Enum Message-ID: <1409878211.89.0.422808973529.issue22339@psf.upfronthosting.co.za> New submission from Kiss Gy?rgy: There is a small inconvenience in the ``enum`` module. When I subclass ``enum.Enum`` and redefine the ``value`` dynamic attribute, the aliasing behavior doesn't work correctly, because ``member.value`` is used in some places instead of ``member._value_``. I attached a patch where I fixed all these places. This causes no harm to the internal working, but makes subclassing behave correctly. ---------- components: Library (Lib) files: enum.patch keywords: patch messages: 226392 nosy: Walkman priority: normal severity: normal status: open title: Incorrect behavior when subclassing enum.Enum type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file36543/enum.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 02:56:55 2014 From: report at bugs.python.org (Ethan Furman) Date: Fri, 05 Sep 2014 00:56:55 +0000 Subject: [issue22339] Incorrect behavior when subclassing enum.Enum In-Reply-To: <1409878211.89.0.422808973529.issue22339@psf.upfronthosting.co.za> Message-ID: <1409878615.29.0.87714950969.issue22339@psf.upfronthosting.co.za> Ethan Furman added the comment: Can you give an example of the code you were having problems with? ---------- assignee: -> ethan.furman nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 02:57:14 2014 From: report at bugs.python.org (Ethan Furman) Date: Fri, 05 Sep 2014 00:57:14 +0000 Subject: [issue22339] Incorrect behavior when subclassing enum.Enum In-Reply-To: <1409878211.89.0.422808973529.issue22339@psf.upfronthosting.co.za> Message-ID: <1409878634.52.0.26827395059.issue22339@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +barry, eli.bendersky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 03:01:15 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 05 Sep 2014 01:01:15 +0000 Subject: [issue21933] Allow the user to change font sizes with the text pane of turtledemo In-Reply-To: <1404746295.5.0.877343308699.issue21933@psf.upfronthosting.co.za> Message-ID: <3hq0vG1tXdz7Ljk@mail.python.org> Roundup Robot added the comment: New changeset ecc98ea50bc3 by Terry Jan Reedy in branch '3.4': Issue #21933: Make Control-Mousewhell only change font size and not also scroll. http://hg.python.org/cpython/rev/ecc98ea50bc3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 03:02:05 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 05 Sep 2014 01:02:05 +0000 Subject: [issue21933] Allow the user to change font sizes with the text pane of turtledemo In-Reply-To: <1404746295.5.0.877343308699.issue21933@psf.upfronthosting.co.za> Message-ID: <1409878925.46.0.902305480458.issue21933@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 03:09:03 2014 From: report at bugs.python.org (=?utf-8?q?Kiss_Gy=C3=B6rgy?=) Date: Fri, 05 Sep 2014 01:09:03 +0000 Subject: [issue22339] Incorrect behavior when subclassing enum.Enum In-Reply-To: <1409878211.89.0.422808973529.issue22339@psf.upfronthosting.co.za> Message-ID: <1409879343.48.0.131364726482.issue22339@psf.upfronthosting.co.za> Kiss Gy?rgy added the comment: Yes, sorry I forgot about that. Here is a minimal example: from enum import EnumMeta, Enum from types import DynamicClassAttribute class _MultiMeta(EnumMeta): def __init__(enum_class, cls, bases, classdict): # make sure we only have tuple values, not single values for member in enum_class.__members__.values(): if not isinstance(member._value_, tuple): raise ValueError('{!r}, should be tuple'.format(member._value_)) def __call__(cls, suit): for member in cls: if suit in member._value_: return member return super().__call__(suit) class MultiValueEnum(Enum, metaclass=_MultiMeta): @DynamicClassAttribute def value(self): """The value of the Enum member.""" return self._value_[0] class IncorrectAliasBehavior(MultiValueEnum): first = 1, 2, 3 second = 4, 5, 6 alias_to_first = 1, 2, 3 When you call IncorrectAliasBehavior.alias_to_first, the documentation says it should return IncorrectAliasBehavior.first, but in this case it returns IncorrectAliasBehavior.alias_to_first, because canonical_member.value is referenced on line 162, and so it returns the redefined value, not the internally used one. This was very confusing for me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 04:10:34 2014 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Fri, 05 Sep 2014 02:10:34 +0000 Subject: [issue19461] RawConfigParser modifies empty strings unconditionally In-Reply-To: <1383240246.91.0.876276014549.issue19461@psf.upfronthosting.co.za> Message-ID: <1409883034.23.0.440432224032.issue19461@psf.upfronthosting.co.za> ?ukasz Langa added the comment: This bug has been fixed in Python 3.2 (see 892236137db9). Please use the configparser backport for Python 2.7. ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed type: enhancement -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 04:46:46 2014 From: report at bugs.python.org (Martin Panter) Date: Fri, 05 Sep 2014 02:46:46 +0000 Subject: [issue22253] ConfigParser does not handle files without sections In-Reply-To: <1408731768.17.0.221948826268.issue22253@psf.upfronthosting.co.za> Message-ID: <1409885206.05.0.614500643463.issue22253@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 04:51:16 2014 From: report at bugs.python.org (Martin Panter) Date: Fri, 05 Sep 2014 02:51:16 +0000 Subject: [issue17083] can't specify newline string for readline for binary files In-Reply-To: <1359570725.1.0.7766942653.issue17083@psf.upfronthosting.co.za> Message-ID: <1409885476.84.0.509382069816.issue17083@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 05:09:20 2014 From: report at bugs.python.org (Martin Panter) Date: Fri, 05 Sep 2014 03:09:20 +0000 Subject: [issue1152248] Add support for reading records with arbitrary separators to the standard IO stack Message-ID: <1409886560.36.0.0187009729695.issue1152248@psf.upfronthosting.co.za> Martin Panter added the comment: Related: * Issue 563491: 2002 proposal for parameter to readline, rejected at the time * Issue 17083: Newline is hard coded for binary file readline Fixing this issue for binary files would probably also satisfy Issue 17083. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 07:23:47 2014 From: report at bugs.python.org (Martin Panter) Date: Fri, 05 Sep 2014 05:23:47 +0000 Subject: [issue1243678] httplib gzip support Message-ID: <1409894627.02.0.688386069826.issue1243678@psf.upfronthosting.co.za> Martin Panter added the comment: Agreed, this issue is not a duplicate of the marked ?gzip? seek issue, however it _does_ duplicate Issue 1508475. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 07:45:04 2014 From: report at bugs.python.org (Martin Panter) Date: Fri, 05 Sep 2014 05:45:04 +0000 Subject: [issue1508475] transparent gzip compression in urllib Message-ID: <1409895904.28.0.250642856025.issue1508475@psf.upfronthosting.co.za> Martin Panter added the comment: Related: Issue 1243678, which includes a patch for ?httplib? (now known as ?http.client??). That patch looks like it sets Accept-Encoding and decodes according to Content-Encoding. However I suspect it is also trying to be too ?transparent? at the wrong level and would have many of the problems already mentioned here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 08:15:51 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 05 Sep 2014 06:15:51 +0000 Subject: [issue21951] tcl test change crashes AIX In-Reply-To: <1405013926.74.0.877232363604.issue21951@psf.upfronthosting.co.za> Message-ID: <1409897751.15.0.428846300757.issue21951@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The patch can be simpler. And there is yet one similar bug, for unicode strings. ---------- Added file: http://bugs.python.org/file36544/asobj_empty_sequence_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 08:24:23 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 05 Sep 2014 06:24:23 +0000 Subject: [issue20912] [zipfile.py]: Make zip directory attributes more friendly for MS-Windows In-Reply-To: <1394729062.0.0.517393567539.issue20912@psf.upfronthosting.co.za> Message-ID: <1409898263.92.0.25521937449.issue20912@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If there are no objections I'll commit the patch soon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 08:56:38 2014 From: report at bugs.python.org (Martin Panter) Date: Fri, 05 Sep 2014 06:56:38 +0000 Subject: [issue21228] Missing enumeration of HTTPResponse Objects methods of urllib.request.urlopen's http.client.HTTPResponse? In-Reply-To: <1397520483.48.0.224250148615.issue21228@psf.upfronthosting.co.za> Message-ID: <1409900198.9.0.291598985745.issue21228@psf.upfronthosting.co.za> Martin Panter added the comment: With this patch, there is no longer any implication that the returned object implements the ?addinfourl? interface. Perhaps that should be added back. Or maybe add it to the HTTPResponse class documentation itself? There is a comment that says the methods are there ?for compatibility with old-style urllib responses?, although it seems to me they also make the class compatible with Python 3?s new ?urllib?: http://hg.python.org/cpython/file/c499cc2c4a06/Lib/http/client.py#l772 It is good to document the ?msg? attribute and its inconsistency, since I have found this is required to implement your own BaseHandler.default_open(). However I?m not so sure if it is necessary to document the ?url? attribute. Why not encourage using geturl() instead, since it is already documented, at least for non-HTTP responses? I also saw a comment against the ?msg? attribute which mentions deprecating something, but it is not clear what: http://hg.python.org/cpython/file/c499cc2c4a06/Lib/urllib/request.py#l1187 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 09:07:03 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 05 Sep 2014 07:07:03 +0000 Subject: [issue22215] "embedded NUL character" exceptions In-Reply-To: <1408286635.01.0.343838296034.issue22215@psf.upfronthosting.co.za> Message-ID: <1409900823.29.0.771778843834.issue22215@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If there are no objections I'll commit the patch soon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 09:26:25 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 05 Sep 2014 07:26:25 +0000 Subject: [issue18960] First line can be executed twice In-Reply-To: <1378559493.77.0.649785663787.issue18960@psf.upfronthosting.co.za> Message-ID: <3hq9Rh3MLWz7LlH@mail.python.org> Roundup Robot added the comment: New changeset dd1e21f17b1c by Serhiy Storchaka in branch '2.7': Issue #22221: Backported fixes from Python 3 (issue #18960). http://hg.python.org/cpython/rev/dd1e21f17b1c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 09:26:24 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 05 Sep 2014 07:26:24 +0000 Subject: [issue22221] ast.literal_eval confused by coding declarations In-Reply-To: <1408305229.31.0.808680198001.issue22221@psf.upfronthosting.co.za> Message-ID: <3hq9Rg5Nwzz7Lkk@mail.python.org> Roundup Robot added the comment: New changeset dd1e21f17b1c by Serhiy Storchaka in branch '2.7': Issue #22221: Backported fixes from Python 3 (issue #18960). http://hg.python.org/cpython/rev/dd1e21f17b1c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 10:07:41 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 05 Sep 2014 08:07:41 +0000 Subject: [issue22226] Refactor dict result handling in Tkinter In-Reply-To: <1408428974.08.0.266954995149.issue22226@psf.upfronthosting.co.za> Message-ID: <1409904461.07.0.148062232379.issue22226@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If there are no objections I'll commit the patch soon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 10:11:59 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 05 Sep 2014 08:11:59 +0000 Subject: [issue22221] ast.literal_eval confused by coding declarations In-Reply-To: <1408305229.31.0.808680198001.issue22221@psf.upfronthosting.co.za> Message-ID: <3hqBSG3H5pz7Ljf@mail.python.org> Roundup Robot added the comment: New changeset 13cd8ea4cafe by Serhiy Storchaka in branch '3.4': Issue #22221: Add tests for compile() with source encoding cookie. http://hg.python.org/cpython/rev/13cd8ea4cafe New changeset 9d335a54d728 by Serhiy Storchaka in branch 'default': Issue #22221: Add tests for compile() with source encoding cookie. http://hg.python.org/cpython/rev/9d335a54d728 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 10:26:26 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 05 Sep 2014 08:26:26 +0000 Subject: [issue22219] python -mzipfile fails to add empty folders to created zip In-Reply-To: <1408298025.49.0.964091160745.issue22219@psf.upfronthosting.co.za> Message-ID: <1409905586.09.0.418368781566.issue22219@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If there are no objections I'll commit the patch soon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 10:28:33 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 05 Sep 2014 08:28:33 +0000 Subject: [issue15513] Correct __sizeof__ support for pickle In-Reply-To: <1343723739.69.0.648602242607.issue15513@psf.upfronthosting.co.za> Message-ID: <1409905713.28.0.662503708282.issue15513@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If there are no objections I'll commit the patch soon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 10:28:34 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 05 Sep 2014 08:28:34 +0000 Subject: [issue22221] ast.literal_eval confused by coding declarations In-Reply-To: <1408305229.31.0.808680198001.issue22221@psf.upfronthosting.co.za> Message-ID: <1409905714.77.0.358969394741.issue22221@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 10:56:51 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 05 Sep 2014 08:56:51 +0000 Subject: [issue22215] "embedded NUL character" exceptions In-Reply-To: <1408286635.01.0.343838296034.issue22215@psf.upfronthosting.co.za> Message-ID: <1409907411.08.0.35468479469.issue22215@psf.upfronthosting.co.za> STINNER Victor added the comment: > If there are no objections I'll commit the patch soon. Replacing TypeError with ValueError is fine. TypeError was a bad choice. If an application relies on TypeError to check for null character, it's easy to replace "except TypeError:" with "except (TypeError, ValueError):" to stay compatible with Python < 3.5. Instead of "NUL character" (and "NUL byte), I had prefer "null character" (and "null byte"): http://en.wikipedia.org/wiki/Null_character I talking about the error message because you changed it in a few places. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 10:57:48 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 05 Sep 2014 08:57:48 +0000 Subject: [issue22215] "embedded NUL character" exceptions In-Reply-To: <1408286635.01.0.343838296034.issue22215@psf.upfronthosting.co.za> Message-ID: <1409907468.88.0.40994045437.issue22215@psf.upfronthosting.co.za> STINNER Victor added the comment: You may also take a look at these 2 issues: #13617 and #21147 (not directly related to this oe). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 11:25:55 2014 From: report at bugs.python.org (Jonas Wagner) Date: Fri, 05 Sep 2014 09:25:55 +0000 Subject: [issue5309] distutils doesn't parallelize extension module compilation In-Reply-To: <1235007592.93.0.0598331575131.issue5309@psf.upfronthosting.co.za> Message-ID: <1409909155.03.0.701549327045.issue5309@psf.upfronthosting.co.za> Changes by Jonas Wagner : ---------- nosy: +Sjlver _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 11:48:25 2014 From: report at bugs.python.org (Jonas Wagner) Date: Fri, 05 Sep 2014 09:48:25 +0000 Subject: [issue5309] distutils doesn't parallelize extension module compilation In-Reply-To: <1235007592.93.0.0598331575131.issue5309@psf.upfronthosting.co.za> Message-ID: <1409910505.04.0.964360259347.issue5309@psf.upfronthosting.co.za> Jonas Wagner added the comment: Is there a reason this has not landed? The patch works perfectly for me, except for one issue: @@ -268,6 +275,9 @@ if self.undef: self.undef = self.undef.split(',') + if self.parallel: + self.parallel = int(self.parallel) + if self.swig_opts is None: self.swig_opts = [] else: If self.parallel is True, this will set self.parallel to 1, causing it to use one worker instead of n (where n is the number of processors). An updated patch is attached. ---------- Added file: http://bugs.python.org/file36545/build_ext_parallel4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 11:50:37 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 05 Sep 2014 09:50:37 +0000 Subject: [issue22215] "embedded NUL character" exceptions In-Reply-To: <1408286635.01.0.343838296034.issue22215@psf.upfronthosting.co.za> Message-ID: <1409910637.03.0.89594560688.issue22215@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Victor. Here is a patch which is synchronized with the tip and addresses your comment about a null character. ---------- Added file: http://bugs.python.org/file36546/valueerror_embedded_nul_character_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 11:51:09 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 05 Sep 2014 09:51:09 +0000 Subject: [issue13617] Reject embedded null characters in wchar* strings In-Reply-To: <1324094022.4.0.746327138354.issue13617@psf.upfronthosting.co.za> Message-ID: <1409910669.04.0.0906841795521.issue13617@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you please answer my comments Victor? ---------- versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 11:54:23 2014 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 05 Sep 2014 09:54:23 +0000 Subject: [issue5309] distutils doesn't parallelize extension module compilation In-Reply-To: <1235007592.93.0.0598331575131.issue5309@psf.upfronthosting.co.za> Message-ID: <1409910863.33.0.477691549278.issue5309@psf.upfronthosting.co.za> Stefan Behnel added the comment: Yes, please. The sequential build in distutils is very annoying. (too late for Py3.4, though, I guess...) ---------- nosy: +scoder versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 12:02:58 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 05 Sep 2014 10:02:58 +0000 Subject: [issue21147] sqlite3 doesn't complain if the request contains a null character In-Reply-To: <1396544845.43.0.82545828662.issue21147@psf.upfronthosting.co.za> Message-ID: <1409911378.8.0.84545319715.issue21147@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Added a comment on Rietveld. ---------- components: +Extension Modules nosy: +serhiy.storchaka stage: -> needs patch type: -> behavior versions: +Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 12:09:06 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 05 Sep 2014 10:09:06 +0000 Subject: [issue22220] Ttk extensions test failure In-Reply-To: <1408301671.8.0.626599352152.issue22220@psf.upfronthosting.co.za> Message-ID: <1409911746.27.0.0157590970165.issue22220@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Looks as all builds since #415 are successful. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 12:45:10 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 05 Sep 2014 10:45:10 +0000 Subject: [issue22340] Fix Python 3 warnings in Python 2 tests Message-ID: <1409913910.6.0.350974401324.issue22340@psf.upfronthosting.co.za> New submission from STINNER Victor: Running Python 2 test suite with "python -3 -Wd" displays a lot of DeprecationWarning warnings. Just one example: /home/haypo/prog/python/2.7/Lib/test/test_ssl.py:2368: DeprecationWarning: urllib.urlopen() has been removed in Python 3.0 in favor of urllib2.urlopen() Attached patch fix most of them (maybe all). ---------- components: Tests files: fix_py3k_warn.patch keywords: patch messages: 226418 nosy: haypo priority: normal severity: normal status: open title: Fix Python 3 warnings in Python 2 tests versions: Python 2.7 Added file: http://bugs.python.org/file36547/fix_py3k_warn.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 13:55:29 2014 From: report at bugs.python.org (Martin Panter) Date: Fri, 05 Sep 2014 11:55:29 +0000 Subject: [issue22341] Python 3 crc32 documentation clarifications Message-ID: <1409918129.4.0.321897542374.issue22341@psf.upfronthosting.co.za> New submission from Martin Panter: This is regarding the Python 3 documentation for binascii.crc32(), . It repeatedly recommends correcting the sign by doing crc32() & 0xFFFFFFFF, but it is not immediately clear why. Only after reading the Python 2 documentation does one realise that the value is always unsigned for Python 3, so you only really need the workaround if you want to support earlier Pythons. I also suggest documenting the initial CRC input value, which is zero. Suggested wording: binascii.crc32(data[, crc]) Compute CRC-32, the 32-bit checksum of ?data?, starting with the given ?crc?. The default initial value is zero. The algorithm is consistent with the ZIP file checksum. Since the algorithm is designed for use as a checksum algorithm, it is not suitable for use as a general hash algorithm. Use as follows: print(binascii.crc32(b"hello world")) # Or, in two pieces: crc = binascii.crc32(b"hello", 0) crc = binascii.crc32(b" world", crc) print('crc32 = {:#010x}'.format(crc)) I would simply drop the notice box with the workaround, because I gather that the Python 3 documentation generally omits Python 2 details. (There are no ?new in version 2.4 tags? for instance.) Otherwise, clarify if ?packed binary format? is a reference to the ?struct? module, or something else. Similar fixes are probably appropriate for zlib.crc32() and zlib.alder32(). Also, what is the relationship between binascii.crc32() and zlib.crc32()? I vaguely remember reading that ?zlib? is not always available, so I tend to use ?binascii? instead. Is there any advantage in using the ?zlib? version? The ?hashlib? documentation points to ?zlib? without mentioning ?binascii? at all. ---------- assignee: docs at python components: Documentation messages: 226419 nosy: docs at python, vadmium priority: normal severity: normal status: open title: Python 3 crc32 documentation clarifications versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 14:34:11 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 05 Sep 2014 12:34:11 +0000 Subject: [issue21866] zipfile.ZipFile.close() doesn't respect allowZip64 In-Reply-To: <1403675769.56.0.836465783864.issue21866@psf.upfronthosting.co.za> Message-ID: <1409920451.3.0.61810864976.issue21866@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Benjamin for explanation. Here is a patch which adds all three required checks in the close() method and adds a check for files count in write methods. Implementing other checks in write methods is too laborious. As far as test_zipfile64 is disabled, for manual testing you need temporary comment out the "support.requires()" statement and run only selected tests: ./python -m test.regrtest -v -m OtherTests test_zipfile64 ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file36548/zipfile64_additional_checks.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 14:36:53 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 05 Sep 2014 12:36:53 +0000 Subject: [issue22340] Fix Python 3 warnings in Python 2 tests In-Reply-To: <1409913910.6.0.350974401324.issue22340@psf.upfronthosting.co.za> Message-ID: <1409920613.49.0.0685280763015.issue22340@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Why test_support.check_py3k_warnings is not used in test_calltips.py? Or may be change the test to "1+0", "1//0" or "1.0/0.0"? ---------- nosy: +serhiy.storchaka, terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 14:59:04 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 05 Sep 2014 12:59:04 +0000 Subject: [issue13968] Support recursive globs In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za> Message-ID: <1409921944.71.0.128591891565.issue13968@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you make a review Nick? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 15:45:12 2014 From: report at bugs.python.org (mirabilos) Date: Fri, 05 Sep 2014 13:45:12 +0000 Subject: [issue22187] commands.mkarg() buggy in East Asian locales In-Reply-To: <1407867185.09.0.871560290901.issue22187@psf.upfronthosting.co.za> Message-ID: <1409924712.74.0.553183656548.issue22187@psf.upfronthosting.co.za> mirabilos added the comment: Just for the record, please do not assume all shells behave like GNU bash. ---------- nosy: +mirabilos _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 15:59:52 2014 From: report at bugs.python.org (Jonas Wagner) Date: Fri, 05 Sep 2014 13:59:52 +0000 Subject: [issue5309] distutils doesn't parallelize extension module compilation In-Reply-To: <1235007592.93.0.0598331575131.issue5309@psf.upfronthosting.co.za> Message-ID: <1409925592.81.0.329155365866.issue5309@psf.upfronthosting.co.za> Jonas Wagner added the comment: With this patch, and on Ubuntu 14.04, occasionally modules fail to build with the following error: *** WARNING: renaming "_testbuffer" since importing it failed: dlopen: cannot load any more object with static TLS I'm not 100% sure if this is really due to the patch... but I've never seen it before. I'll try investigate a bit more. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 16:12:14 2014 From: report at bugs.python.org (Gael Robin) Date: Fri, 05 Sep 2014 14:12:14 +0000 Subject: [issue22342] Fix typo in PEP 380 -- Syntax for Delegating to a Subgenerator Message-ID: <1409926334.06.0.657946256906.issue22342@psf.upfronthosting.co.za> New submission from Gael Robin: The first line of the Refactoring Principle subsection of the Rationale section contains the following typo : "It should be possible to take an section of code" should be "It should be possible to take a section of code" ---------- assignee: docs at python components: Documentation messages: 226425 nosy: Gael.Robin, docs at python priority: normal severity: normal status: open title: Fix typo in PEP 380 -- Syntax for Delegating to a Subgenerator type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 17:49:50 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 05 Sep 2014 15:49:50 +0000 Subject: [issue22187] commands.mkarg() buggy in East Asian locales In-Reply-To: <1407867185.09.0.871560290901.issue22187@psf.upfronthosting.co.za> Message-ID: <1409932190.08.0.42195426563.issue22187@psf.upfronthosting.co.za> R. David Murray added the comment: That is true, but sh-alikes (posix standard) are the only ones we support in commands. subprocess (which commands was folded in to in python3) also supports windows cmd to the extent we've managed, but that's all we are committed to support. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 18:32:59 2014 From: report at bugs.python.org (Steve Dower) Date: Fri, 05 Sep 2014 16:32:59 +0000 Subject: [issue22302] Windows os.path.isabs UNC path bug In-Reply-To: <1409349502.55.0.177656049078.issue22302@psf.upfronthosting.co.za> Message-ID: <1409934779.24.0.465216104827.issue22302@psf.upfronthosting.co.za> Steve Dower added the comment: Antoine almost certainly thought about this with pathlib and may know about the change, or at least have some decent context on it. I'm more inclined to think that os.path.isabs(r"\\server") should also return False, since it's not a path that can be opened directly unless you add more path before or after it. Indeed, pathlib seems to support my understanding: >>> Path('//server').is_absolute() False >>> Path('//server/share').is_absolute() True >>> Path('//server/share/').is_absolute() True >>> Path('//server/share/file').is_absolute() True If the regression appeared in 3.4, it should be easy enough to look at what changed. ---------- nosy: +pitrou, steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 18:51:28 2014 From: report at bugs.python.org (Steve Dower) Date: Fri, 05 Sep 2014 16:51:28 +0000 Subject: [issue22299] resolve() on Windows makes some pathological paths unusable In-Reply-To: <1409318228.27.0.489471733533.issue22299@psf.upfronthosting.co.za> Message-ID: <1409935888.14.0.359138145124.issue22299@psf.upfronthosting.co.za> Steve Dower added the comment: Patch attached. (Kinda feel like this was too simple...) ---------- keywords: +patch Added file: http://bugs.python.org/file36549/22299_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 18:52:14 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 05 Sep 2014 16:52:14 +0000 Subject: [issue22302] Windows os.path.isabs UNC path bug In-Reply-To: <1409349502.55.0.177656049078.issue22302@psf.upfronthosting.co.za> Message-ID: <1409935934.46.0.712030389339.issue22302@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Under Windows, pathlib's "absolute" means a fully qualified path as defined in http://msdn.microsoft.com/en-us/library/aa365247%28v=vs.85%29.aspx >>> PureWindowsPath("c:").is_absolute() False >>> PureWindowsPath("/").is_absolute() False >>> PureWindowsPath("c:/").is_absolute() True The fact that "//server" isn't considered absolute is a bug in pathlib, since "//server/" is: >>> PureWindowsPath("//foo").is_absolute() False >>> PureWindowsPath("//foo/").is_absolute() True I agree that it's not really important, since both aren't actual paths (in the sense that they may not point to anything, AFAIK). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 19:16:57 2014 From: report at bugs.python.org (Steve Dower) Date: Fri, 05 Sep 2014 17:16:57 +0000 Subject: [issue22302] Windows os.path.isabs UNC path bug In-Reply-To: <1409349502.55.0.177656049078.issue22302@psf.upfronthosting.co.za> Message-ID: <1409937417.18.0.261922593267.issue22302@psf.upfronthosting.co.za> Steve Dower added the comment: My experience says the main reason people want to know whether the path is absolute is to figure out whether to do `Path.cwd() / path` or not. According to that MSDN page, they shouldn't because the path starts with "//" (that is, the last character and the existence of the share name are irrelevant here). Both pathlib and ntpath are reasonably consistent in determining the "drive" of the path: >>> splitdrive('\\\\server\\')[0] '\\\\server\\' >>> splitdrive('\\\\server')[0] '' >>> Path('\\\\server\\').parts[0] '\\\\server\\\\' >>> Path('\\\\server').parts[0] '\\' I assume the bug in the last statement is what Antoine is referring to. The difference in results then comes from how they determine roots. >>> splitdrive('\\\\server\\')[1] '' >>> splitdrive('\\\\server')[1] '\\\\server' >>> Path('//server/').root '\\' >>> Path('//server').root '\\' Pathlib always has a root, but splitdrive doesn't. I'm not sure exactly which one to fix where, but hopefully that helps someone else figure it out. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 19:17:17 2014 From: report at bugs.python.org (eryksun) Date: Fri, 05 Sep 2014 17:17:17 +0000 Subject: [issue22299] resolve() on Windows makes some pathological paths unusable In-Reply-To: <1409318228.27.0.489471733533.issue22299@psf.upfronthosting.co.za> Message-ID: <1409937437.67.0.412240645971.issue22299@psf.upfronthosting.co.za> eryksun added the comment: It should only skip _ext_to_normal for an already extended path, i.e. a path that starts with ext_namespace_prefix. Otherwise it needs to call _ext_to_normal. For example: Strip the prefix in this case: >>> os.path._getfinalpathname('C:\\Windows') '\\\\?\\C:\\Windows' but not in this case: >>> os.path._getfinalpathname(r'\\?\GLOBALROOT\Device\HarddiskVolume1\Windows') '\\\\?\\C:\\Windows' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 19:18:25 2014 From: report at bugs.python.org (Steve Dower) Date: Fri, 05 Sep 2014 17:18:25 +0000 Subject: [issue22302] Windows os.path.isabs UNC path bug In-Reply-To: <1409349502.55.0.177656049078.issue22302@psf.upfronthosting.co.za> Message-ID: <1409937505.07.0.919014905542.issue22302@psf.upfronthosting.co.za> Steve Dower added the comment: Just did a double-take, but that output for Path('\\\\server\\').parts[0] is actually correct... >>> Path('\\\\server\\').parts[0] '\\\\server\\\\' >>> print(Path('\\\\server\\').parts[0]) \\server\\ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 19:20:10 2014 From: report at bugs.python.org (Steve Dower) Date: Fri, 05 Sep 2014 17:20:10 +0000 Subject: [issue22299] resolve() on Windows makes some pathological paths unusable In-Reply-To: <1409318228.27.0.489471733533.issue22299@psf.upfronthosting.co.za> Message-ID: <1409937610.44.0.547696259687.issue22299@psf.upfronthosting.co.za> Steve Dower added the comment: Ah, thought it was too simple. I didn't realise that _getfinalpathname adds the prefix. New patch soon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 19:30:24 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 05 Sep 2014 17:30:24 +0000 Subject: [issue22302] Windows os.path.isabs UNC path bug In-Reply-To: <1409349502.55.0.177656049078.issue22302@psf.upfronthosting.co.za> Message-ID: <1409938224.51.0.82911858385.issue22302@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It looks to me that rather handling of "//server/" is buggy than "//server". "//server" is just the same as "/server" or "///server". But "//server/" looks as an UNC path with empty ("") mount point. This is invalid path and we can't create valid path from this path by adding components. Perhaps PureWindowsPath("//server/") should raise an exception. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 19:33:44 2014 From: report at bugs.python.org (Steve Dower) Date: Fri, 05 Sep 2014 17:33:44 +0000 Subject: [issue22299] resolve() on Windows makes some pathological paths unusable In-Reply-To: <1409318228.27.0.489471733533.issue22299@psf.upfronthosting.co.za> Message-ID: <1409938424.13.0.51330166401.issue22299@psf.upfronthosting.co.za> Steve Dower added the comment: Strips the prefix if it wasn't in the original path - otherwise, keeps it. ---------- Added file: http://bugs.python.org/file36550/22299_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 20:06:25 2014 From: report at bugs.python.org (eryksun) Date: Fri, 05 Sep 2014 18:06:25 +0000 Subject: [issue22302] Windows os.path.isabs UNC path bug In-Reply-To: <1409349502.55.0.177656049078.issue22302@psf.upfronthosting.co.za> Message-ID: <1409940385.2.0.239215600598.issue22302@psf.upfronthosting.co.za> eryksun added the comment: Isn't this bug about the "root of a share" case with ntpath.isabs in 3.x and 2.7 (splitdrive was backported)? For example: >>> os.path.isabs("//server/share") False >>> os.path.splitdrive('//server/share') ('//server/share', '') vs. >>> os.path.isabs('//server/share/') True >>> os.path.splitdrive('//server/share/') ('//server/share', '/') I think '//server/share' is an absolute path, and pathlib agrees. Network shares do not maintain a current directory the way drives do (i.e. the hidden environment variable trick). There's no such thing as a share-relative path, nor would there be any way to even write such a path, as compared to "C:drive/relative/path". ---------- versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 20:09:31 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 05 Sep 2014 18:09:31 +0000 Subject: [issue22340] Fix Python 3 warnings in Python 2 tests In-Reply-To: <1409913910.6.0.350974401324.issue22340@psf.upfronthosting.co.za> Message-ID: <1409940571.71.0.81544152742.issue22340@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Please just change '1/0' to '1//0'. Any expression that raises something other than NameError or AttributeError will do. .get_entity evals user code and Idle previously crashed when other exceptions were not caught. Thanks, Serhiy, for catching this. The other warned code appears to be essential to the corresponding test. I presume Serhiy checked this also. ---------- assignee: -> haypo stage: -> patch review type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 20:10:00 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 05 Sep 2014 18:10:00 +0000 Subject: [issue4945] json checks True/False by identity, not boolean value In-Reply-To: <1231911098.49.0.621266929609.issue4945@psf.upfronthosting.co.za> Message-ID: <1409940600.09.0.441193709092.issue4945@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 20:11:26 2014 From: report at bugs.python.org (Mark Lawrence) Date: Fri, 05 Sep 2014 18:11:26 +0000 Subject: [issue900092] hotshot.stats.load fails with AssertionError Message-ID: <1409940686.5.0.348446751036.issue900092@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- versions: +Python 2.7 -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 20:18:40 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 05 Sep 2014 18:18:40 +0000 Subject: [issue22340] Fix Python 3 warnings in Python 2 tests In-Reply-To: <1409913910.6.0.350974401324.issue22340@psf.upfronthosting.co.za> Message-ID: <1409941120.85.0.928997509621.issue22340@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The rest of the patch LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 20:27:33 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 05 Sep 2014 18:27:33 +0000 Subject: [issue17651] Errno checking replaced by concrete classes inherited from OSError In-Reply-To: <1365354742.46.0.363482089834.issue17651@psf.upfronthosting.co.za> Message-ID: <1409941653.5.0.271708526195.issue17651@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: -> needs patch versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 20:34:17 2014 From: report at bugs.python.org (Jakub Wilk) Date: Fri, 05 Sep 2014 18:34:17 +0000 Subject: [issue22187] commands.mkarg() buggy in East Asian locales In-Reply-To: <1407867185.09.0.871560290901.issue22187@psf.upfronthosting.co.za> Message-ID: <1409942057.01.0.138350053734.issue22187@psf.upfronthosting.co.za> Jakub Wilk added the comment: I think what mirabilos meant (and what I should have mentioned in my initial message) is that even sh-alikes don't necessarily behave the same way as bash: $ bash test.sh ? $ ksh test.sh ? $ dash test.sh test.sh: 2: test.sh: Syntax error: Unterminated quoted string $ mksh test.sh test.sh[2]: no closing quote $ posh test.sh test.sh:2: no closing quote ---------- Added file: http://bugs.python.org/file36551/test.sh _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 20:47:31 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 05 Sep 2014 18:47:31 +0000 Subject: [issue22302] Windows os.path.isabs UNC path bug In-Reply-To: <1409349502.55.0.177656049078.issue22302@psf.upfronthosting.co.za> Message-ID: <1409942851.51.0.121390524289.issue22302@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Serhiy, you may be right. I'd suggest opening a python-dev discussion to gather more feedback. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 20:52:08 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 05 Sep 2014 18:52:08 +0000 Subject: [issue22299] resolve() on Windows makes some pathological paths unusable In-Reply-To: <1409318228.27.0.489471733533.issue22299@psf.upfronthosting.co.za> Message-ID: <1409943128.32.0.626744624905.issue22299@psf.upfronthosting.co.za> Antoine Pitrou added the comment: As far as I can say, the patch looks fine to me. Thanks, Steve. ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 21:09:04 2014 From: report at bugs.python.org (Mark Lawrence) Date: Fri, 05 Sep 2014 19:09:04 +0000 Subject: [issue8840] truncate() semantics changed in 3.1.2 In-Reply-To: <1275005546.82.0.0795236723796.issue8840@psf.upfronthosting.co.za> Message-ID: <1409944144.06.0.724352216197.issue8840@psf.upfronthosting.co.za> Mark Lawrence added the comment: Can this be closed or what? ---------- versions: +Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 21:09:05 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 05 Sep 2014 19:09:05 +0000 Subject: [issue22340] Fix Python 3 warnings in Python 2 tests In-Reply-To: <1409913910.6.0.350974401324.issue22340@psf.upfronthosting.co.za> Message-ID: <3hqT2N25jGz7LkP@mail.python.org> Roundup Robot added the comment: New changeset 0675b3a55941 by Victor Stinner in branch '2.7': Issue #22340: Fix Python 3 warnings in Python 2 tests http://hg.python.org/cpython/rev/0675b3a55941 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 21:09:11 2014 From: report at bugs.python.org (eryksun) Date: Fri, 05 Sep 2014 19:09:11 +0000 Subject: [issue22302] Windows os.path.isabs UNC path bug In-Reply-To: <1409349502.55.0.177656049078.issue22302@psf.upfronthosting.co.za> Message-ID: <1409944151.66.0.302551005407.issue22302@psf.upfronthosting.co.za> eryksun added the comment: > "//server" is just the same as "/server" or "///server". Repeated slashes aren't collapsed at the start of a Windows path. Here's what I get in Windows 7: >>> os.listdir('/server') [] >>> os.listdir('//server') Traceback (most recent call last): File "", line 1, in FileNotFoundError: [WinError 53] The network path was not found: '//server' >>> os.listdir('///server') Traceback (most recent call last): File "", line 1, in FileNotFoundError: [WinError 161] The specified path is invalid: '///server' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 21:11:45 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 05 Sep 2014 19:11:45 +0000 Subject: [issue22340] Fix Python 3 warnings in Python 2 tests In-Reply-To: <1409913910.6.0.350974401324.issue22340@psf.upfronthosting.co.za> Message-ID: <1409944305.81.0.764184327391.issue22340@psf.upfronthosting.co.za> STINNER Victor added the comment: Ok, I replaced 1/0 with 1//0 in IDLE tests. I also changed the context manager in test_collections, the sets module is just deprecated, it's not a Python 3 specific warning. Thanks for the review Serhiy. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 21:11:56 2014 From: report at bugs.python.org (Mark Lawrence) Date: Fri, 05 Sep 2014 19:11:56 +0000 Subject: [issue15934] flaky test in test_ftplib In-Reply-To: <1347466895.7.0.169569796798.issue15934@psf.upfronthosting.co.za> Message-ID: <1409944316.88.0.633124339381.issue15934@psf.upfronthosting.co.za> Mark Lawrence added the comment: Surely a test issue can be closed after two years? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 21:34:47 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 05 Sep 2014 19:34:47 +0000 Subject: [issue22226] Refactor dict result handling in Tkinter In-Reply-To: <1408428974.08.0.266954995149.issue22226@psf.upfronthosting.co.za> Message-ID: <1409945687.89.0.99288950548.issue22226@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I made two style comments, one an expansion of a previous comment. I believe all other previous comments were handled ok. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 21:41:35 2014 From: report at bugs.python.org (Lauri Tirkkonen) Date: Fri, 05 Sep 2014 19:41:35 +0000 Subject: [issue896330] pyconfig.h is not placed in --includedir Message-ID: <1409946095.48.0.938978408436.issue896330@psf.upfronthosting.co.za> Lauri Tirkkonen added the comment: Patch attached to set CONFINCLUDEDIR to --includedir. There's additionally some hardcoded assumptions in sysconfig and distutils.sysconfig about the include paths, of which this patch fixes some. What it doesn't address is sysconfig.get_path with 'include' or 'platinclude'. There 'include', however, were already broken if python was configured with --includedir ('platinclude' was correct because it was hardcoded, and pyconfig.h always installed to the same place). I think those should also be fixable by getting the correct directories from _sysconfigdata instead of hardcoding possible 'installation schemes' and trying some de-facto paths based on those. I suspect this is also a problem for library paths, but this issue is only concerned with includedir. I suspect the problem that 'CONFINCLUDEDIR' was trying to solve is separating platform-dependent headers from platform-independent ones, but it doesn't actually solve that problem correctly: pyconfig.h does not go in --includedir AND the hardcoded include path for pyconfig.h doesn't go in "python-config --includes" output. ---------- keywords: +patch nosy: +lotheac Added file: http://bugs.python.org/file36552/pyconfig-includedir.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 21:41:37 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 05 Sep 2014 19:41:37 +0000 Subject: [issue22340] Fix Python 3 warnings in Python 2 tests In-Reply-To: <1409913910.6.0.350974401324.issue22340@psf.upfronthosting.co.za> Message-ID: <3hqTm02jXrz7LmH@mail.python.org> Roundup Robot added the comment: New changeset 407653078135 by Victor Stinner in branch '2.7': Issue #22340: Fix test_collections if the sets module was already imported http://hg.python.org/cpython/rev/407653078135 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 21:47:11 2014 From: report at bugs.python.org (Ben Roberts) Date: Fri, 05 Sep 2014 19:47:11 +0000 Subject: [issue22192] dict_values objects are hashable In-Reply-To: <1407963163.14.0.392361410258.issue22192@psf.upfronthosting.co.za> Message-ID: <1409946431.42.0.436198554085.issue22192@psf.upfronthosting.co.za> Ben Roberts added the comment: Going to close this down - implementing rich comparisons for values() does feel like the correct solution... but I don't think it's possible to implement __eq__ in better than nlogn time (and possibly space). So nothing can realistically be done, yeah. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 22:07:49 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 05 Sep 2014 20:07:49 +0000 Subject: [issue8840] truncate() semantics changed in 3.1.2 In-Reply-To: <1275005546.82.0.0795236723796.issue8840@psf.upfronthosting.co.za> Message-ID: <1409947669.17.0.252551830935.issue8840@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The docstring is unchanged from before the behavior change and to me still has problems a. to d. listed in msg106698. The manual entry seems too longs to just copy, but I would not know know to condense it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 22:24:08 2014 From: report at bugs.python.org (Kevin Christopher Henry) Date: Fri, 05 Sep 2014 20:24:08 +0000 Subject: [issue22343] Install bash activate script on Windows when using venv Message-ID: <1409948648.7.0.892236136888.issue22343@psf.upfronthosting.co.za> New submission from Kevin Christopher Henry: When I use venv to create a new virtual environment in Windows I'm given two activate scripts, a .bat file and a .ps1 file (which is consistent with the documentation). However, bash (and probably the other shells as well) works just fine in Windows under Cygwin. Since you have these scripts anyway, please include them in the Windows virtual environment (as virtualenv did). ---------- components: Windows messages: 226452 nosy: marfire priority: normal severity: normal status: open title: Install bash activate script on Windows when using venv type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 22:28:57 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 05 Sep 2014 20:28:57 +0000 Subject: [issue22342] Fix typo in PEP 380 -- Syntax for Delegating to a Subgenerator In-Reply-To: <1409926334.06.0.657946256906.issue22342@psf.upfronthosting.co.za> Message-ID: <3hqVpc3MMpz7LkP@mail.python.org> Roundup Robot added the comment: New changeset 4b03ae00a76b by Benjamin Peterson in branch 'default': use correct article (closes #22342) http://hg.python.org/peps/rev/4b03ae00a76b ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 22:38:33 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 05 Sep 2014 20:38:33 +0000 Subject: [issue20643] Strange dot in documentation (after generator.close) In-Reply-To: <1392587871.68.0.444276628486.issue20643@psf.upfronthosting.co.za> Message-ID: <3hqW1j04w0z7Ljt@mail.python.org> Roundup Robot added the comment: New changeset bc4e26755a13 by Serhiy Storchaka in branch '3.4': Issue #20643: Removed unneeded (and wrong) class directives. http://hg.python.org/cpython/rev/bc4e26755a13 New changeset 060e347c9a23 by Serhiy Storchaka in branch 'default': Issue #20643: Removed unneeded (and wrong) class directives. http://hg.python.org/cpython/rev/060e347c9a23 New changeset 6dba9db360d0 by Serhiy Storchaka in branch '2.7': Issue #20643: Fixed references to the next() method (distinguish from the http://hg.python.org/cpython/rev/6dba9db360d0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 22:50:53 2014 From: report at bugs.python.org (Akima) Date: Fri, 05 Sep 2014 20:50:53 +0000 Subject: [issue22302] Windows os.path.isabs UNC path bug In-Reply-To: <1409349502.55.0.177656049078.issue22302@psf.upfronthosting.co.za> Message-ID: <1409950253.32.0.784780667477.issue22302@psf.upfronthosting.co.za> Akima added the comment: As eryksun pointed out, I created this bug report to report on one issue; that \\server\share isn't being consider absolute by os.path.isabs when it should be considered absolute. I found this bug when I was writing a basic config file parsing module. One of the options in the config (named log_dir) required an absolute path to a directory where my program could dump log files. It has to be absolute because the working directory of the program changes. A user entered a path \\pollux\logs as the log_dir value in their config file and my program rejected it informing the user that it wasn't absolute (because I checked the path using isabs). I've worked around this bug in my program, but it is clearly a problem that needs fixing. Steve: with regard to what isabs should return when given the string r"\\server": does it really matter whether it returns True or False? As you said; \\server isn't a real path. It's invalid. If you ask python if it's absolute (using os.path.isabs) and you expect a boolean response, no matter whether the response is True or False, the response will be meaningless. Consider this: Python 3.2.3 (default, Feb 27 2014, 21:31:18) [GCC 4.6.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os.path >>> os.path.isabs("&monkeyfart!??") False >>> I just asked isabs if "&monkeyfart!??" was absolute and it told me it's not an absolute path, it's relative! It's infact, not even a path. There is no "os.path.isrelative" function. If we want to know if a path is relative we use the isabs function and decide the path is relative if the result is False. If you give the function a junk-string which isn't even a path (eg \\server or &monkeyfart!?? ) then you can only expect a junk response. If we decide that all invalid paths provide to isabs should return False then what we are saying is all invalid paths provided to isabs should be considered relative paths. What use is that to anyone? Really, the programmer should ensure that the path is valid before trying to find out if it's relative or absolute. To summarize: I think it's important that isabs works correctly when given a *valid* path (like \\server\share). When it's given a string which is an invalid path (like \\server), its behaviour should be undefined. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 22:50:58 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 05 Sep 2014 20:50:58 +0000 Subject: [issue20643] Strange dot in documentation (after generator.close) In-Reply-To: <1392587871.68.0.444276628486.issue20643@psf.upfronthosting.co.za> Message-ID: <1409950258.57.0.921642373476.issue20643@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: docs at python -> serhiy.storchaka resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 23:02:07 2014 From: report at bugs.python.org (py.user) Date: Fri, 05 Sep 2014 21:02:07 +0000 Subject: [issue22344] Reorganize unittest.mock docs into linear manner Message-ID: <1409950927.16.0.630847623783.issue22344@psf.upfronthosting.co.za> New submission from py.user: Now, it's very inconvenient to learn this documentation. It's not compact (could be reduced in 2 or even 3 times). It repeats itself: many examples copy-pasted unchangeably. And it cites to terms that placed under those cites, so people should start at the bottom to anderstand what it's talking about on the top. Remember Zen "If the implementation is hard to explain, it's a bad idea." - Move the MagicMock description to the point between Mock and PropertyMock descriptions - Remove "copy-paste" examples - Rename print to print() and StringIO to io - Split the Autospecing section to several chunks ---------- assignee: docs at python components: Documentation messages: 226456 nosy: docs at python, py.user priority: normal severity: normal status: open title: Reorganize unittest.mock docs into linear manner type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 23:13:19 2014 From: report at bugs.python.org (=?utf-8?q?Zbyszek_J=C4=99drzejewski-Szmek?=) Date: Fri, 05 Sep 2014 21:13:19 +0000 Subject: [issue22345] https://docs.python.org/release/1.4/ returns 403 Message-ID: <1409951599.8.0.482931497215.issue22345@psf.upfronthosting.co.za> New submission from Zbyszek J?drzejewski-Szmek: This is the last link on https://www.python.org/doc/versions/. ---------- assignee: docs at python components: Documentation messages: 226457 nosy: docs at python, zbysz priority: normal severity: normal status: open title: https://docs.python.org/release/1.4/ returns 403 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 23:21:01 2014 From: report at bugs.python.org (Ned Deily) Date: Fri, 05 Sep 2014 21:21:01 +0000 Subject: [issue22345] https://docs.python.org/release/1.4/ returns 403 In-Reply-To: <1409951599.8.0.482931497215.issue22345@psf.upfronthosting.co.za> Message-ID: <1409952061.28.0.501760991209.issue22345@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- assignee: docs at python -> benjamin.peterson nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 23:28:23 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 05 Sep 2014 21:28:23 +0000 Subject: [issue22345] https://docs.python.org/release/1.4/ returns 403 In-Reply-To: <1409951599.8.0.482931497215.issue22345@psf.upfronthosting.co.za> Message-ID: <1409952503.18.0.235296966326.issue22345@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 23:34:59 2014 From: report at bugs.python.org (Kevin Norris) Date: Fri, 05 Sep 2014 21:34:59 +0000 Subject: [issue22299] resolve() on Windows makes some pathological paths unusable In-Reply-To: <1409318228.27.0.489471733533.issue22299@psf.upfronthosting.co.za> Message-ID: <1409952899.75.0.860257244039.issue22299@psf.upfronthosting.co.za> Kevin Norris added the comment: I'm a little concerned about this fix. In particular, if I understand the design of the patch correctly, it is intended to produce this behavior: Path('C:/foo').resolve() != Path('//?/C:/foo').resolve() Since both paths are valid and both paths refer to the same file, some developers may find this result counterintuitive. The Path.resolve() docs do not expressly forbid it, however. How many developers assume Path.resolve() is always the same for the same file? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 5 23:43:50 2014 From: report at bugs.python.org (Ned Deily) Date: Fri, 05 Sep 2014 21:43:50 +0000 Subject: [issue22344] Reorganize unittest.mock docs into linear manner In-Reply-To: <1409950927.16.0.630847623783.issue22344@psf.upfronthosting.co.za> Message-ID: <1409953430.68.0.909032690245.issue22344@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +michael.foord versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 00:20:07 2014 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 05 Sep 2014 22:20:07 +0000 Subject: [issue13968] Support recursive globs In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za> Message-ID: <1409955607.69.0.466808402066.issue13968@psf.upfronthosting.co.za> Nick Coghlan added the comment: Mostly looks good to me, just two comments: 1. Is there a reason the helper function is "glob2" rather than either "_glob2" or else something more self-documenting? 2. "match a files" in the docs and docstrings doesn't read correctly. "match any files", perhaps? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 00:24:32 2014 From: report at bugs.python.org (Ethan Furman) Date: Fri, 05 Sep 2014 22:24:32 +0000 Subject: [issue22339] Incorrect behavior when subclassing enum.Enum In-Reply-To: <1409878211.89.0.422808973529.issue22339@psf.upfronthosting.co.za> Message-ID: <1409955872.76.0.715470033965.issue22339@psf.upfronthosting.co.za> Ethan Furman added the comment: My apologies for the confusion, and thanks for tracking it down. I'll get the patch in, but I'm curious how you actually use these Enums? Is this a way to easily handle multiple aliases? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 01:09:30 2014 From: report at bugs.python.org (Brian Curtin) Date: Fri, 05 Sep 2014 23:09:30 +0000 Subject: [issue900092] hotshot.stats.load fails with AssertionError Message-ID: <1409958570.84.0.97336196585.issue900092@psf.upfronthosting.co.za> Changes by Brian Curtin : ---------- nosy: -brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 01:52:54 2014 From: report at bugs.python.org (Martin Panter) Date: Fri, 05 Sep 2014 23:52:54 +0000 Subject: [issue19280] Add a datatype to represent mime types to the email module In-Reply-To: <1382019183.72.0.422205662358.issue19280@psf.upfronthosting.co.za> Message-ID: <1409961174.52.0.430061616056.issue19280@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 02:43:35 2014 From: report at bugs.python.org (=?utf-8?q?Kiss_Gy=C3=B6rgy?=) Date: Sat, 06 Sep 2014 00:43:35 +0000 Subject: [issue22339] Incorrect behavior when subclassing enum.Enum In-Reply-To: <1409878211.89.0.422808973529.issue22339@psf.upfronthosting.co.za> Message-ID: <1409964215.19.0.955372110416.issue22339@psf.upfronthosting.co.za> Kiss Gy?rgy added the comment: > Is this a way to easily handle multiple aliases? You mean this MultiValueEnum implementation? (If not I don't understand the question, could you elaborate?) No, this is the opposite of aliases, because an alias is when the same value have multiple names, but this is when the values are used to lookup the same name. I use it when very similar values have the same meaning like: class Suit(MultiValueEnum): CLUBS = '?', 'c', 'C', 'clubs', 'club' DIAMONDS = '?', 'd', 'D', 'diamonds', 'diamond' HEARTS = '?', 'h', 'H', 'hearts', 'heart' SPADES = '?', 's', 'S', 'spades', 'spade' Also it can be used for ECP testing (Equivalence class testing) like this: from http.client import responses class ResponseEnum(MultiValueEnum): GOOD = [status for status in responses if 200 <= status <= 299] BAD = [status for status in responses if not (200 <= status <= 299)] I did not think about this use case, but I think it's very interesting and useful. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 03:23:36 2014 From: report at bugs.python.org (eryksun) Date: Sat, 06 Sep 2014 01:23:36 +0000 Subject: [issue22299] resolve() on Windows makes some pathological paths unusable In-Reply-To: <1409318228.27.0.489471733533.issue22299@psf.upfronthosting.co.za> Message-ID: <1409966616.76.0.383883377532.issue22299@psf.upfronthosting.co.za> eryksun added the comment: Maybe for an extended path it could try _getfinalpathname without the prefix. If it isn't a valid path or the result isn't the same as _getfinalpathname including the prefix, then skip calling _ext_to_normal. For example: def resolve(self, path): s = str(path) if not s: return os.getcwd() if _getfinalpathname is not None: prefix, t = self._split_extended_path(s) s = _getfinalpathname(s) if prefix: try: if _getfinalpathname(t) != s: return s except FileNotFoundError: return s return self._ext_to_normal(s) # Means fallback on absolute return None The 'foo.' path in this issue would keep the prefix: >>> Path('//?/C:/foo.').resolve() WindowsPath('//?/C:/foo.') >>> Path('//?/UNC/server/C$/foo.').resolve() WindowsPath('//?/UNC/server/C$/foo.') But regular paths would remove the prefix: >>> Path('//?/C:/bar').resolve() WindowsPath('C:/bar') >>> Path('//?/UNC/server/C$/bar').resolve() WindowsPath('//server/C$/bar') On a related note, _split_extended_path only looks for uppercase "UNC", which makes the above resolve method fail: >>> Path('//?/unc/server/C$/bar').resolve() WindowsPath('//?/UNC/server/C$/bar') ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 03:29:13 2014 From: report at bugs.python.org (Thomas Kluyver) Date: Sat, 06 Sep 2014 01:29:13 +0000 Subject: [issue22346] asyncio documentation does not mention provisional status Message-ID: <1409966953.11.0.406607337237.issue22346@psf.upfronthosting.co.za> New submission from Thomas Kluyver: >From PEP 411: """ A package will be marked provisional by a notice in its documentation page and its docstring. The following paragraph will be added as a note at the top of the documentation page: The package has been included in the standard library on a provisional basis. Backwards incompatible changes (up to and including removal of the package) may occur if deemed necessary by the core developers. """ PEP 3156 says that asyncio is in provisional status until Python 3.5, but the main asyncio page in the docs does not even mention this, let alone having the new warning: https://docs.python.org/3/library/asyncio.html I freely admit this is nitpicking, but if the idea of provisional status is to be taken seriously, I think asyncio, as a very high profile new package, should set a good example of it. ---------- assignee: docs at python components: Documentation, asyncio messages: 226463 nosy: docs at python, gvanrossum, haypo, takluyver, yselivanov priority: normal severity: normal status: open title: asyncio documentation does not mention provisional status versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 04:28:51 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 06 Sep 2014 02:28:51 +0000 Subject: [issue22346] asyncio documentation does not mention provisional status In-Reply-To: <1409966953.11.0.406607337237.issue22346@psf.upfronthosting.co.za> Message-ID: <3hqfnt0WMdz7LjV@mail.python.org> Roundup Robot added the comment: New changeset f8f3e83c9528 by Guido van Rossum in branch 'default': Add PEP-411-compliant note about asyncio being provisional. Fixes issue #22346. http://hg.python.org/cpython/rev/f8f3e83c9528 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 04:29:20 2014 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 06 Sep 2014 02:29:20 +0000 Subject: [issue22346] asyncio documentation does not mention provisional status In-Reply-To: <1409966953.11.0.406607337237.issue22346@psf.upfronthosting.co.za> Message-ID: <1409970560.47.0.603381818295.issue22346@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thanks! ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 04:37:27 2014 From: report at bugs.python.org (Ned Deily) Date: Sat, 06 Sep 2014 02:37:27 +0000 Subject: [issue22343] Install bash activate script on Windows when using venv In-Reply-To: <1409948648.7.0.892236136888.issue22343@psf.upfronthosting.co.za> Message-ID: <1409971047.15.0.804427563628.issue22343@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +ncoghlan, vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 04:39:08 2014 From: report at bugs.python.org (Martin Panter) Date: Sat, 06 Sep 2014 02:39:08 +0000 Subject: [issue1043134] Add preferred extensions for MIME types Message-ID: <1409971148.86.0.843311634139.issue1043134@psf.upfronthosting.co.za> Martin Panter added the comment: See also , which mentions using a list of tuples instead of a dictionary, which sounds like it might help with this issue. Doing it that way you might be able avoid some duplication in the lists. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 04:52:37 2014 From: report at bugs.python.org (Martin Panter) Date: Sat, 06 Sep 2014 02:52:37 +0000 Subject: [issue22347] mimetypes.guess_type("//example.com") misinterprets host name as file name Message-ID: <1409971957.28.0.64915967452.issue22347@psf.upfronthosting.co.za> New submission from Martin Panter: The documentation says that guess_type() takes a URL, but: >>> mimetypes.guess_type("http://example.com") ('application/x-msdownload', None) I suspect the MS download is a reference to *.com files (like DOS's command.com). My current workaround is to strip out the host name from the URL, since I cannot imagine it would be useful for determining the content type. I am also stripping the fragment part. An argument could probably be made for stripping the ?;parameters? and ??query? parts as well. >>> # Workaround for mimetypes.guess_type("//example.com") ... # interpreting host name as file name ... url = urlparse("http://example.com") >>> url = net.url_replace(url, netloc="", fragment="") >>> url 'http://' >>> mimetypes.guess_type(url, strict=False) (None, None) ---------- components: Library (Lib) messages: 226467 nosy: vadmium priority: normal severity: normal status: open title: mimetypes.guess_type("//example.com") misinterprets host name as file name type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 04:54:19 2014 From: report at bugs.python.org (Ethan Furman) Date: Sat, 06 Sep 2014 02:54:19 +0000 Subject: [issue22339] Incorrect behavior when subclassing enum.Enum In-Reply-To: <1409878211.89.0.422808973529.issue22339@psf.upfronthosting.co.za> Message-ID: <1409972059.24.0.618017657573.issue22339@psf.upfronthosting.co.za> Ethan Furman added the comment: Right. We can still use the alias machinery to accomplish this task for us, and avoid the metaclass hacking: -- python2 sample code ------------------------------------ # -*- coding: utf-8 -*- from enum import Enum class MultiValueEnum(Enum): def __new__(cls, *values): obj = object.__new__(cls) obj._value_ = values[0] obj._all_values = values for alias in values[1:]: cls._value2member_map_[alias] = obj return obj def __repr__(self): return "<%s.%s: %s>" % ( self.__class__.__name__, self._name_, ', '.join(["'%s'" % v for v in self._all_values]) ) class Suits(MultiValueEnum): CLUBS = '?', 'c', 'C', 'clubs', 'club' DIAMONDS = '?', 'd', 'D', 'diamonds', 'diamond' HEARTS = '?', 'h', 'H', 'hearts', 'heart' SPADES = '?', 's', 'S', 'spades', 'spade' print(Suits.HEARTS) print(repr(Suits.HEARTS)) print(Suits('d')) print(Suits('club')) print(Suits('S')) print(Suits('hearts')) ---------------------------------------------------------------- And the output: Suits.HEARTS Suits.DIAMONDS Suits.CLUBS Suits.SPADES Suits.HEARTS ---------------------------------------------------------------- I'm still going to fix the bug, though. :) Oh, the above does not fix the IncorrectAliasBehavior class, but honestly I'm not sure what you are trying to accomplish there. ---------- stage: -> patch review type: enhancement -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 04:58:27 2014 From: report at bugs.python.org (paul j3) Date: Sat, 06 Sep 2014 02:58:27 +0000 Subject: [issue11588] Add "necessarily inclusive" groups to argparse In-Reply-To: <1300377092.03.0.159307937388.issue11588@psf.upfronthosting.co.za> Message-ID: <1409972307.0.0.631573741443.issue11588@psf.upfronthosting.co.za> paul j3 added the comment: Attached is a patch for 3.5.0 dev that adds UsageGroups. Now different 'kinds' are implemented as subclasses, which are accessed via the registry: _XorUsageGroup - replicate action of MutuallyExclusiveGroups _AndUsageGroup - an inclusive group _OrUsageGroup - an 'any' group _NorUsageGroup - NotOr - also works as Not _NandUsageGroup - NotAnd Open issues: - what difference should the 'required' parameter make? - how should 'errors' in nested groups propagate? - formatting of error messages - formatting the usage line with these groups - any additional 'help' display - framework for custom test and/or subclasses - documentation, sample scripts, and formal testing ---------- Added file: http://bugs.python.org/file36553/usage_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 07:03:39 2014 From: report at bugs.python.org (=?utf-8?q?Kiss_Gy=C3=B6rgy?=) Date: Sat, 06 Sep 2014 05:03:39 +0000 Subject: [issue22339] Incorrect behavior when subclassing enum.Enum In-Reply-To: <1409878211.89.0.422808973529.issue22339@psf.upfronthosting.co.za> Message-ID: <1409979819.55.0.694422776039.issue22339@psf.upfronthosting.co.za> Kiss Gy?rgy added the comment: Oh, wow. I never really understood what _find_new_ did, now I do. > I'm not sure what you are trying to accomplish there. Exactly that, I'm just not as good. Oh well at least I found a bug! :) Thanks for the enlightenment! If the patch goes in, I also would like one more minor change. On line 457, the missing value is represented as simple str(). In case of user defined types, it would make debugging easier if repr() would be used instead. I attached the patch. ---------- Added file: http://bugs.python.org/file36554/enum.patch2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 07:52:07 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 06 Sep 2014 05:52:07 +0000 Subject: [issue13968] Support recursive globs In-Reply-To: <1409955607.69.0.466808402066.issue13968@psf.upfronthosting.co.za> Message-ID: <5205308.KOxEr8Ur9U@raxxla> Serhiy Storchaka added the comment: Thank you Nick. > 1. Is there a reason the helper function is "glob2" rather than either > "_glob2" or else something more self-documenting? Only consistency with other helper functions (glob0, glob1). > 2. "match a files" in the docs and docstrings doesn't read correctly. "match > any files", perhaps? Of course. This is just a typo. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 07:57:40 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 06 Sep 2014 05:57:40 +0000 Subject: [issue13968] Support recursive globs In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za> Message-ID: <1409983060.5.0.30985553165.issue13968@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file36555/glob_recursive_6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 08:21:39 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 06 Sep 2014 06:21:39 +0000 Subject: [issue22215] "embedded NUL character" exceptions In-Reply-To: <1408286635.01.0.343838296034.issue22215@psf.upfronthosting.co.za> Message-ID: <1409984499.87.0.205094941432.issue22215@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Simplified a code in getargs.c as suggested by Victor. ---------- Added file: http://bugs.python.org/file36556/valueerror_embedded_nul_character_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 08:23:08 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 06 Sep 2014 06:23:08 +0000 Subject: [issue22215] "embedded NUL character" exceptions In-Reply-To: <1408286635.01.0.343838296034.issue22215@psf.upfronthosting.co.za> Message-ID: <1409984588.87.0.695836054791.issue22215@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file36556/valueerror_embedded_nul_character_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 08:29:27 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 06 Sep 2014 06:29:27 +0000 Subject: [issue22215] "embedded NUL character" exceptions In-Reply-To: <1408286635.01.0.343838296034.issue22215@psf.upfronthosting.co.za> Message-ID: <1409984967.6.0.159075666903.issue22215@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file36557/valueerror_embedded_nul_character_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 09:24:07 2014 From: report at bugs.python.org (Akima) Date: Sat, 06 Sep 2014 07:24:07 +0000 Subject: [issue22302] Windows os.path.isabs UNC path bug In-Reply-To: <1409349502.55.0.177656049078.issue22302@psf.upfronthosting.co.za> Message-ID: <1409988247.47.0.676328913014.issue22302@psf.upfronthosting.co.za> Akima added the comment: I just realised that "&monkeyfart!??" is actually a valid relative path name. What I said still holds, just replace "&monkeyfart!??" with ">elephant*dung?" (which contains the invalid characters: >*? ). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 09:28:45 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 06 Sep 2014 07:28:45 +0000 Subject: [issue22226] Refactor dict result handling in Tkinter In-Reply-To: <1408428974.08.0.266954995149.issue22226@psf.upfronthosting.co.za> Message-ID: <1409988525.18.0.624121520671.issue22226@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Terry. Fixed style in two methods, added a summary to Treeview.set() docstring and changed returns/sets to return/set. But I disagree with other suggestions. Return value of 3-arg call is insignificant implementation detail. In any case these changes are irrelevant to this issue. ---------- Added file: http://bugs.python.org/file36558/tkinter_splitdict_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 09:31:12 2014 From: report at bugs.python.org (Akima) Date: Sat, 06 Sep 2014 07:31:12 +0000 Subject: [issue22302] Windows os.path.isabs UNC path bug In-Reply-To: <1409349502.55.0.177656049078.issue22302@psf.upfronthosting.co.za> Message-ID: <1409988672.54.0.793103601372.issue22302@psf.upfronthosting.co.za> Akima added the comment: eryksun: You have marked this bug as effecting Python 2.7. When I tested for the bug on 2.7.5 the problem didn't show up: Python 2.7.5 (default, May 15 2013, 22:43:36) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import os.path >>> os.path.isabs(r"\\server") True >>> os.path.isabs(r"\\server\share") True >>> os.path.isabs(r"\\server\share\folder") True >>> os.path.isabs(r"\\server\share\folder\folder") True >>> Did you independently test a later release of version 2.7 and find the issue? If not, could you remove Python 2.7 from the "Versions" list. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 09:56:42 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 06 Sep 2014 07:56:42 +0000 Subject: [issue13968] Support recursive globs In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za> Message-ID: <1409990202.69.0.0756559518586.issue13968@psf.upfronthosting.co.za> Nick Coghlan added the comment: Looks good to me! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 10:02:47 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 06 Sep 2014 08:02:47 +0000 Subject: [issue22302] Windows os.path.isabs UNC path bug In-Reply-To: <1409988672.54.0.793103601372.issue22302@psf.upfronthosting.co.za> Message-ID: <2429253.FVXbE0rSIT@raxxla> Serhiy Storchaka added the comment: This is the consequence of recent backporting splitdrive() implementation from 3.x to 2.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 11:06:57 2014 From: report at bugs.python.org (STINNER Victor) Date: Sat, 06 Sep 2014 09:06:57 +0000 Subject: [issue22215] "embedded NUL character" exceptions In-Reply-To: <1409984967.66.0.930112114122.issue22215@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: The latest patch looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 11:18:54 2014 From: report at bugs.python.org (Cory Benfield) Date: Sat, 06 Sep 2014 09:18:54 +0000 Subject: [issue20188] ALPN support for TLS In-Reply-To: <1389153179.88.0.510995543218.issue20188@psf.upfronthosting.co.za> Message-ID: <1409995134.36.0.92163607863.issue20188@psf.upfronthosting.co.za> Cory Benfield added the comment: Updating to mention a concern with ALPN implementation. HTTP/2 requires that a cipher with AEAD be negotiated. However, it also allows for offering a wider range of cipher suites: if an AEAD cipher is not present, this will allow fallback to HTTP/1.1. There's some interplay between ALPN and cipher selection here. We'll want to ensure that either ALPN negotiation can inform cipher selection or vice-versa, or writing a Python HTTP/2 server will get tricky fast. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 11:47:20 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 06 Sep 2014 09:47:20 +0000 Subject: [issue22346] asyncio documentation does not mention provisional status In-Reply-To: <1409966953.11.0.406607337237.issue22346@psf.upfronthosting.co.za> Message-ID: <3hqrWq5G44z7LjM@mail.python.org> Roundup Robot added the comment: New changeset fefe7822e6b8 by Nick Coghlan in branch '3.4': Issue #22346: also include asyncio PEP 411 notice in 3.4 http://hg.python.org/cpython/rev/fefe7822e6b8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 12:35:30 2014 From: report at bugs.python.org (Berker Peksag) Date: Sat, 06 Sep 2014 10:35:30 +0000 Subject: [issue22340] Fix Python 3 warnings in Python 2 tests In-Reply-To: <1409913910.6.0.350974401324.issue22340@psf.upfronthosting.co.za> Message-ID: <1409999730.24.0.243558290416.issue22340@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 12:40:19 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 06 Sep 2014 10:40:19 +0000 Subject: [issue22295] Clarify available commands for package installation In-Reply-To: <1409258945.79.0.640887405807.issue22295@psf.upfronthosting.co.za> Message-ID: <3hqshy1sDjz7NCS@mail.python.org> Roundup Robot added the comment: New changeset e8447da8791d by Nick Coghlan in branch '3.4': Issue #22295: Adopt 'python -m pip' as the preferred invocation http://hg.python.org/cpython/rev/e8447da8791d New changeset a969b42e6e2b by Nick Coghlan in branch 'default': Merge issue #22295 fix from 3.4 http://hg.python.org/cpython/rev/a969b42e6e2b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 12:42:54 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 06 Sep 2014 10:42:54 +0000 Subject: [issue22295] Clarify available commands for package installation In-Reply-To: <1409258945.79.0.640887405807.issue22295@psf.upfronthosting.co.za> Message-ID: <1410000174.61.0.394896722835.issue22295@psf.upfronthosting.co.za> Nick Coghlan added the comment: Switched to "python -m pip". To deal with "python3" vs "python" parallel system installs, I made the assumption that folks are using virtual environments explicitly, rather than diving into the arcana associated with using pip in conjunction with a system Python installation. ---------- resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 12:45:19 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 06 Sep 2014 10:45:19 +0000 Subject: [issue22343] Install bash activate script on Windows when using venv In-Reply-To: <1409948648.7.0.892236136888.issue22343@psf.upfronthosting.co.za> Message-ID: <1410000319.36.0.400894578328.issue22343@psf.upfronthosting.co.za> Nick Coghlan added the comment: +1 from me - Vinay? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 12:57:31 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 06 Sep 2014 10:57:31 +0000 Subject: [issue22299] resolve() on Windows makes some pathological paths unusable In-Reply-To: <1409318228.27.0.489471733533.issue22299@psf.upfronthosting.co.za> Message-ID: <1410001051.64.0.179227759861.issue22299@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Since both paths are valid and both paths refer to the same file, some developers may find this result counterintuitive. On the other hand the proposed solution is regular. If you input an extended path, you get an extended path as output. There are other factors that can come into play, such as hard links under Unix (and perhaps under Windows too). The recommended way to check if two paths point to the same file is still os.path.samefile(). Another approach would be for pathlib to *always* use extended paths internally on Windows absolute paths; I don't know which side effects that could have, though. Note we could also add methods to switch from the extended to the regular form and vice-versa. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 14:34:42 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 06 Sep 2014 12:34:42 +0000 Subject: [issue22166] test_codecs leaks references In-Reply-To: <1407444567.64.0.0425446064781.issue22166@psf.upfronthosting.co.za> Message-ID: <1410006882.33.0.0966817668859.issue22166@psf.upfronthosting.co.za> Nick Coghlan added the comment: Ah, I think I've found a possible underlying culprit: there's a separate C level "codec_search_cache" on the interpreter object that is independent of encodings._cache. The attached patch eliminates the reference leaks entirely (using gc.get_referrers() to get a reference to the otherwise inaccessible internal interpreter cache). However, the patch has a bunch of changes that may not be necessary if that cache is dealt with properly, so I'm going to revert everything, and *start* with fixing the cache cleanup. ---------- Added file: http://bugs.python.org/file36559/issue22166_no_leaks_too_many_changes.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 14:45:10 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 06 Sep 2014 12:45:10 +0000 Subject: [issue22166] test_codecs leaks references In-Reply-To: <1407444567.64.0.0425446064781.issue22166@psf.upfronthosting.co.za> Message-ID: <1410007510.24.0.635677942099.issue22166@psf.upfronthosting.co.za> Nick Coghlan added the comment: Yep, it looks like the mess with the reference cycles in the tracebacks was just a secondary problem: the real culprit was the internal cache keeping everything else alive. Attached patch just adds clearing encodings._cache and the CPython internal cache to the ExceptionChainingTest.tearDown() method. The latter is accomplised via gc.get_referrers() and popping the codec's name from any dict remaining in that list after clearing the known caches, so it will actually handle any hidden name based caches on any interpreter. ---------- Added file: http://bugs.python.org/file36560/issue22166_clear_internal_cache.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 14:53:47 2014 From: report at bugs.python.org (Martin Richard) Date: Sat, 06 Sep 2014 12:53:47 +0000 Subject: [issue22348] Documentation of asyncio.StreamWriter.drain() Message-ID: <1410008027.32.0.320660376013.issue22348@psf.upfronthosting.co.za> New submission from Martin Richard: Hi, Following the discussion on the python-tulip group, I'd like to propose a patch for the documentation of StreamWriter.drain(). This patch aims to give a better description of what drain() is intended to do, and when to use it. In particular, it highlights the fact that calling drain() does not mean that any write operation will be performed, nor is required to be called. ---------- components: asyncio files: asyncio-streams-drain-doc.patch hgrepos: 273 keywords: patch messages: 226487 nosy: gvanrossum, haypo, martius, yselivanov priority: normal severity: normal status: open title: Documentation of asyncio.StreamWriter.drain() type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file36561/asyncio-streams-drain-doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 14:54:18 2014 From: report at bugs.python.org (Martin Richard) Date: Sat, 06 Sep 2014 12:54:18 +0000 Subject: [issue22348] Documentation of asyncio.StreamWriter.drain() In-Reply-To: <1410008027.32.0.320660376013.issue22348@psf.upfronthosting.co.za> Message-ID: <1410008058.8.0.774293392025.issue22348@psf.upfronthosting.co.za> Changes by Martin Richard : ---------- hgrepos: -273 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 14:55:31 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 06 Sep 2014 12:55:31 +0000 Subject: [issue22166] test_codecs leaks references In-Reply-To: <1407444567.64.0.0425446064781.issue22166@psf.upfronthosting.co.za> Message-ID: <1410008131.21.0.514236927478.issue22166@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I'd much rather see a private function somewhere (in the _codecs module) to clear that private interpreter cache. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 15:03:10 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 06 Sep 2014 13:03:10 +0000 Subject: [issue22166] test_codecs leaks references In-Reply-To: <1407444567.64.0.0425446064781.issue22166@psf.upfronthosting.co.za> Message-ID: <1410008590.21.0.826619885725.issue22166@psf.upfronthosting.co.za> Nick Coghlan added the comment: Yeah, I'm wary of the GC hack as well. It's a nice way to prove that this the internal cache is the problem, but probably not something we want to commit. A "codecs._forget_codec" helper in the C module would be all that was needed to handle it. Other implementations could then also use that to clear their own internal cache (if they have one). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 15:15:57 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Sat, 06 Sep 2014 13:15:57 +0000 Subject: [issue22166] test_codecs leaks references In-Reply-To: <1410008590.21.0.826619885725.issue22166@psf.upfronthosting.co.za> Message-ID: <540B0904.9020508@egenix.com> Marc-Andre Lemburg added the comment: On 06.09.2014 15:03, Nick Coghlan wrote: > A "codecs._forget_codec" helper in the C module would be all that was needed to handle it. Other implementations could then also use that to clear their own internal cache (if they have one). If you want to take that approach, please call that function codecs._clear_lookup_cache() and also add a new C API _PyCodecRegistry_ClearLookupCache() to Python/codecs.c. Thanks, -- Marc-Andre Lemburg eGenix.com ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 16:26:25 2014 From: report at bugs.python.org (=?utf-8?q?Kiss_Gy=C3=B6rgy?=) Date: Sat, 06 Sep 2014 14:26:25 +0000 Subject: [issue22339] Incorrect behavior when subclassing enum.Enum In-Reply-To: <1409878211.89.0.422808973529.issue22339@psf.upfronthosting.co.za> Message-ID: <1410013585.45.0.904286108748.issue22339@psf.upfronthosting.co.za> Kiss Gy?rgy added the comment: I found one thing which you can't do subclassing Enum what you can with metaclasses: enforcing type checking at class creation time. Values are passed to __new__ as positional arguments, so it's impossible to tell the difference between these two: class SingleValue(MultiVAlueEnum): one = 1, 'one' two = 2 class Tuple(MultiVAlueEnum): one = 1, 'one' two = 2, because in both cases (2,) would be passed. It's not a big deal, but "Explicit is better than implicit." and also I would like to avoid typos, which I often make like this: class StrValues(MultiValueEnum): one = ('One' 'one') two = ('two', 'Two') In this case, the first member would be accepted as 'Oneone' instead of ('One', 'one') and I see no way to check that without metaclasses. Do you? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 17:00:41 2014 From: report at bugs.python.org (Steve Dower) Date: Sat, 06 Sep 2014 15:00:41 +0000 Subject: [issue22299] resolve() on Windows makes some pathological paths unusable In-Reply-To: <1409318228.27.0.489471733533.issue22299@psf.upfronthosting.co.za> Message-ID: <1410015641.91.0.573084494547.issue22299@psf.upfronthosting.co.za> Steve Dower added the comment: Actually, I'd be inclined to never use the prefix within pathlib and then add it on if necessary when converting to a string. That would also solve a problem like: >>> p = Path("C:\\") / ('a'*150) / ('a'*150) >>> p.stat() FileNotFoundError: [WinError 3] The system cannot find the path specified: ... >>> p2 = Path("\\\\?\\" + str(p)) >>> p2.stat() os.stat_result(...) The hardest part about this is knowing with certainty whether it's needed. We can certainly detect most cases automatically. Maybe we also need an extra method or a format character to force a str() with prefix? Or maybe having an obvious enough function that people can monkey-patch if necessary - the "\\?\" prefix is an edge case for most people already, and checking the total length would bring that to >99% IME. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 17:04:24 2014 From: report at bugs.python.org (Steve Dower) Date: Sat, 06 Sep 2014 15:04:24 +0000 Subject: [issue22299] resolve() on Windows makes some pathological paths unusable In-Reply-To: <1409318228.27.0.489471733533.issue22299@psf.upfronthosting.co.za> Message-ID: <1410015864.52.0.10495501698.issue22299@psf.upfronthosting.co.za> Steve Dower added the comment: If anyone wanted to test that really long path, here's the incantation to create it: >>> import os, pathlib >>> os.mkdir("C:\\a") >>> os.mkdir("C:\\a\\" + "a"*150) >>> os.rename("C:\\a", "C:\\" + "a"*150) >>> p = pathlib.Path("C:\\") / ("a"*150) / ("a"*150) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 18:06:19 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 06 Sep 2014 16:06:19 +0000 Subject: [issue22166] test_codecs leaks references In-Reply-To: <1407444567.64.0.0425446064781.issue22166@psf.upfronthosting.co.za> Message-ID: <1410019579.24.0.588319831803.issue22166@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: May be just do not use the unique name? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 19:08:25 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 06 Sep 2014 17:08:25 +0000 Subject: [issue22215] "embedded NUL character" exceptions In-Reply-To: <1408286635.01.0.343838296034.issue22215@psf.upfronthosting.co.za> Message-ID: <3hr2Jm2swSz7LjV@mail.python.org> Roundup Robot added the comment: New changeset 25032ec29315 by Serhiy Storchaka in branch 'default': Issue #22215: Now ValueError is raised instead of TypeError when str or bytes http://hg.python.org/cpython/rev/25032ec29315 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 19:17:58 2014 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 06 Sep 2014 17:17:58 +0000 Subject: [issue12067] Doc: remove errors about mixed-type comparisons. In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za> Message-ID: <1410023878.27.0.0816209916129.issue12067@psf.upfronthosting.co.za> Guido van Rossum added the comment: - This bug should discuss doc updates, not question the rules. - The rules have evolved over time and the docs stayed behind. - We should definitely update the 2.7 docs as well as the 3.4 and 3.5 (in development) docs. The 2.7 docs need to be different than the 3.x docs. - The language reference manual should clearly state the rules so that implementers can use them as guidelines for implementation. - There are several sets of relevant rules: (a) How is each operator translated into a series of lookups and method calls, etc. It's similar to other binary operators except that the reverse for __lt__ is __gt__ instead of __rlt__, and there's an extra rule that if __ne__ doesn't exist we compute __eq__ and take the opposite. (b) The default implementation (e.g. default == falls back to 'is', < raises TypeError). (c) The rules for built-in types, especially numbers (if there are still special cases that aren't explained by the __xx__ methods on the various numeric types). ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 19:30:58 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 06 Sep 2014 17:30:58 +0000 Subject: [issue22215] "embedded NUL character" exceptions In-Reply-To: <1408286635.01.0.343838296034.issue22215@psf.upfronthosting.co.za> Message-ID: <1410024658.78.0.0557113867763.issue22215@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your review Victor. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 19:31:30 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 06 Sep 2014 17:31:30 +0000 Subject: [issue22215] "embedded NUL character" exceptions In-Reply-To: <1408286635.01.0.343838296034.issue22215@psf.upfronthosting.co.za> Message-ID: <1410024690.37.0.504863541199.issue22215@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 19:36:48 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 06 Sep 2014 17:36:48 +0000 Subject: [issue22131] uuid.bytes optimization In-Reply-To: <1407117956.69.0.92579582172.issue22131@psf.upfronthosting.co.za> Message-ID: <1410025008.05.0.0506066382041.issue22131@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Alex, Raymond, could you please make a review of my patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 19:55:03 2014 From: report at bugs.python.org (Alex Gaynor) Date: Sat, 06 Sep 2014 17:55:03 +0000 Subject: [issue22131] uuid.bytes optimization In-Reply-To: <1407117956.69.0.92579582172.issue22131@psf.upfronthosting.co.za> Message-ID: <1410026103.33.0.632416107709.issue22131@psf.upfronthosting.co.za> Alex Gaynor added the comment: Patch looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 20:07:14 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 06 Sep 2014 18:07:14 +0000 Subject: [issue22226] Refactor dict result handling in Tkinter In-Reply-To: <1408428974.08.0.266954995149.issue22226@psf.upfronthosting.co.za> Message-ID: <1410026834.73.0.0954521368209.issue22226@psf.upfronthosting.co.za> Terry J. Reedy added the comment: looks good to commit. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 20:34:54 2014 From: report at bugs.python.org (Ethan Furman) Date: Sat, 06 Sep 2014 18:34:54 +0000 Subject: [issue22339] Incorrect behavior when subclassing enum.Enum In-Reply-To: <1409878211.89.0.422808973529.issue22339@psf.upfronthosting.co.za> Message-ID: <1410028494.81.0.179066171152.issue22339@psf.upfronthosting.co.za> Ethan Furman added the comment: You could do the same kind of check in __new__, but consider this: class StrValues(MultiValueEnum): one = ('One' 'one', '1') two = ('two', 'Two', '2') In this scenario the 'Oneone' mistake would still not be automatically caught. There are the two ways I deal with this type of problem: - unit tests - formatting The formatting looks like this: class StrValues(MultiValueEnum): one = ( 'One' 'one', '1', ) two = ( 'two', 'Two', '2', ) This style of format does several things for us: - easier to read the code: - each value is on it's own line - each value is lined up - there is white space between the values of one attribute and the values of the next attribute - easier to read diffs, as we don't see extraneous stuff like - '2' + '2', - easier to spot mistakes, since we get used to seeing that trailing comma and it's absence will stand out. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 20:46:06 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 06 Sep 2014 18:46:06 +0000 Subject: [issue19524] ResourceWarning when urlopen() forgets the HTTPConnection object In-Reply-To: <1383882317.08.0.635493267684.issue19524@psf.upfronthosting.co.za> Message-ID: <3hr4TT2S4sz7Ljl@mail.python.org> Roundup Robot added the comment: New changeset c1fb19907cc4 by Serhiy Storchaka in branch '3.4': Issue #19524: Fixed resource leak in the HTTP connection when an invalid http://hg.python.org/cpython/rev/c1fb19907cc4 New changeset 43bf95480c3c by Serhiy Storchaka in branch 'default': Issue #19524: Fixed resource leak in the HTTP connection when an invalid http://hg.python.org/cpython/rev/43bf95480c3c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 20:57:39 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 06 Sep 2014 18:57:39 +0000 Subject: [issue19524] ResourceWarning when urlopen() forgets the HTTPConnection object In-Reply-To: <1383882317.08.0.635493267684.issue19524@psf.upfronthosting.co.za> Message-ID: <1410029859.81.0.135813928182.issue19524@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your contribution Martin. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 21:11:14 2014 From: report at bugs.python.org (Vinay Sajip) Date: Sat, 06 Sep 2014 19:11:14 +0000 Subject: [issue22343] Install bash activate script on Windows when using venv In-Reply-To: <1409948648.7.0.892236136888.issue22343@psf.upfronthosting.co.za> Message-ID: <1410030674.88.0.76391249704.issue22343@psf.upfronthosting.co.za> Vinay Sajip added the comment: I have no particular objection to this, and it's not a lot of work to make it happen. The POSIX scripts were left out in case the opposite view was advanced - that these scripts would be of no use to most people on Windows, and shouldn't be there cluttering up the place :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 21:14:09 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 06 Sep 2014 19:14:09 +0000 Subject: [issue22166] test_codecs leaks references In-Reply-To: <1410019579.24.0.588319831803.issue22166@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: This investigation also showed why the original tests that used a non-unique name didn't work: the codec was getting cached the first time through and hence not seeing the different codecs registered by other tests. MAL, my plan was to provide an API to forget a specific named codec rather than flush the whole cache. I agree a private C API would also be a good idea, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 21:21:25 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 06 Sep 2014 19:21:25 +0000 Subject: [issue22131] uuid.bytes optimization In-Reply-To: <1407117956.69.0.92579582172.issue22131@psf.upfronthosting.co.za> Message-ID: <3hr5GF0SX3z7Ljj@mail.python.org> Roundup Robot added the comment: New changeset f7b5038d3102 by Serhiy Storchaka in branch 'default': Issue #22131: Modernized the code of the uuid module. http://hg.python.org/cpython/rev/f7b5038d3102 New changeset d8c6b15a2ae3 by Serhiy Storchaka in branch '2.7': Issue #22131: Fixed a bug in handling an error occured during reading from http://hg.python.org/cpython/rev/d8c6b15a2ae3 New changeset 8a61a287776d by Serhiy Storchaka in branch '3.4': Issue #22131: Fixed a bug in handling an error occured during reading from http://hg.python.org/cpython/rev/8a61a287776d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 21:51:21 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 06 Sep 2014 19:51:21 +0000 Subject: [issue22131] uuid.bytes optimization In-Reply-To: <1407117956.69.0.92579582172.issue22131@psf.upfronthosting.co.za> Message-ID: <1410033081.69.0.31415825496.issue22131@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Alex. ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 21:52:08 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 06 Sep 2014 19:52:08 +0000 Subject: [issue22226] Refactor dict result handling in Tkinter In-Reply-To: <1408428974.08.0.266954995149.issue22226@psf.upfronthosting.co.za> Message-ID: <3hr5xh2J6Dz7LjY@mail.python.org> Roundup Robot added the comment: New changeset 7b0fdc1e917a by Serhiy Storchaka in branch '2.7': Issue #22226: Added private function _splitdict() in the Tkinter module. http://hg.python.org/cpython/rev/7b0fdc1e917a New changeset f89995a4ec11 by Serhiy Storchaka in branch '3.4': Issue #22226: Added private function _splitdict() in the Tkinter module. http://hg.python.org/cpython/rev/f89995a4ec11 New changeset 11cf18ec1900 by Serhiy Storchaka in branch 'default': Issue #22226: Added private function _splitdict() in the Tkinter module. http://hg.python.org/cpython/rev/11cf18ec1900 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 21:53:17 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 06 Sep 2014 19:53:17 +0000 Subject: [issue22226] Refactor dict result handling in Tkinter In-Reply-To: <1408428974.08.0.266954995149.issue22226@psf.upfronthosting.co.za> Message-ID: <1410033197.62.0.7373061262.issue22226@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Terry for your review. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 21:58:37 2014 From: report at bugs.python.org (Thomas Kluyver) Date: Sat, 06 Sep 2014 19:58:37 +0000 Subject: [issue22349] Remove more unnecessary version checks from distutils Message-ID: <1410033517.64.0.25782139484.issue22349@psf.upfronthosting.co.za> New submission from Thomas Kluyver: Following on from issue 22200, this removes some more code in distutils that checks which Python version it's running on. As part of the standard library, distutils should always be running on the version of Python which it ships with. ---------- components: Distutils files: rm-more-distutils-version-checks.patch keywords: patch messages: 226510 nosy: dstufft, eric.araujo, takluyver priority: normal severity: normal status: open title: Remove more unnecessary version checks from distutils versions: Python 3.5 Added file: http://bugs.python.org/file36562/rm-more-distutils-version-checks.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 22:01:03 2014 From: report at bugs.python.org (Thomas Kluyver) Date: Sat, 06 Sep 2014 20:01:03 +0000 Subject: [issue22200] Remove distutils checks for Python version In-Reply-To: <1408052221.61.0.16718662323.issue22200@psf.upfronthosting.co.za> Message-ID: <1410033663.25.0.447798409843.issue22200@psf.upfronthosting.co.za> Thomas Kluyver added the comment: I've made a patch removing some more of these version checks in issue 22349. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 22:07:45 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Sat, 06 Sep 2014 20:07:45 +0000 Subject: [issue22166] test_codecs leaks references In-Reply-To: Message-ID: <540B698F.80208@egenix.com> Marc-Andre Lemburg added the comment: On 06.09.2014 21:14, Nick Coghlan wrote: > > This investigation also showed why the original tests that used a > non-unique name didn't work: the codec was getting cached the first time > through and hence not seeing the different codecs registered by other tests. > > MAL, my plan was to provide an API to forget a specific named codec rather > than flush the whole cache. I agree a private C API would also be a good > idea, though. I don't think such a specific API for only forgetting a single codec is useful outside this particular test case, since you typically don't know the names of the cached codecs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 22:09:48 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 06 Sep 2014 20:09:48 +0000 Subject: [issue22166] test_codecs leaks references In-Reply-To: <1407444567.64.0.0425446064781.issue22166@psf.upfronthosting.co.za> Message-ID: <1410034188.18.0.0946440312783.issue22166@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Well, the point here is to add a private API just for our test suite, not something users would want to call. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 22:11:36 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 06 Sep 2014 20:11:36 +0000 Subject: [issue22299] resolve() on Windows makes some pathological paths unusable In-Reply-To: <1409318228.27.0.489471733533.issue22299@psf.upfronthosting.co.za> Message-ID: <1410034296.31.0.0995149397361.issue22299@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > I'd be inclined to never use the prefix within pathlib and then add it on if necessary when converting to a string That may be very surprising when that prefix appears, though... At least with explicit methods the user would have to invoke them, instead of getting unexpected results implicitly. I don't know what Windows users think about all this, though (I uses Linux myself). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 22:17:56 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 06 Sep 2014 20:17:56 +0000 Subject: [issue22323] Rewrite PyUnicode_AsWideChar() and PyUnicode_AsWideCharString() In-Reply-To: <1409607134.14.0.210351686888.issue22323@psf.upfronthosting.co.za> Message-ID: <1410034676.84.0.562571944206.issue22323@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Hmm... sorry for the delay, there's no review link. Perhaps the patch is not against the latest default? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 22:40:30 2014 From: report at bugs.python.org (Steve Dower) Date: Sat, 06 Sep 2014 20:40:30 +0000 Subject: [issue22299] resolve() on Windows makes some pathological paths unusable In-Reply-To: <1409318228.27.0.489471733533.issue22299@psf.upfronthosting.co.za> Message-ID: <1410036030.7.0.603150763539.issue22299@psf.upfronthosting.co.za> Steve Dower added the comment: It's no less expected than having OS functions fail because the path is too long. Using it to maintain dots at the end of directory/file names is a little less safe and may break some code. Maybe pathlib should strip these if there is no a prefix? (For example, "C:\Test." == "C:\Test" == "\\?\C:\Test" != "\\?\C:\Test.") If most (or all) of the file handling functions in Python are using *W() APIs and can support the prefix, I'd rather add it in silently if only to avoid the long path issue. It's really the sort of implementation detail that pathlib should be able to hide from the app developer and the user (Node.js does this, for example, as its node_modules hierarchies regularly exceed the max path limitation). Maybe the best approach is to preserve the prefix if it already exists, and add it if it becomes necessary. File operations are most likely to succeed in this case, even if it may be surprising to users. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 22:46:13 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 06 Sep 2014 20:46:13 +0000 Subject: [issue22324] Use PyUnicode_AsWideCharString() instead of PyUnicode_AsUnicode() In-Reply-To: <1409611190.39.0.820072774539.issue22324@psf.upfronthosting.co.za> Message-ID: <1410036373.23.0.62906243427.issue22324@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The cache is released when the string is released. While the string exists it's wchar_t representation can be needed again. That is for what the cache exists. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 6 23:24:42 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 06 Sep 2014 21:24:42 +0000 Subject: [issue22349] Remove more unnecessary version checks from distutils In-Reply-To: <1410033517.64.0.25782139484.issue22349@psf.upfronthosting.co.za> Message-ID: <3hr80T6gMHz7Lky@mail.python.org> Roundup Robot added the comment: New changeset 7fece97e605d by Benjamin Peterson in branch '3.4': remove various dead version checks (closes #22349) http://hg.python.org/cpython/rev/7fece97e605d New changeset 688701337b1a by Benjamin Peterson in branch 'default': merge 3.4 (#22349) http://hg.python.org/cpython/rev/688701337b1a ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 7 00:25:44 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 06 Sep 2014 22:25:44 +0000 Subject: [issue22299] resolve() on Windows makes some pathological paths unusable In-Reply-To: <1409318228.27.0.489471733533.issue22299@psf.upfronthosting.co.za> Message-ID: <1410042344.59.0.160665035003.issue22299@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > If most (or all) of the file handling functions in Python are using *W() APIs and can support the prefix, I'd rather add it in silently if only to avoid the long path issue. This would only work for fully-qualified paths, right? Not relative ones. I'm all for making things higher-level, I just want to make sure it won't break existing use cases :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 7 00:32:51 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 06 Sep 2014 22:32:51 +0000 Subject: [issue22166] test_codecs leaks references In-Reply-To: <1407444567.64.0.0425446064781.issue22166@psf.upfronthosting.co.za> Message-ID: <1410042771.35.0.170215154132.issue22166@psf.upfronthosting.co.za> Nick Coghlan added the comment: Targeted API to forget a particular codec name. Normally we don't care about the caching (as evidenced by the fact it took 14+ years to want this feature). The intent with this API is to be able to selective purge a particular codec when we either care about getting the latest version of a specific codec (no current use cases) or to avoid the appearance of leaking references when looking up lots of custom codecs (this case). I considered dropping the per-test naming scheme, but decided I liked the fact it kept these test instances orthogonal, even though they all use the shared TEST_CODECS registry. The lack of global side effects is also a benefit of just popping the named codec, rather than purging the entire cache. ---------- Added file: http://bugs.python.org/file36563/issue22166_with_forget_codec_helper_api.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 7 01:16:48 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 06 Sep 2014 23:16:48 +0000 Subject: [issue5309] distutils doesn't parallelize extension module compilation In-Reply-To: <1235007592.93.0.0598331575131.issue5309@psf.upfronthosting.co.za> Message-ID: <1410045408.65.0.412732381865.issue5309@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Updated patch: - add the -j option to the "build" command as well (even though it's only used by build_ext) - in setup.py, only force parallel compilation if make was called with -j ---------- Added file: http://bugs.python.org/file36564/build_ext_parallel5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 7 01:18:10 2014 From: report at bugs.python.org (Martin Panter) Date: Sat, 06 Sep 2014 23:18:10 +0000 Subject: [issue12067] Doc: remove errors about mixed-type comparisons. In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za> Message-ID: <1410045490.11.0.880626014689.issue12067@psf.upfronthosting.co.za> Martin Panter added the comment: The point about ?a != b? deferring to ?not a.__eq__(b)? is not documented anywhere that I am aware of. In fact the opposite is currently documented at , so maybe this needs to be fixed, one way or another. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 7 01:23:45 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 06 Sep 2014 23:23:45 +0000 Subject: [issue5309] distutils doesn't parallelize extension module compilation In-Reply-To: <1235007592.93.0.0598331575131.issue5309@psf.upfronthosting.co.za> Message-ID: <1410045825.23.0.402173549309.issue5309@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 7 01:37:08 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 06 Sep 2014 23:37:08 +0000 Subject: [issue5309] distutils doesn't parallelize extension module compilation In-Reply-To: <1235007592.93.0.0598331575131.issue5309@psf.upfronthosting.co.za> Message-ID: <1410046628.67.0.568833089891.issue5309@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: - Is support for infinite jobs planned? (GNU make supports it for -j without number argument.) - self.parallel = int(self.parallel) would raise ValueError when a non-number is passed. I suggest to print user-friendly error message. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 7 01:37:40 2014 From: report at bugs.python.org (Steve Dower) Date: Sat, 06 Sep 2014 23:37:40 +0000 Subject: [issue22299] resolve() on Windows makes some pathological paths unusable In-Reply-To: <1409318228.27.0.489471733533.issue22299@psf.upfronthosting.co.za> Message-ID: <1410046660.97.0.65046614447.issue22299@psf.upfronthosting.co.za> Steve Dower added the comment: > This would only work for fully-qualified paths, right? Not relative ones. Correct, and I think we're most of the way there with how drives are handled. Since the prefix only works with absolute paths, why not treat it as part of the drive name? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 7 01:38:03 2014 From: report at bugs.python.org (Berker Peksag) Date: Sat, 06 Sep 2014 23:38:03 +0000 Subject: [issue11572] bring Lib/copy.py to 100% coverage In-Reply-To: <1300293152.7.0.733550751317.issue11572@psf.upfronthosting.co.za> Message-ID: <1410046683.44.0.907732255962.issue11572@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- components: +Library (Lib) nosy: +berker.peksag type: -> enhancement versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 7 03:01:46 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 07 Sep 2014 01:01:46 +0000 Subject: [issue11822] Improve disassembly to show embedded code objects In-Reply-To: <1302467152.39.0.854888976189.issue11822@psf.upfronthosting.co.za> Message-ID: <1410051706.46.0.237906870333.issue11822@psf.upfronthosting.co.za> Nick Coghlan added the comment: Sorry for the long delay in doing anything with this patch. Unfortunately, trunk has moved on quite a bit since this patch was submitted, and it's no longer directly applicable. However, the basic principle is sound, so this is a new patch that aligns with the changes made in 3.4 to provide an iterator based bytecode introspection API. It also changes the indenting to be based on the structure of the bytecode disassembly - nested lines start aligned with the opcode *name* on the preceding line. This will get unreadable with more than two or three levels of nesting, but at that point, hard to read disassembly for the top level function is the least of your worries. (A potentially useful option may to be add a flag to turn off the implicit recursion, easily restoring the old single level behaviour. I'd like the recursive version to be the default though, since it's far more useful given that Python 3 comprehensions all involve a nested code object) A descriptive header makes the new output more self-explanatory. Note that I did try repeating the code object repr from the LOAD_CONST opcode in the new header - it was pretty unreadable, and redundant given the preceding line of disassembly. Two examples, one showing Torsten's list comprehension from above, and another showing that the nested line numbers work properly. This can't be applied as is - it's still missing tests, docs, and fixes to disassembly output tests that assume the old behaviour. >>> dis.dis('[x**2 for x in range(3)]') 1 0 LOAD_CONST 0 ( at 0x7f459ec4a0c0, file "", line 1>) Disassembly for nested code object 1 0 BUILD_LIST 0 3 LOAD_FAST 0 (.0) >> 6 FOR_ITER 16 (to 25) 9 STORE_FAST 1 (x) 12 LOAD_FAST 1 (x) 15 LOAD_CONST 0 (2) 18 BINARY_POWER 19 LIST_APPEND 2 22 JUMP_ABSOLUTE 6 >> 25 RETURN_VALUE 3 LOAD_CONST 1 ('') 6 MAKE_FUNCTION 0 9 LOAD_NAME 0 (range) 12 LOAD_CONST 2 (3) 15 CALL_FUNCTION 1 (1 positional, 0 keyword pair) 18 GET_ITER 19 CALL_FUNCTION 1 (1 positional, 0 keyword pair) 22 RETURN_VALUE >>> def f(): ... print("Hello") ... def g(): ... for x in range(10): ... yield x ... return g ... >>> dis.dis(f) 2 0 LOAD_GLOBAL 0 (print) 3 LOAD_CONST 1 ('Hello') 6 CALL_FUNCTION 1 (1 positional, 0 keyword pair) 9 POP_TOP 3 10 LOAD_CONST 2 (", line 3>) Disassembly for nested code object 4 0 SETUP_LOOP 25 (to 28) 3 LOAD_GLOBAL 0 (range) 6 LOAD_CONST 1 (10) 9 CALL_FUNCTION 1 (1 positional, 0 keyword pair) 12 GET_ITER >> 13 FOR_ITER 11 (to 27) 16 STORE_FAST 0 (x) 5 19 LOAD_FAST 0 (x) 22 YIELD_VALUE 23 POP_TOP 24 JUMP_ABSOLUTE 13 >> 27 POP_BLOCK >> 28 LOAD_CONST 0 (None) 31 RETURN_VALUE 13 LOAD_CONST 3 ('f..g') 16 MAKE_FUNCTION 0 19 STORE_FAST 0 (g) 6 22 LOAD_FAST 0 (g) 25 RETURN_VALUE ---------- Added file: http://bugs.python.org/file36565/issue11822_nested_disassembly.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 7 05:40:19 2014 From: report at bugs.python.org (Martin Panter) Date: Sun, 07 Sep 2014 03:40:19 +0000 Subject: [issue22350] nntplib file write failure causes exception from QUIT command Message-ID: <1410061219.03.0.0230581897355.issue22350@psf.upfronthosting.co.za> New submission from Martin Panter: The following code triggers an NNTPProtocolError, as long as the body is large enough to cause an intermediate flush of the output file. The reason I think is that the body() method aborts in the middle of reading the BODY response, and when the context manager exits, a QUIT command is attempted, which continues to read the BODY response. >>> with NNTP("localhost") as nntp: ... nntp.body("", file="/dev/full") ... Traceback (most recent call last): File "/usr/lib/python3.4/nntplib.py", line 491, in _getlongresp file.write(line) OSError: [Errno 28] No space left on device During handling of the above exception, another exception occurred: Traceback (most recent call last): File "", line 2, in File "/usr/lib/python3.4/nntplib.py", line 757, in body return self._artcmd(cmd, file) File "/usr/lib/python3.4/nntplib.py", line 727, in _artcmd resp, lines = self._longcmd(line, file) File "/usr/lib/python3.4/nntplib.py", line 518, in _longcmd return self._getlongresp(file) File "/usr/lib/python3.4/nntplib.py", line 504, in _getlongresp openedFile.close() OSError: [Errno 28] No space left on device During handling of the above exception, another exception occurred: Traceback (most recent call last): File "", line 2, in File "/usr/lib/python3.4/nntplib.py", line 367, in __exit__ self.quit() File "/usr/lib/python3.4/nntplib.py", line 936, in quit resp = self._shortcmd('QUIT') File "/usr/lib/python3.4/nntplib.py", line 512, in _shortcmd return self._getresp() File "/usr/lib/python3.4/nntplib.py", line 459, in _getresp raise NNTPProtocolError(resp) nntplib.NNTPProtocolError: It is hard to work around because the context manager and quit() methods seem to be the only public interfaces for closing the connection, and they both try to do a QUIT command first. I am thinking of something equivalent to this for a workaround, however it is bit hacky and may not be reliable in all cases: nntp = NNTP("localhost") abort = False try: ... try: nntp.body("", file="/dev/full") except (NNTPTemporaryError, NNTPPermanentError): raise # NNTP connection still intact except: abort = True raise ... finally: try: nntp.quit() except NNTPError: # Connection cleaned up despite exception if not abort: raise Perhaps the ?nntplib? module could abort the connection itself if any command does not complete according to the protocol. Or at the very least, provide an API to manually abort the connection without poking at the internals. ---------- components: Library (Lib) messages: 226526 nosy: vadmium priority: normal severity: normal status: open title: nntplib file write failure causes exception from QUIT command versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 7 05:47:33 2014 From: report at bugs.python.org (Martin Panter) Date: Sun, 07 Sep 2014 03:47:33 +0000 Subject: [issue21468] NNTPLib connections become corrupt after long periods of activity In-Reply-To: <1399738998.21.0.285283528599.issue21468@psf.upfronthosting.co.za> Message-ID: <1410061652.99.0.620603818465.issue21468@psf.upfronthosting.co.za> Martin Panter added the comment: Perhaps this is similar to Issue 22350 which I just raised. Whenever the NNTP context manager exits, a QUIT command is called, and if the context manager is exiting due to a protocol error or some other exception not handled by the protocol, the code will try and read other protocol data as the QUIT response. Perhaps your code was interrupted in the middle of reading a yEnc binary body and that is why it looks like garbage? ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 7 06:07:08 2014 From: report at bugs.python.org (Martin Panter) Date: Sun, 07 Sep 2014 04:07:08 +0000 Subject: [issue22351] NNTP constructor exception leaves socket for garbage collector Message-ID: <1410062828.01.0.535616885323.issue22351@psf.upfronthosting.co.za> New submission from Martin Panter: If the nntplib.NNTP constructor fails, it often leaves the connection and socket open until the garbage collector cleans them up and emits a ResourceWarning: >>> try: ... NNTP("localhost") ... except Exception as err: ... print(repr(err)) ... NNTPTemporaryError('400 Service temporarily unavailable',) >>> gc.collect() __main__:1: ResourceWarning: unclosed 12 This happens both for error responses that are expected by the protocol, e.g. service unavailable as above, authentication errors. It also happens for other exceptions such as EOFError if the connection is closed with no response. ---------- components: Library (Lib) messages: 226528 nosy: vadmium priority: normal severity: normal status: open title: NNTP constructor exception leaves socket for garbage collector type: resource usage versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 7 06:13:26 2014 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 07 Sep 2014 04:13:26 +0000 Subject: [issue12067] Doc: remove errors about mixed-type comparisons. In-Reply-To: <1410045490.11.0.880626014689.issue12067@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: That's a pretty new feature. Someone probably forgot to clean up all the places where it was documented. On Sat, Sep 6, 2014 at 4:18 PM, Martin Panter wrote: > > Martin Panter added the comment: > > The point about ?a != b? deferring to ?not a.__eq__(b)? is not documented > anywhere that I am aware of. In fact the opposite is currently documented > at < > https://docs.python.org/release/3.4.0/reference/datamodel.html#richcmpfuncs>, > so maybe this needs to be fixed, one way or another. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 7 06:58:11 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 07 Sep 2014 04:58:11 +0000 Subject: [issue22352] Ensure opcode names and args fit in disassembly output Message-ID: <1410065891.58.0.12430207232.issue22352@psf.upfronthosting.co.za> New submission from Nick Coghlan: While exploring display options for issue 11822, I found that the new matrix multiplication opcode names (BINARY_MATRIX_MULTIPLY and INPLACE_MATRIX_MULTIPLY) don't fit in the nominal field width in the disassembly output (which is currently 20 characters). These two clock in at 22 and 23 characters respectively. In practice, they do fit, since neither takes on argument, which effectively allows an extra 5 characters (while still looking neat) and unlimited characters if we ignore expanding past the column of opcode arguments. However, it would be good to: 1. Factor out the opname and oparg sizes to private class attributes on dis.Instruction 2. have a test in test_dis that scans dis.opnames and ensures all opcodes < dis.HAVE_ARGUMENT have names shorter than the combined length of the two fields, and that all opcodes >= HAVE_ARGUMENT will fit in the opname field, even with an argument present. Have such a test will ensure any new opcodes added can be displayed without any problems, rather than anyone having to remember to check manually. ---------- assignee: ncoghlan components: Library (Lib) messages: 226530 nosy: ncoghlan priority: low severity: normal status: open title: Ensure opcode names and args fit in disassembly output type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 7 07:30:36 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 07 Sep 2014 05:30:36 +0000 Subject: [issue11822] Improve disassembly to show embedded code objects In-Reply-To: <1302467152.39.0.854888976189.issue11822@psf.upfronthosting.co.za> Message-ID: <1410067836.77.0.153532979633.issue11822@psf.upfronthosting.co.za> Nick Coghlan added the comment: I didn't want to add a second argument to turn off the new behaviour, so I changed it such that passing a value < 0 for "nested" turns off the new feature entirely. Levels >= 0 enable it, defining which level to start with. The default level is "0" so there's no implied prefix, and nested code objects are displayed by default. This picks up at least comprehensions, lambda expressions and nested functions. I haven't checked how it handles nested classes yet. I used this feature to get the old tests passing again by turning off the recursion feature. New tests for the new behaviour are still needed. I also tweaked the header to show the *name* of the code object. The full repr is to noisy, but the generic message was hard to read when there were multiple nested code objects. ---------- Added file: http://bugs.python.org/file36566/issue11822_nested_disassembly_with_off_switch.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 7 12:09:56 2014 From: report at bugs.python.org (Berker Peksag) Date: Sun, 07 Sep 2014 10:09:56 +0000 Subject: [issue8315] ./python -m unittest test.test_importlib doesn't work In-Reply-To: <1270481793.28.0.468676978723.issue8315@psf.upfronthosting.co.za> Message-ID: <1410084596.2.0.378963126896.issue8315@psf.upfronthosting.co.za> Berker Peksag added the comment: test_importlib has been fixed in issue 22002. $ ./python -m unittest test.test_importlib ---------------------------------------------------------------------- Ran 963 tests in 1.533s OK (skipped=15, expected failures=1) ---------- nosy: +berker.peksag resolution: -> out of date stage: -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 7 12:30:23 2014 From: report at bugs.python.org (Berker Peksag) Date: Sun, 07 Sep 2014 10:30:23 +0000 Subject: [issue22200] Remove distutils checks for Python version In-Reply-To: <1408052221.61.0.16718662323.issue22200@psf.upfronthosting.co.za> Message-ID: <1410085823.42.0.284598032958.issue22200@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 7 14:12:13 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 07 Sep 2014 12:12:13 +0000 Subject: [issue22299] resolve() on Windows makes some pathological paths unusable In-Reply-To: <1409318228.27.0.489471733533.issue22299@psf.upfronthosting.co.za> Message-ID: <1410091933.17.0.609370233066.issue22299@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I'm a bit worried about the consequences still. If you take "C:" and join it with e.g. "foo", you get a drive-relative path. If you take "//?/C:/" and join it with e.g. "foo", you get an absolute path (or, if you remove the drive's trailing slash, you get something that's invalid AFAIK). So the question is: how implicit/explicit will the conversion be, and at which stages will it happen? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 7 14:35:32 2014 From: report at bugs.python.org (Mateusz Dobrowolny) Date: Sun, 07 Sep 2014 12:35:32 +0000 Subject: [issue22353] re.findall() documentation lacks information about finding THE LAST iteration of reoeated capturing group (greedy) Message-ID: <1410093332.63.0.87948506622.issue22353@psf.upfronthosting.co.za> New submission from Mateusz Dobrowolny: Python 3.4.1, Windows. help(re.findall) shows me: findall(pattern, string, flags=0) Return a list of all non-overlapping matches in the string. If one or more capturing groups are present in the pattern, return a list of groups; this will be a list of tuples if the pattern has more than one group. Empty matches are included in the result. It seems like there is missing information regarding greedy groups, i.e. (regular_expression)* Please take a look at my example: -------------EXAMPLE------------- import re text = 'To configure your editing environment, use the Editor settings page and its child pages. There is also a ' \ 'Quick Switch Scheme command that lets you change color schemes, themes, keymaps, etc. with a couple of ' \ 'keystrokes.' print('Text to be searched: \n' + text) print('\nSarching method: re.findall()') regexp_result = re.findall(r'\w+(\s+\w+)', text) print('\nRegexp rule: r\'\w+(\s+\w+)\' \nFound: ' + str(regexp_result)) print('This works as expected: findall() returns a list of groups (\s+\w+), and the groups are from non-overlapping matches.') regexp_result = re.findall(r'\w+(\s+\w+)*', text) print('\nHow about making the group greedy? Here we go: \nRegexp rule: r\'\w+(\s+\w+)*\' \nFound: ' + str(regexp_result)) print('This is a little bit unexpected for me: findall() returns THE LAST MATCHING group only, parsing from-left-to-righ.') regexp_result_list = re.findall(r'(\w+(\s+\w+)*)', text) first_group = list(i for i, j in regexp_result_list) print('\nThe solution is to put an extra group aroung the whole RE: \nRegexp rule: r\'(\w+(\s+\w+)*)\' \nFound: ' + str(first_group)) print('So finally I can get all strings I am looking for, just like expected from the FINDALL method, by accessing first elements in tuples.') ----------END OF EXAMPLE------------- I found the solution when practicing on this page: http://regex101.com/#python Entering: REGULAR EXPRESSION: \w+(\s+\w+)* TEST STRING: To configure your editing environment, use the Editor settings page and its child pages. There is also a Quick Switch Scheme command that lets you change color schemes, themes, keymaps, etc. with a couple of keystrokes. it showed me on the right side with nice color-coding: 1st Capturing group (\s+\w+)* Quantifier: Between zero and unlimited times, as many times as possible, giving back as needed [greedy] Note: A repeated capturing group will only capture the last iteration. Put a capturing group around the repeated group to capture all iterations or use a non-capturing group instead if you're not interested in the data I think some information regarding repeated groups should be included as well in Python documentation. BTW: I have one extra question. Searching for 'findall' in this tracker I found this issue: http://bugs.python.org/issue3384 It looks like information about ordering information is no longer in 3.4.1 documentation. Shouldn't this be there? Kind Regards ---------- assignee: docs at python components: Documentation messages: 226534 nosy: Mateusz.Dobrowolny, docs at python priority: normal severity: normal status: open title: re.findall() documentation lacks information about finding THE LAST iteration of reoeated capturing group (greedy) versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 7 14:49:20 2014 From: report at bugs.python.org (Mateusz Dobrowolny) Date: Sun, 07 Sep 2014 12:49:20 +0000 Subject: [issue22353] re.findall() documentation lacks information about finding THE LAST iteration of repeated capturing group (greedy) In-Reply-To: <1410093332.63.0.87948506622.issue22353@psf.upfronthosting.co.za> Message-ID: <1410094160.19.0.421257973563.issue22353@psf.upfronthosting.co.za> Changes by Mateusz Dobrowolny : ---------- title: re.findall() documentation lacks information about finding THE LAST iteration of reoeated capturing group (greedy) -> re.findall() documentation lacks information about finding THE LAST iteration of repeated capturing group (greedy) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 7 15:17:02 2014 From: report at bugs.python.org (Christian Kleineidam) Date: Sun, 07 Sep 2014 13:17:02 +0000 Subject: [issue22354] Highlite tabs in the IDLE Message-ID: <1410095822.07.0.751550923398.issue22354@psf.upfronthosting.co.za> New submission from Christian Kleineidam: Python accepts both tabs and spaces. Code that mixes tab and spaces can lead to problematic issues. Especially beginners who are new to python can be confused if they copy some code and it doesn't work as they expected because of issues of invisible whitespace. Beginners are also more likely to use the editor that comes with the IDLE instead of using a more specialised editor. If the IDLE would highlite the fact that tabs are used instead of spaces, it would be easier to spot the issue. I therefore suggest that the IDLE highlites tabs both in the shell mode and the editor mode. Possible ways to highlite is to have a light grey: <--> ? (at the beginning of the tab) PyCharm style error underlining ---------- components: IDLE messages: 226535 nosy: Christian.Kleineidam priority: normal severity: normal status: open title: Highlite tabs in the IDLE type: enhancement versions: 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 Sun Sep 7 15:21:18 2014 From: report at bugs.python.org (Saimadhav Heblikar) Date: Sun, 07 Sep 2014 13:21:18 +0000 Subject: [issue18766] IDLE: Autocomplete in editor doesn't work for un-imported modules In-Reply-To: <1376703586.47.0.0617094548794.issue18766@psf.upfronthosting.co.za> Message-ID: <1410096078.5.0.276850800086.issue18766@psf.upfronthosting.co.za> Saimadhav Heblikar added the comment: Hi Terry, Would it be better if the current inlined code is moved into get_entity? It will also make it easier to test. The try:... except ImportError block be present within the get_entity method itself? Otherwise, I will make a patch on what you said earlier in http://bugs.python.org/issue18766#msg224663. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 7 16:45:41 2014 From: report at bugs.python.org (Iestyn Elfick) Date: Sun, 07 Sep 2014 14:45:41 +0000 Subject: [issue22355] inconsistent results with inspect.getsource() / inspect.getsourcelines() Message-ID: <1410101141.24.0.25482778458.issue22355@psf.upfronthosting.co.za> New submission from Iestyn Elfick: The functions inspect.getsource() and inspect.getsourcelines() return inconsistent results for frames corresponding to class definitions within a function. Test code: import sys import inspect def case1(): class C: def __init__(self): pass c = C() def case2(): a = 1 class C: def __init__(self): pass c = C() def case3(): def fn(): pass class C: def __init__(self): pass c = C() def trace(frame,event,arg): code = frame.f_code print('name:',code.co_name) print('source:\n',inspect.getsource(code),'\n') for case in ('case1','case2','case3'): print('#####',case) call = getattr(sys.modules[__name__],case) sys.settrace(trace) try: call() finally: sys.settrace(None) Result: ##### case1 name: case1 source: def case1(): class C: def __init__(self): pass c = C() name: C source: def case1(): class C: def __init__(self): pass c = C() name: __init__ source: def __init__(self): pass ##### case2 name: case2 source: def case2(): a = 1 class C: def __init__(self): pass c = C() name: C source: def case2(): a = 1 class C: def __init__(self): pass c = C() name: __init__ source: def __init__(self): pass ##### case3 name: case3 source: def case3(): def fn(): pass class C: def __init__(self): pass c = C() name: C source: def fn(): pass name: __init__ source: def __init__(self): pass The source listed for frames named 'C' (the class creation code) is not consistent across all three cases. It could be considered incorrect in all cases as it does not correspond only to the class definition source lines. ---------- components: Library (Lib) messages: 226537 nosy: isedev priority: normal severity: normal status: open title: inconsistent results with inspect.getsource() / inspect.getsourcelines() type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 7 17:42:25 2014 From: report at bugs.python.org (Iestyn Elfick) Date: Sun, 07 Sep 2014 15:42:25 +0000 Subject: [issue22355] inconsistent results with inspect.getsource() / inspect.getsourcelines() In-Reply-To: <1410101141.24.0.25482778458.issue22355@psf.upfronthosting.co.za> Message-ID: <1410104545.64.0.977572846825.issue22355@psf.upfronthosting.co.za> Iestyn Elfick added the comment: Possible fix: --- /usr/lib64/python3.3/inspect.py 2014-06-30 19:21:52.000000000 +0200 +++ inspect.py 2014-09-07 17:41:29.463936079 +0200 @@ -600,7 +600,8 @@ if not hasattr(object, 'co_firstlineno'): raise IOError('could not find function definition') lnum = object.co_firstlineno - 1 - pat = re.compile(r'^(\s*def\s)|(.*(? 0: if pat.match(lines[lnum]): break lnum = lnum - 1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 7 19:20:44 2014 From: report at bugs.python.org (Akira Li) Date: Sun, 07 Sep 2014 17:20:44 +0000 Subject: [issue22356] mention explicitly that stdlib assumes gmtime(0) epoch is 1970 Message-ID: <1410110444.5.0.966357232963.issue22356@psf.upfronthosting.co.za> New submission from Akira Li: See discussion on Python-ideas https://mail.python.org/pipermail/python-ideas/2014-September/029228.html ---------- assignee: docs at python components: Documentation files: docs-time-epoch_is_1970.diff keywords: patch messages: 226539 nosy: akira, docs at python priority: normal severity: normal status: open title: mention explicitly that stdlib assumes gmtime(0) epoch is 1970 type: behavior versions: Python 2.7, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file36567/docs-time-epoch_is_1970.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 7 20:03:52 2014 From: report at bugs.python.org (eryksun) Date: Sun, 07 Sep 2014 18:03:52 +0000 Subject: [issue22299] resolve() on Windows makes some pathological paths unusable In-Reply-To: <1409318228.27.0.489471733533.issue22299@psf.upfronthosting.co.za> Message-ID: <1410113032.32.0.36031178343.issue22299@psf.upfronthosting.co.za> eryksun added the comment: > If you take "//?/C:/" and join it with e.g. "foo", you get an > absolute path (or, if you remove the drive's trailing slash, you > get something that's invalid AFAIK). FYI, DOS device names such as "C:" are NT symlinks. Win32 looks for DOS device links in NT's \Global?? directory, and also per logon-session in \Sessions\0\DosDevices\LOGON_ID. A link named "C:foo" is actually possible: >>> windll.kernel32.DefineDosDeviceW(0, "C:foo", "C:\\Python34") 1 >>> gfpn = os.path._getfinalpathname >>> gfpn(r'\\?\C:foo') '\\\\?\\C:\\Python34' >>> os.listdir(r'\\?\C:foo') ['DLLs', 'Doc', 'include', 'Lib', 'libs', 'LICENSE.txt', 'NEWS.txt', 'python.exe', 'pythonw.exe', 'README.txt', 'Scripts', 'tcl', 'Tools'] GLOBALROOT links to the native NT root: >>> gfpn('\\\\?\\GLOBALROOT\\Global??\C:\\') '\\\\?\\C:\\' >>> gfpn('\\\\?\\GLOBALROOT\\Device\\HarddiskVolume1\\') '\\\\?\\C:\\' >>> gfpn(r'\\?\GLOBALROOT\SystemRoot') '\\\\?\\C:\\Windows' >>> p = r'\\?\GLOBALROOT\Sessions\0\DosDevices\00000000-0f341de9\C:foo' >>> gfpn(p) '\\\\?\\C:\\Python34' Without the \\?\ prefix, "C:foo" is relative to the current directory on the C: drive: >>> os.chdir('C:\\') >>> os.mkdir('foo') >>> os.listdir('C:foo') [] where the current directory on C: is stored in the "=C:" environment variable: >>> buf = (c_wchar * 100)() >>> windll.kernel32.GetEnvironmentVariableW("=C:", buf) 3 >>> buf.value 'C:\\' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 7 21:06:27 2014 From: report at bugs.python.org (Petr Viktorin) Date: Sun, 07 Sep 2014 19:06:27 +0000 Subject: [issue22198] Odd floor-division corner case In-Reply-To: <1408034861.79.0.503776123394.issue22198@psf.upfronthosting.co.za> Message-ID: <1410116787.74.0.898377617203.issue22198@psf.upfronthosting.co.za> Petr Viktorin added the comment: I tried my hand at writing a patch. I hope it is helpful. The message of the 2001 commit that introduces this says that "there's no platform-independent way to write a test case for this". I assume with @support.requires_IEEE_754 that is no longer true (at least for non-exotic platforms), or was there another issue? I noticed there is no test suite for float floordiv, so I attempted writing a fuller one, but when I saw that >>> float('inf') // 1.0 nan I decided to keep my first CPython patch small and focused, so I can learn the ropes. I'll file more issues later. ---------- keywords: +patch nosy: +encukou Added file: http://bugs.python.org/file36568/issue22198.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 7 21:11:56 2014 From: report at bugs.python.org (Petr Viktorin) Date: Sun, 07 Sep 2014 19:11:56 +0000 Subject: [issue22198] Odd floor-division corner case In-Reply-To: <1408034861.79.0.503776123394.issue22198@psf.upfronthosting.co.za> Message-ID: <1410117116.74.0.298818649453.issue22198@psf.upfronthosting.co.za> Petr Viktorin added the comment: Note: I signed the contributor agreement form recently, I should have a * soon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 7 22:30:31 2014 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 07 Sep 2014 20:30:31 +0000 Subject: [issue22353] re.findall() documentation lacks information about finding THE LAST iteration of repeated capturing group (greedy) In-Reply-To: <1410093332.63.0.87948506622.issue22353@psf.upfronthosting.co.za> Message-ID: <1410121831.18.0.460353214891.issue22353@psf.upfronthosting.co.za> Guido van Rossum added the comment: Do you have a specific sentence or paragraph in mind that could be added? Be aware help() just shows what's in the docstring, which is typically abbreviated. The full docs are on docs.python.org. Can you find what you need there? ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 7 23:03:01 2014 From: report at bugs.python.org (Alex Lord) Date: Sun, 07 Sep 2014 21:03:01 +0000 Subject: [issue22212] zipfile.py fails if zlib.so module fails to build. In-Reply-To: <1408224552.38.0.698985209475.issue22212@psf.upfronthosting.co.za> Message-ID: <1410123781.78.0.448154789853.issue22212@psf.upfronthosting.co.za> Alex Lord added the comment: Just adding that I have also run into this problem. ---------- nosy: +Alex.Lord _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 7 23:11:47 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Sun, 07 Sep 2014 21:11:47 +0000 Subject: [issue22257] PEP 432: Redesign the interpreter startup sequence In-Reply-To: <1408789351.84.0.0171822343712.issue22257@psf.upfronthosting.co.za> Message-ID: <1410124307.4.0.0391860828712.issue22257@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 7 23:23:13 2014 From: report at bugs.python.org (Iestyn Elfick) Date: Sun, 07 Sep 2014 21:23:13 +0000 Subject: [issue22357] inspect module documentation make no reference to __qualname__ attribute Message-ID: <1410124992.98.0.0231359390306.issue22357@psf.upfronthosting.co.za> New submission from Iestyn Elfick: The documentation for the 'inspect' module should list the '__qualname__' attribute for 'method', 'function' and 'builtin' types in section '29.12.1 Types and members'. ---------- assignee: docs at python components: Documentation messages: 226545 nosy: docs at python, isedev priority: normal severity: normal status: open title: inspect module documentation make no reference to __qualname__ attribute type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 7 23:23:42 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 07 Sep 2014 21:23:42 +0000 Subject: [issue5309] distutils doesn't parallelize extension module compilation In-Reply-To: <1235007592.93.0.0598331575131.issue5309@psf.upfronthosting.co.za> Message-ID: <1410125022.25.0.497531571471.issue5309@psf.upfronthosting.co.za> ?ric Araujo added the comment: > self.parallel = int(self.parallel) would raise ValueError when a > non-number is passed. I suggest to print user-friendly error message. The distutils idiom would be to catch the TypeError/ValueError and raise DistutilsOptionError. Higher layers convert that to a message. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 00:48:44 2014 From: report at bugs.python.org (Iestyn Elfick) Date: Sun, 07 Sep 2014 22:48:44 +0000 Subject: [issue22357] inspect module documentation makes no reference to __qualname__ attribute In-Reply-To: <1410124992.98.0.0231359390306.issue22357@psf.upfronthosting.co.za> Message-ID: <1410130124.76.0.761241126161.issue22357@psf.upfronthosting.co.za> Changes by Iestyn Elfick : ---------- title: inspect module documentation make no reference to __qualname__ attribute -> inspect module documentation makes no reference to __qualname__ attribute _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 01:15:51 2014 From: report at bugs.python.org (Attila Fazekas) Date: Sun, 07 Sep 2014 23:15:51 +0000 Subject: [issue22358] Unnecessary JUMP_FORWARD(0) (NOP) in if statements without else or elif Message-ID: <1410131751.3.0.286807905275.issue22358@psf.upfronthosting.co.za> New submission from Attila Fazekas: The following example function compiles to bytecode which contains, an unnecessary JUMP_FORWARD 0 instruction: def func(): if a: pass Actual: dis.dis(func) 2 0 LOAD_GLOBAL 0 (a) 3 POP_JUMP_IF_FALSE 9 6 JUMP_FORWARD 0 (to 9) >> 9 LOAD_CONST 0 (None) 12 RETURN_VALUE Expected: dis.dis(func) 2 0 LOAD_GLOBAL 0 (a) 3 POP_JUMP_IF_FALSE 6 >> 6 LOAD_CONST 0 (None) 9 RETURN_VALUE The above JUMP_FORWARD instruction increases the code size and also has a negative performance effect. I do not see any reason to have the extra NOP in the byte code in this case. *** The attached patch removes this NOP generation from the code compilation part, so it will take effect by default. I had a little trouble when the code compiled from ast, because the If.orelse had a different content. (NULL vs. zero sizes asdl_seq) * The generated Assembly code updated in dis unit test. * The compilation test updated to test a real 'if' by using a variable in the condition. (The True and False is not a variable anymore) ---------- components: Interpreter Core files: python_nop_ifelse.patch keywords: patch messages: 226547 nosy: Attila.Fazekas priority: normal severity: normal status: open title: Unnecessary JUMP_FORWARD(0) (NOP) in if statements without else or elif type: performance 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/file36569/python_nop_ifelse.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 02:11:12 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 08 Sep 2014 00:11:12 +0000 Subject: [issue22358] Unnecessary JUMP_FORWARD(0) (NOP) in if statements without else or elif In-Reply-To: <1410131751.3.0.286807905275.issue22358@psf.upfronthosting.co.za> Message-ID: <1410135072.15.0.00754179246845.issue22358@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 02:22:18 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 08 Sep 2014 00:22:18 +0000 Subject: [issue17095] Modules/Setup *shared* support broken In-Reply-To: <1359669296.59.0.227426586133.issue17095@psf.upfronthosting.co.za> Message-ID: <1410135738.45.0.844568809365.issue17095@psf.upfronthosting.co.za> Ned Deily added the comment: Clearly this breaks running from the build directory for various modules when their optional C extension module build fails. I'll either change the Setup shared builds to use a build directory or revert the path changes prior to the upcoming 3.4.2. ---------- assignee: -> ned.deily nosy: +larry priority: normal -> release blocker stage: resolved -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 02:25:40 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 08 Sep 2014 00:25:40 +0000 Subject: [issue22285] The Modules/ directory should not be added to sys.path In-Reply-To: <1409134067.89.0.764298356643.issue22285@psf.upfronthosting.co.za> Message-ID: <1410135940.3.0.0641153873622.issue22285@psf.upfronthosting.co.za> Ned Deily added the comment: Closing as a duplicate of the re-opened Issue17095 (since the changes there haven't been released yet) ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Modules/Setup *shared* support broken versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 02:28:28 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 08 Sep 2014 00:28:28 +0000 Subject: [issue22212] zipfile.py fails if zlib.so module fails to build. In-Reply-To: <1408224552.38.0.698985209475.issue22212@psf.upfronthosting.co.za> Message-ID: <1410136108.58.0.498225718105.issue22212@psf.upfronthosting.co.za> Ned Deily added the comment: This problem has been introduced by the initial changes for Issue17095. That issue has been re-opened and the resolution will be covered there. ---------- nosy: +ned.deily resolution: -> duplicate stage: needs patch -> resolved status: open -> closed superseder: -> Modules/Setup *shared* support broken _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 03:30:44 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 08 Sep 2014 01:30:44 +0000 Subject: [issue19884] Importing readline produces erroneous output In-Reply-To: <1386158776.45.0.265770743985.issue19884@psf.upfronthosting.co.za> Message-ID: <1410139844.11.0.949800887022.issue19884@psf.upfronthosting.co.za> Ned Deily added the comment: Should this be a release blocker for 3.4.2? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 04:04:03 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 08 Sep 2014 02:04:03 +0000 Subject: [issue21112] 3.4 regression: unittest.expectedFailure no longer works on TestCase subclasses In-Reply-To: <1396275626.74.0.920741880392.issue21112@psf.upfronthosting.co.za> Message-ID: <1410141843.8.0.912045228619.issue21112@psf.upfronthosting.co.za> Ned Deily added the comment: Should this be fixed for 3.4.2? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 04:05:09 2014 From: report at bugs.python.org (Larry Hastings) Date: Mon, 08 Sep 2014 02:05:09 +0000 Subject: [issue21112] 3.4 regression: unittest.expectedFailure no longer works on TestCase subclasses In-Reply-To: <1396275626.74.0.920741880392.issue21112@psf.upfronthosting.co.za> Message-ID: <1410141909.68.0.526129258356.issue21112@psf.upfronthosting.co.za> Larry Hastings added the comment: Note: current plan for 3.4.2 is to release at the end of the month. RC1 will be in about a week. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 04:24:38 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 08 Sep 2014 02:24:38 +0000 Subject: [issue22358] Unnecessary JUMP_FORWARD(0) (NOP) in if statements without else or elif In-Reply-To: <1410131751.3.0.286807905275.issue22358@psf.upfronthosting.co.za> Message-ID: <1410143078.73.0.408453742665.issue22358@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: What about the peephole optimizer?. ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 04:38:40 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 08 Sep 2014 02:38:40 +0000 Subject: [issue19693] "make altinstall && make install" behaviour differs from "make install" In-Reply-To: <1385131154.65.0.84746252058.issue19693@psf.upfronthosting.co.za> Message-ID: <1410143920.23.0.18464787006.issue19693@psf.upfronthosting.co.za> Ned Deily added the comment: Ping. Also this will be presumably be an issue for the approved 2.7.x backport of ensurepip. ---------- versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 04:41:40 2014 From: report at bugs.python.org (John Malmberg) Date: Mon, 08 Sep 2014 02:41:40 +0000 Subject: [issue17095] Modules/Setup *shared* support broken In-Reply-To: <1359669296.59.0.227426586133.issue17095@psf.upfronthosting.co.za> Message-ID: <1410144100.03.0.482067964854.issue17095@psf.upfronthosting.co.za> Changes by John Malmberg : ---------- nosy: +John.Malmberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 05:13:42 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 08 Sep 2014 03:13:42 +0000 Subject: [issue15594] test_copyfile_named_pipe() fails on Mac OS X Snow Leopard: OSError: [Errno 22] Invalid argument In-Reply-To: <1344457655.9.0.373688420399.issue15594@psf.upfronthosting.co.za> Message-ID: <1410146022.87.0.0327226932315.issue15594@psf.upfronthosting.co.za> Ned Deily added the comment: Closing since there have been no further reports of this problem and this buildbot is no longer connected ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 06:12:10 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 08 Sep 2014 04:12:10 +0000 Subject: [issue11487] build_installer.py should avoid relying on a young Python In-Reply-To: <1300053776.08.0.54704271531.issue11487@psf.upfronthosting.co.za> Message-ID: <1410149530.23.0.187147807732.issue11487@psf.upfronthosting.co.za> Ned Deily added the comment: The changes for Issue21383 added calls to "make touch" to build_installer.py so the initial problem reported here should no longer occur on any OS X installer build. As to the more general problem of needing to use "make touch" because hg checkouts do not preserve original file checkin time orders, there have been multiple issues opened (and closed) on that subject; there's no need to keep this issue open for that. ---------- resolution: -> out of date stage: -> resolved status: open -> closed versions: +Python 3.4, Python 3.5 -Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 07:57:28 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 08 Sep 2014 05:57:28 +0000 Subject: [issue19884] Importing readline produces erroneous output In-Reply-To: <1410139844.11.0.949800887022.issue19884@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: The test fails on some platforms but it's not a regression. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 09:03:35 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 08 Sep 2014 07:03:35 +0000 Subject: [issue18766] IDLE: Autocomplete in editor doesn't work for un-imported modules In-Reply-To: <1376703586.47.0.0617094548794.issue18766@psf.upfronthosting.co.za> Message-ID: <1410159815.97.0.321287589221.issue18766@psf.upfronthosting.co.za> Terry J. Reedy added the comment: This issue is about name completion and not path completion. I have re-reviewed the patch, current code, current behavior, and the fetch_completions doctstring that more or less explains why name completion cannot reliably work given how Idle now works. I would add to the docstring that even after running the editor file and before running anything else, there can still be problems. If one adds 'from mod import SomeClass' and types 'SomeClass.', there will be no help. This patch will not help either. Getting completions for 'sc.', where 'sc' is an instance of SomeClass, without running code, is an even harder problem. There is, in a sense, no substitute for running the code up to the point where name completion is wanted. Perhaps an explicit Show Completions(Name completion seems fairly common; I wonder how other editors handle it.) Idle once ran user code in the idle process, which meant that any module ever imported by running any editor buffer would still be in sys.modules. Thus looking for modules in the Idle process sys.modules was more or less guaranteed to work, and would substitute for the user __main__ module (within the Idle process) being cleared by running another editor buffer. Idle now, without the -N option, runs edited files in a *new* user processes. The problem for name completion (and calltips, and shell interaction with the old process) is that Idle discards the previous user process. So running file B discards the information needed for name completion with file A. A possible solution to this is to keep a user process for each file and not discard information we may want. I thought of this idea about a month ago because I am sometimes annoyed when running any file discards an interactive shell process I am not really done with. After running a file, I sometimes retype or rerun code to recreate the bidings I had before running an editor file. This change would also help this issue and a similar one with calltips. I plan to make this proposal the subject of another issue. If I open Idle with Shell and open a new editor window, then, as Phil noted, typing 're.' and waiting brings up a list of re attributes, whereas 'datetime.' does not. A year ago, 'textwrap.' did not, whereas now it does, thus illustratig the arbitrary nature of current behavior. Phil's proposal is to make 'datetime.' act like 're.' by importing datetime. There are two things I do not like about this. First, if there is no 'import re' in the file, then putting, say, 're.DOTALL' into the file is a bug in that it will be a NameError when the file is run. I might rather make 'import re' work like 'import datetime', that is fail, by not using sys.module as a backup. Second, the import is done in a process that does not belong to the editor, adding a name binding where is does not belong, and will have to be done again when the file is run. Phil notes that the current workaround it to do the import in the shell (which, as noted, does it in the wrong place) or run the file (which, as noted, deleted the current process). If there were a separate process for each editor, then either running the process or doing the import would not have the problems listed above. If we did do an auto import, it would be under the presumption that it would be imported into that particular process in a later run. We could also think about doing something else, like checking whether 'import xxx' is in the file and either inserting it or at least warning the user to do so. I would add to the docstring that even after running the editor file and before running anything else, there can still be problems. If one adds 'from mod import SomeClass' and types 'SomeClass.', there will be no help. This patch will not help either. Getting completions for 'sc.', where 'sc' is an instance of SomeClass, without running code, is an even harder problem. There is, in a sense, no substitute for running the code up to the point where name completion is wanted. Perhaps an explicit Show Completions or Cntl-Space should do so. This would be more feasible with a separate process so it did not have the side effect of killing the existing user process. Name completion seems fairly common; I wonder how other editors handle it. --- In my previous post, I suggested that get_entity does too much by copying to namespaces into one, looking up one name, and discarding the new combined namespace. Looking more, it also occurs to me that the eval is not needed, as eval(name, namespace) is the same as getattr(name, namespace). I believe the following would do what the current get_entity does. it now does. def get_entity(name): # should be a standalone utility function try: ob = __main__.__dict__[name] except KeyError: try: ob = sys.modules[name] except KeyError: raise NameError('cannot find %s' % name) from None return ob With this version, the patch would amount to adding try: import name as ob except ImportError before giving up and raising. I agree that keeping get_entiry separate (as a function, since self is not used) might make testing easier. The same might be reason to pull more code into separate, more easily tested, units. So lets keep it separate for now. The real issue is whether the idea of the patch is a good one or not for how Idle currently works. ---------- type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 09:28:36 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 08 Sep 2014 07:28:36 +0000 Subject: [issue22358] Unnecessary JUMP_FORWARD(0) (NOP) in if statements without else or elif In-Reply-To: <1410131751.3.0.286807905275.issue22358@psf.upfronthosting.co.za> Message-ID: <1410161316.8.0.310995791927.issue22358@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is a duplicate of issue11471. Explicit check for NULL is not needed because the asdl_seq_LEN() macro checks its argument for NULL. ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> If without else generates redundant jump versions: -Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 09:32:49 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 08 Sep 2014 07:32:49 +0000 Subject: [issue11471] If without else generates redundant jump In-Reply-To: <1299880156.4.0.0999870554397.issue11471@psf.upfronthosting.co.za> Message-ID: <1410161569.36.0.0122401948427.issue11471@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. Attila Fazekas just has provided almost the same patch in issue22358. ---------- stage: patch review -> commit review versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 09:42:44 2014 From: report at bugs.python.org (Michael Foord) Date: Mon, 08 Sep 2014 07:42:44 +0000 Subject: [issue21112] 3.4 regression: unittest.expectedFailure no longer works on TestCase subclasses In-Reply-To: <1396275626.74.0.920741880392.issue21112@psf.upfronthosting.co.za> Message-ID: <1410162164.03.0.888469660105.issue21112@psf.upfronthosting.co.za> Michael Foord added the comment: The patch looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 10:31:22 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 08 Sep 2014 08:31:22 +0000 Subject: [issue20071] What should happen if someone runs ./python -m ensurepip in the build environment? In-Reply-To: <1388078726.11.0.20000173411.issue20071@psf.upfronthosting.co.za> Message-ID: <1410165082.49.0.242923795356.issue20071@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +dstufft, ncoghlan, ned.deily versions: +Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 10:33:26 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 08 Sep 2014 08:33:26 +0000 Subject: [issue20417] ensurepip should not be installed with --without-ensurepip In-Reply-To: <1390910081.3.0.794745591099.issue20417@psf.upfronthosting.co.za> Message-ID: <1410165206.78.0.181005057247.issue20417@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 10:44:29 2014 From: report at bugs.python.org (Jonas Wagner) Date: Mon, 08 Sep 2014 08:44:29 +0000 Subject: [issue22359] Remove incorrect uses of recursive make Message-ID: <1410165869.76.0.203082844365.issue22359@psf.upfronthosting.co.za> New submission from Jonas Wagner: The attached patch fixes issues with Python's Makefile, which manifest when doing parallel builds. The Makefile invoked "make" recursively for some targets. This caused some files (which were depended upon by multiple targets) to be built by both the original "make" and the sub-"make". Besides duplicate work, this caused failed builds with non-threadsafe compilers. The proposed patch removes recursive calls to "make", and instead builds all targets in the same "make" process. ---------- components: Build files: makefile_parallel.patch keywords: patch messages: 226563 nosy: Sjlver priority: normal severity: normal status: open title: Remove incorrect uses of recursive make type: compile error versions: Python 3.5 Added file: http://bugs.python.org/file36570/makefile_parallel.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 11:29:02 2014 From: report at bugs.python.org (Christoph Wruck) Date: Mon, 08 Sep 2014 09:29:02 +0000 Subject: [issue22360] Adding manually offset parameter to str/bytes split function Message-ID: <1410168542.37.0.66219638693.issue22360@psf.upfronthosting.co.za> New submission from Christoph Wruck: Currently we have a "split" function which splits a str/bytestr into chunks of their underlying data. This works great for the most tivial jobs. But there is no possibility to pass an offset parameter into the split function which indicates the next "user-defined" starting index. Actually the next starting position will be build upon the last starting position (of found sep.) + separator length + 1. It should be possible to manipulate the next starting index by changing this behavior into: last starting position (of found sep.) + separator length + OFFSET. NOTE: The slicing start index (for substring) stay untouched. This will help us to solve splitting sequences with one or more consecutive separators. The following demonstrates the actually behavior. >>> s = 'abc;;def;hij' >>> s.split(';') ['abc', '', 'def', 'hij'] This works fine for both str/bytes values. The following demonstrates an "offset variant" of split function. >>> s = 'abc;;def;hij' >>> s.split(';', offset=1) ['abc', ';def', 'hij'] The behavior of maxcount/None sep. parameter should be generate the same output as before. A change will be affect (as far as I can see): - split.h - split_char/rsplit_char - split/rsplit ---------- messages: 226564 nosy: cwr priority: normal severity: normal status: open title: Adding manually offset parameter to str/bytes split function type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 11:44:18 2014 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 08 Sep 2014 09:44:18 +0000 Subject: [issue19693] "make altinstall && make install" behaviour differs from "make install" In-Reply-To: <1410143920.23.0.18464787006.issue19693@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: No change for 3.x (unless something changed on the pip side that I'm not aware of). For 2.7, the Makefile changes, at least for the install and altinstall targets, were deliberately excluded from the backport PEP. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 11:50:54 2014 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 08 Sep 2014 09:50:54 +0000 Subject: [issue20417] ensurepip should not be installed with --without-ensurepip In-Reply-To: <1390910081.3.0.794745591099.issue20417@psf.upfronthosting.co.za> Message-ID: <1410169854.88.0.220033736164.issue20417@psf.upfronthosting.co.za> Nick Coghlan added the comment: As Donald notes, this was explicitly covered in the PEP: the onus is on the distros to make ensurepip and pyvenv work in a way that complies with their debundling requirements (e.g. by using rewheel, or redirecting to the system installer). The "--without-ensurepip" flag is there to disable running it at install time. Fully removing the ensurepip module is not a supported configuration - if a distro wants to do that, they're going to have to carry a patch. ---------- resolution: -> wont fix stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 12:15:45 2014 From: report at bugs.python.org (Mateusz Dobrowolny) Date: Mon, 08 Sep 2014 10:15:45 +0000 Subject: [issue22353] re.findall() documentation lacks information about finding THE LAST iteration of repeated capturing group (greedy) In-Reply-To: <1410093332.63.0.87948506622.issue22353@psf.upfronthosting.co.za> Message-ID: <1410171345.37.0.592776261776.issue22353@psf.upfronthosting.co.za> Mateusz Dobrowolny added the comment: The official help https://docs.python.org/3/library/re.html?highlight=findall#re.findall in fact contains more information, especially the one mentioned in http://bugs.python.org/issue3384. Regarding my issue - I am afraid it was my misunderstanding, because it looks like Regular Expressions return always LAST match and Python re.findall reutrns what it is said to be: the list of groups. And since I repeat a captured group, I get only the last match. More here for example here: http://www.regular-expressions.info/captureall.html I was learning regexp yesterday, and first I reported this without knowing everytnig about capturing groups. If returning the last match for repeting a capturing group is defined within RegEx itself, than there is no need to mention it in Python documentation... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 12:29:18 2014 From: report at bugs.python.org (Steven D'Aprano) Date: Mon, 08 Sep 2014 10:29:18 +0000 Subject: [issue22360] Adding manually offset parameter to str/bytes split function In-Reply-To: <1410168542.37.0.66219638693.issue22360@psf.upfronthosting.co.za> Message-ID: <1410172158.9.0.255448822483.issue22360@psf.upfronthosting.co.za> Steven D'Aprano added the comment: I'm afraid I don't understand the purpose of this feature request, or what the behaviour is. You show a simple example: >>> s = 'abc;;def;hij' >>> s.split(';', offset=1) ['abc', ';def', 'hij'] but I don't understand why you want to keep the second semi-colon. I would have thought this would be more useful: # treat runs of the separator as if it were a single separator ['abc', 'def', 'hij'] It might help if you explain under what circumstances you would use this. Also, how does the caller choose a value for offset? Say, I read a string from a data file, or from the user. How do I know what offset to use? I'm not sure I understand what this offset parameter is supposed to do in general. Here are some examples showing what I think you want, can you tell me if I'm right? 'spam--eggs--cheese----toast'.split('-', offset=1) --> ['spam', '-eggs', '-cheese', '-', '-toast'] 'spam--eggs--cheese--toast'.split('-', offset=8) --> ['spam', '-eggs--cheese', '-toast'] ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 12:29:45 2014 From: report at bugs.python.org (Luca Falavigna) Date: Mon, 08 Sep 2014 10:29:45 +0000 Subject: [issue22361] Ability to join() threads in concurrent.futures.ThreadPoolExecutor Message-ID: <1410172185.62.0.239101325071.issue22361@psf.upfronthosting.co.za> New submission from Luca Falavigna: I have a program which waits for external events (mostly pyinotify events), and when events occur a new worker is created using concurrent.futures.ThreadPoolExecutor. The following snippet represents shortly what my program does: from time import sleep from concurrent.futures import ThreadPoolExecutor def func(): print("start") sleep(10) print("stop") ex = ThreadPoolExecutor(1) # New workers will be scheduled when an event # is triggered (i.e. pyinotify events) ex.submit(func) # Dummy sleep sleep(60) When func() is complete, I'd like the underlying thread to be terminated. I realize I could call ex.shutdown() to achieve this, but this would prevent me from adding new workers in case new events occur. Not calling ex.shutdown() leads to have unfinished threads which pile up considerably: (gdb) run test.py Starting program: /usr/bin/python3.4-dbg test.py [Thread debugging using libthread_db enabled] [New Thread 0x7ffff688e700 (LWP 17502)] start stop ^C Program received signal SIGINT, Interrupt. 0x00007ffff6e41963 in select () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) info threads Id Target Id Frame 2 Thread 0x7ffff688e700 (LWP 17502) "python3.4-dbg" 0x00007ffff7bce420 in sem_wait () from /lib/x86_64-linux-gnu/libpthread.so.0 * 1 Thread 0x7ffff7ff1700 (LWP 17501) "python3.4-dbg" 0x00007ffff6e41963 in select () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) Would it be possible to add a new method (or a ThreadPoolExecutor option) which allows to join the underlying thread when the worker function returns? ---------- components: Library (Lib) messages: 226569 nosy: dktrkranz priority: normal severity: normal status: open title: Ability to join() threads in concurrent.futures.ThreadPoolExecutor type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 13:07:20 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 08 Sep 2014 11:07:20 +0000 Subject: [issue22362] Warn about octal escapes > 0o377 in re Message-ID: <1410174440.93.0.911211496637.issue22362@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Currently the re module accepts octal escapes from \400 to \777, but ignore highest bit. >>> re.search(r'\542', 'abc') <_sre.SRE_Match object; span=(1, 2), match='b'> This behavior looks surprising and is inconsistent with the regex module which preserve highest bit. Such escaping is not portable across different regular exception engines. I propose to add a warning when octal escape value is larger than 0o377. Here is preliminary patch which adds UserWarning. Or may be better to emit DeprecationWarning and then replace it by ValueError in future releases? ---------- components: Library (Lib), Regular Expressions files: re_octal_escape_overflow.patch keywords: patch messages: 226570 nosy: ezio.melotti, mrabarnett, pitrou, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Warn about octal escapes > 0o377 in re type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file36571/re_octal_escape_overflow.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 13:18:54 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 08 Sep 2014 11:18:54 +0000 Subject: [issue22360] Adding manually offset parameter to str/bytes split function In-Reply-To: <1410168542.37.0.66219638693.issue22360@psf.upfronthosting.co.za> Message-ID: <1410175134.93.0.475812304389.issue22360@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Such problems are solved by using regular expressions. >>> re.findall('(?:^|(?<=;)).?[^;]*', 'abc;;def;hij') ['abc', ';def', 'hij'] ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 13:45:43 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 08 Sep 2014 11:45:43 +0000 Subject: [issue22355] inconsistent results with inspect.getsource() / inspect.getsourcelines() In-Reply-To: <1410101141.24.0.25482778458.issue22355@psf.upfronthosting.co.za> Message-ID: <1410176743.3.0.177344949191.issue22355@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 13:46:27 2014 From: report at bugs.python.org (Zacrath) Date: Mon, 08 Sep 2014 11:46:27 +0000 Subject: [issue22363] argparse AssertionError with add_mutually_exclusive_group and help=SUPPRESS Message-ID: <1410176787.11.0.945188170372.issue22363@psf.upfronthosting.co.za> New submission from Zacrath: Executing the attached script causes an AssertionError. Traceback (most recent call last): File "bug.py", line 18, in parser.format_usage() File "/usr/lib/python3.4/argparse.py", line 2318, in format_usage return formatter.format_help() File "/usr/lib/python3.4/argparse.py", line 287, in format_help help = self._root_section.format_help() File "/usr/lib/python3.4/argparse.py", line 217, in format_help func(*args) File "/usr/lib/python3.4/argparse.py", line 338, in _format_usage assert ' '.join(opt_parts) == opt_usage AssertionError The script was tested in a clean Python installation. If any of the arguments are removed, there is no AssertionError exception. If "help=SUPPRESS" is removed, there is no AssertionError exception. This bug appears to have existed since Python 3.2, the first version that included argparse. ---------- files: bug.py messages: 226572 nosy: Zacrath, bethard priority: normal severity: normal status: open title: argparse AssertionError with add_mutually_exclusive_group and help=SUPPRESS type: behavior 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/file36572/bug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 13:47:39 2014 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 08 Sep 2014 11:47:39 +0000 Subject: [issue20071] What should happen if someone runs ./python -m ensurepip in the build environment? In-Reply-To: <1388078726.11.0.20000173411.issue20071@psf.upfronthosting.co.za> Message-ID: <1410176859.46.0.532211386216.issue20071@psf.upfronthosting.co.za> Nick Coghlan added the comment: The whole sys.path initialisation scheme is pretty broken when running from a source checkout, so the short answer is "it won't work, and it isn't really fixable in a maintenance release". System Python 3: sys.path = [ '/home/ncoghlan/devel/py3k', '/usr/lib64/python33.zip', '/usr/lib64/python3.3', '/usr/lib64/python3.3/plat-linux', '/usr/lib64/python3.3/lib-dynload', '/home/ncoghlan/.local/lib/python3.3/site-packages', '/usr/lib64/python3.3/site-packages', '/usr/lib/python3.3/site-packages', ] My source checkout: sys.path = [ '/home/ncoghlan/devel/py3k', '/usr/local/lib/python35.zip', '/home/ncoghlan/devel/py3k/Lib', '/home/ncoghlan/devel/py3k/Lib/plat-linux', '/home/ncoghlan/devel/py3k/build/lib.linux-x86_64-3.5', '/home/ncoghlan/devel/py3k/Modules', '/home/ncoghlan/.local/lib/python3.5/site-packages', ] We should probably have an explicit check for that in ensurepip so it bails out as an unsupported operation rather than doing something weird. Looking in sys.path for "os.path.join(os.path.dirname(sys.executable), 'Lib')" should be a fairly reliable indicator that we're running from a source checkout. Actually *fixing* it to do something sensible would require a lot of work on the sys.path initialisation code, and I frankly consider that impractical given the current state of getpath.c. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 13:51:44 2014 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 08 Sep 2014 11:51:44 +0000 Subject: [issue20071] What should happen if someone runs ./python -m ensurepip in the build environment? In-Reply-To: <1388078726.11.0.20000173411.issue20071@psf.upfronthosting.co.za> Message-ID: <1410177104.58.0.530511428934.issue20071@psf.upfronthosting.co.za> Nick Coghlan added the comment: Note that if I find time to implement the startup sequence redesign for PEP 432/issue #22257 (which is finally starting to look like it may actually happen some time in the next few months), a proper fix may end up being possible for 3.5. We shouldn't bet on that, though, and the explicit failure is definitely the best we'll be able to do for 3.4 and the 2.7 backport. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 14:03:45 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 08 Sep 2014 12:03:45 +0000 Subject: [issue22359] Remove incorrect uses of recursive make In-Reply-To: <1410165869.76.0.203082844365.issue22359@psf.upfronthosting.co.za> Message-ID: <1410177825.96.0.211056302871.issue22359@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +doko _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 14:22:56 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 08 Sep 2014 12:22:56 +0000 Subject: [issue22364] Unify error messages of re and regex Message-ID: <1410178976.27.0.421938794422.issue22364@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: In some cases standard re module and third-party regex modules raise exceptions with different error messages. 1. re.match(re.compile('.'), 'A', re.I) re: Cannot process flags argument with a compiled pattern regex: can't process flags argument with a compiled pattern 2. re.compile('(?P 3. re.compile('(?Pa)(?P=foo_123') re: unterminated name regex: missing ) 4. regex.sub('(?Px)', r'\g 5. re.sub('(?Px)', r'\g<', 'xx') re: unterminated group name regex: bad group name 6. re.sub('(?Px)', r'\g', 'xx') re: bad character in group name regex: bad group name 7. re.sub('(?Px)', r'\g<-1>', 'xx') re: negative group number regex: bad group name 8. re.compile('(?Pa)(?P=!)') re: bad character in backref group name '!' regex: bad group name 9. re.sub('(?Px)', r'\g', 'xx') re: missing group name regex: missing < 10. re.compile('a\\') re.sub('x', '\\', 'x') re: bogus escape (end of line) regex: bad escape 11. re.compile(r'\1') re: bogus escape: '\1' regex: unknown group 12. re.compile('[a-') re: unexpected end of regular expression regex: bad set 13. re.sub(b'.', 'b', b'c') re: expected bytes, bytearray, or an object with the buffer interface, str found regex: expected bytes instance, str found 14. re.compile(r'\w', re.UNICODE | re.ASCII) re: ASCII and UNICODE flags are incompatible regex: ASCII, LOCALE and UNICODE flags are mutually incompatible 15. re.compile('(abc') re: unbalanced parenthesis regex: missing ) 16. re.compile('abc)') re: unbalanced parenthesis regex: trailing characters in pattern 17. re.compile(r'((.)\1+)') re: cannot refer to open group regex: can't refer to an open group Looks as in one case re messages are better, and in other cases regex messages are better. In any case it would be good to unify error messages in both modules. ---------- components: Library (Lib), Regular Expressions messages: 226575 nosy: ezio.melotti, mrabarnett, pitrou, serhiy.storchaka priority: normal severity: normal status: open title: Unify error messages of re and regex type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 14:32:22 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 08 Sep 2014 12:32:22 +0000 Subject: [issue22364] Unify error messages of re and regex In-Reply-To: <1410178976.27.0.421938794422.issue22364@psf.upfronthosting.co.za> Message-ID: <1410179542.67.0.612026112865.issue22364@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: 18. re.compile(r'.???') re: multiple repeat regex: nothing to repeat at position 3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 14:40:06 2014 From: report at bugs.python.org (Philippe Devalkeneer) Date: Mon, 08 Sep 2014 12:40:06 +0000 Subject: [issue22327] test_gdb failures on Ubuntu 14.10 In-Reply-To: <1409690431.38.0.272932349651.issue22327@psf.upfronthosting.co.za> Message-ID: <1410180006.14.0.717105803044.issue22327@psf.upfronthosting.co.za> Changes by Philippe Devalkeneer : ---------- nosy: +flupke _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 14:43:44 2014 From: report at bugs.python.org (Christoph Wruck) Date: Mon, 08 Sep 2014 12:43:44 +0000 Subject: [issue22360] Adding manually offset parameter to str/bytes split function In-Reply-To: <1410168542.37.0.66219638693.issue22360@psf.upfronthosting.co.za> Message-ID: <1410180224.21.0.749597183232.issue22360@psf.upfronthosting.co.za> Christoph Wruck added the comment: Hi Steven exactly - you're right with this. 'spam--eggs--cheese----toast'.split('-', offset=1) --> ['spam', '-eggs', '-cheese', '-', '-toast'] 'spam--eggs--cheese--toast'.split('-', offset=8) --> ['spam', '-eggs--cheese', '-toast'] Okay - the name "offset" might be an unfortunate choice and you are right that this could be hard to understand for a caller. One more examples: The following removes all escape signs to process the octal escape sequences in a second way if the first three characters are digits. 'spam\\055\\\\055-eggs-\\\\rest'.split('\\', offset=1) --> ['spam', '055', '\\055-eggs-', '\\rest'] # could speed up the split built-in func if a caller knows that every chunk is 3 chars long? 'tic-tac-toe'.split('-', offset=3) A caller could use the offset parameter to keep all separators between the last found and offset if it's a part of a chunk. Or if he awaiting a separator followed by itself which should be keeped - in doubt with the same length of separator. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 14:57:29 2014 From: report at bugs.python.org (Philippe Devalkeneer) Date: Mon, 08 Sep 2014 12:57:29 +0000 Subject: [issue14076] sqlite3 module ignores placeholders in CREATE TRIGGER code In-Reply-To: <1329853172.58.0.728674289337.issue14076@psf.upfronthosting.co.za> Message-ID: <1410181049.02.0.824762153417.issue14076@psf.upfronthosting.co.za> Changes by Philippe Devalkeneer : ---------- nosy: +flupke _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 15:00:23 2014 From: report at bugs.python.org (Miki Tebeka) Date: Mon, 08 Sep 2014 13:00:23 +0000 Subject: [issue22240] argparse support for "python -m module" in help In-Reply-To: <1408564751.42.0.897410433728.issue22240@psf.upfronthosting.co.za> Message-ID: <1410181223.06.0.284914741794.issue22240@psf.upfronthosting.co.za> Miki Tebeka added the comment: Anything else I need to solve to get this patch accepted? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 15:10:43 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 08 Sep 2014 13:10:43 +0000 Subject: [issue22360] Adding manually offset parameter to str/bytes split function In-Reply-To: <1410168542.37.0.66219638693.issue22360@psf.upfronthosting.co.za> Message-ID: <1410181843.14.0.726763393132.issue22360@psf.upfronthosting.co.za> R. David Murray added the comment: If you want to do complex splitting, the supported way to do so is re.split. Feel free to take this to python-ideas if you think there is sufficient reason for baking a particular additional splitting functionality into str.split. ---------- nosy: +r.david.murray resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 15:25:36 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 08 Sep 2014 13:25:36 +0000 Subject: [issue22240] argparse support for "python -m module" in help In-Reply-To: <1408564751.42.0.897410433728.issue22240@psf.upfronthosting.co.za> Message-ID: <1410182736.02.0.12635009106.issue22240@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 15:42:36 2014 From: report at bugs.python.org (Christoph Wruck) Date: Mon, 08 Sep 2014 13:42:36 +0000 Subject: [issue22360] Adding manually offset parameter to str/bytes split function In-Reply-To: <1410168542.37.0.66219638693.issue22360@psf.upfronthosting.co.za> Message-ID: <1410183756.11.0.840084885358.issue22360@psf.upfronthosting.co.za> Christoph Wruck added the comment: Serhiy, you will be right if you've to split a complex string such spliting strings with more than one separator. In this case I would prefer a regex bases solution too. Otherwise we could actually use the re-lib for every of those jobs without using the fast built-in str/bytes split function. Unfortunately lags re.split/findall again str/bytes split function. ---------- resolution: rejected -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 15:47:33 2014 From: report at bugs.python.org (Robert) Date: Mon, 08 Sep 2014 13:47:33 +0000 Subject: [issue21929] Rounding properly In-Reply-To: <1404729306.28.0.45044219182.issue21929@psf.upfronthosting.co.za> Message-ID: <1410184053.09.0.0656930820794.issue21929@psf.upfronthosting.co.za> Robert added the comment: I'm not sure if this is related or not, but on 3.4.1 I get the following: >>> print(round(float(3/2))) 2 (as expected) >>> print(round(float(5/2))) 2 (expected 3, as float should round .5 up) ---------- nosy: +fenofonts _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 16:16:57 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 08 Sep 2014 14:16:57 +0000 Subject: [issue16662] load_tests not invoked in package/__init__.py In-Reply-To: <1355217291.85.0.41912767842.issue16662@psf.upfronthosting.co.za> Message-ID: <1410185817.51.0.928847822539.issue16662@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 16:23:05 2014 From: report at bugs.python.org (Brett Cannon) Date: Mon, 08 Sep 2014 14:23:05 +0000 Subject: [issue22359] Remove incorrect uses of recursive make In-Reply-To: <1410165869.76.0.203082844365.issue22359@psf.upfronthosting.co.za> Message-ID: <1410186185.59.0.895884993212.issue22359@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 16:35:03 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 08 Sep 2014 14:35:03 +0000 Subject: [issue11471] If without else generates redundant jump In-Reply-To: <1299880156.4.0.0999870554397.issue11471@psf.upfronthosting.co.za> Message-ID: <1410186903.38.0.625831280645.issue11471@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 16:36:05 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 08 Sep 2014 14:36:05 +0000 Subject: [issue16662] load_tests not invoked in package/__init__.py In-Reply-To: <1355217291.85.0.41912767842.issue16662@psf.upfronthosting.co.za> Message-ID: <1410186965.8.0.771861653448.issue16662@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- assignee: michael.foord -> barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 16:46:24 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 08 Sep 2014 14:46:24 +0000 Subject: [issue16662] load_tests not invoked in package/__init__.py In-Reply-To: <1355217291.85.0.41912767842.issue16662@psf.upfronthosting.co.za> Message-ID: <1410187584.29.0.481576854708.issue16662@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 16:54:46 2014 From: report at bugs.python.org (Ralph Broenink) Date: Mon, 08 Sep 2014 14:54:46 +0000 Subject: [issue22365] SSLContext.load_verify_locations(cadata) does not accept CRLs Message-ID: <1410188086.75.0.333692035483.issue22365@psf.upfronthosting.co.za> New submission from Ralph Broenink: Issue #18138 added support for the cadata argument in SSLContext.load_verify_locations. However, this argument does not support certificate revocation lists (CRLs) to be added (at least not in PEM format): ssl.SSLError: [PEM: NO_START_LINE] no start line (_ssl.c:2633) The documentation of this method is rather vague on this subject and does not state explicitly this is not allowed: This method can also load certification revocation lists (CRLs) in PEM or or DER format. In order to make use of CRLs, SSLContext.verify_flags must be configured properly. I think CRLs should be allowed to be loaded using the cadata argument. However, the documentation could use some polishing too: "At least one of cafile or capath must be specified." is outdated since the introduction of cadata. ---------- components: Extension Modules messages: 226582 nosy: Ralph.Broenink priority: normal severity: normal status: open title: SSLContext.load_verify_locations(cadata) does not accept CRLs versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 16:55:28 2014 From: report at bugs.python.org (Alex Gaynor) Date: Mon, 08 Sep 2014 14:55:28 +0000 Subject: [issue22365] SSLContext.load_verify_locations(cadata) does not accept CRLs In-Reply-To: <1410188086.75.0.333692035483.issue22365@psf.upfronthosting.co.za> Message-ID: <1410188128.8.0.56635684461.issue22365@psf.upfronthosting.co.za> Changes by Alex Gaynor : ---------- nosy: +alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 17:09:11 2014 From: report at bugs.python.org (Geoffrey Spear) Date: Mon, 08 Sep 2014 15:09:11 +0000 Subject: [issue21929] Rounding properly In-Reply-To: <1404729306.28.0.45044219182.issue21929@psf.upfronthosting.co.za> Message-ID: <1410188951.57.0.836244382495.issue21929@psf.upfronthosting.co.za> Geoffrey Spear added the comment: Robert: That is not related. Python 3's round() function, as documented, rounds halves to the even choice; what you describe is the expected behavior. ---------- nosy: +geoffreyspear _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 17:25:51 2014 From: report at bugs.python.org (=?utf-8?q?Kiss_Gy=C3=B6rgy?=) Date: Mon, 08 Sep 2014 15:25:51 +0000 Subject: [issue22339] Incorrect behavior when subclassing enum.Enum In-Reply-To: <1409878211.89.0.422808973529.issue22339@psf.upfronthosting.co.za> Message-ID: <1410189951.53.0.997700442009.issue22339@psf.upfronthosting.co.za> Kiss Gy?rgy added the comment: Thanks for the tip! That looks much better. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 17:33:11 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 08 Sep 2014 15:33:11 +0000 Subject: [issue16662] load_tests not invoked in package/__init__.py In-Reply-To: <1355217291.85.0.41912767842.issue16662@psf.upfronthosting.co.za> Message-ID: <1410190391.03.0.18868985922.issue16662@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: One thing I really do not like about Rob's last patch is that it exacerbates the documentation discrepancy for loadTestsFromModule(). As previously mentioned, use_load_tests arg was already not documented, and now the patch adds another undocumented pattern default arg. Undocumented "unofficial" APIs are really a fib - we treat them as official APIs for backward compatibility reasons anyway, so I think it behooves us to document them. In the same vein, the load_tests Protocol really should tell the truth about its third argument - i.e. it will not always be None. As Michael suggests in http://bugs.python.org/issue16662#msg200274 I think we should just remove use_load_tests. We'll still need to document the new pattern=None, unless there's a better way to handle that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 17:49:14 2014 From: report at bugs.python.org (Steve Dower) Date: Mon, 08 Sep 2014 15:49:14 +0000 Subject: [issue22299] resolve() on Windows makes some pathological paths unusable In-Reply-To: <1409318228.27.0.489471733533.issue22299@psf.upfronthosting.co.za> Message-ID: <1410191353.98.0.0202237836071.issue22299@psf.upfronthosting.co.za> Steve Dower added the comment: Right, what the prefix actually means is "treat this path as a blob and don't do any processing". Some of the things that 'processing' includes are: * CWD * invalid names ('foo.' -> 'foo') * adjacent backslashes ('a\\b' -> 'a\b') * forward slashes ('a/b' -> 'a\b') * (probably) short/long file names ('progra~1' -> 'Program Files') A nice side-effect is that you can also use path names longer than 260 characters, provided your path name is correctly normalized already. Really, the test for whether to keep or remove the prefix should be to remove the prefix and try and resolve the path again. If it succeeds, remove the prefix; otherwise, keep it. This can only really be done as part of the resolve() call, which would address the original issue, but it may be quite a perf. hit. I'd still be inclined to add the prefix in str() if the final path length is greater than 260 characters, if only because we go from zero chance of it working to a non-zero chance. Unfortunately, there seems to be no way to process a long path to make it 'safe' to add the prefix (though we can do a few of the things and increase the chances) as GetFinalPathName will not work on a long path. FWIW, paths longer than 260 chars are a mess and everyone knows it, but it's really really hard to fix without breaking back-compat. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 18:24:35 2014 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 08 Sep 2014 16:24:35 +0000 Subject: [issue22253] ConfigParser does not handle files without sections In-Reply-To: <1408731768.17.0.221948826268.issue22253@psf.upfronthosting.co.za> Message-ID: <1410193475.26.0.262361500466.issue22253@psf.upfronthosting.co.za> Guido van Rossum added the comment: It looks like this feature request tries to change an existing (ancient) module into something it isn't. At the very least can you point to a spec for the syntax of "POSIX" config files? I always thought they were essentially shell scripts, which suggests that they might have a more complex (and different) quoting syntax than ConfigParser, so there might be cases where the interpretation of a line in a POSIX config file would be different than the interpretation of the same line in a .ini file. ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 18:53:25 2014 From: report at bugs.python.org (Andres Riancho) Date: Mon, 08 Sep 2014 16:53:25 +0000 Subject: [issue826897] Proto 2 pickle vs dict subclass Message-ID: <1410195205.39.0.923354760098.issue826897@psf.upfronthosting.co.za> Andres Riancho added the comment: Well, closing this as wont-fix is far from ideal. +4 years have past from the last activity in this issue but people are still being hit by this issue. In my case I'm not creating any special sub-class, I just use one of Python's built-in libs: ```python import cPickle import Cookie c = Cookie.SimpleCookie() c['abc'] = 'def' unpickled_highest = cPickle.loads(cPickle.dumps(c, cPickle.HIGHEST_PROTOCOL)) unpickled_default = cPickle.loads(cPickle.dumps(c)) print "c['abc'].value ", c['abc'].value print "unpickled_default['abc'].value", unpickled_default['abc'].value print "unpickled_highest['abc'].value", unpickled_highest['abc'].value assert unpickled_default['abc'].value == c['abc'].value assert unpickled_highest['abc'].value == c['abc'].value ``` I know there is a work-around (subclass SimpleCookie, override methods, etc.) but it's still going to be something that others will have to implement on their own, they are going to spend time debugging the issue until they reach this bug report, etc. Batteries included should focus on cutting down development time, and this issue increases dev time by introducing strange/hidden limitations to pickle. Is there any plan to actually fix this in the long term? ---------- nosy: +Andres.Riancho _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 18:57:40 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 08 Sep 2014 16:57:40 +0000 Subject: [issue16662] load_tests not invoked in package/__init__.py In-Reply-To: <1355217291.85.0.41912767842.issue16662@psf.upfronthosting.co.za> Message-ID: <1410195460.38.0.837289641171.issue16662@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: So, I think what I'm going to do is change the sig of the method to: def loadTestsFromModule(self, module, *args, pattern=None, **kws): I.e. the new `pattern` arg will be keyword-only. *args and **kws will be parsed for use_load_tests usage and a deprecation warning will be issued if found, but the argument will be ignored. load_tests() will always be called if it's found. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 18:58:09 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 08 Sep 2014 16:58:09 +0000 Subject: [issue16662] load_tests not invoked in package/__init__.py In-Reply-To: <1355217291.85.0.41912767842.issue16662@psf.upfronthosting.co.za> Message-ID: <1410195489.3.0.720086348215.issue16662@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: pattern will have to be documented and accepted as official API ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 18:58:42 2014 From: report at bugs.python.org (Andres Riancho) Date: Mon, 08 Sep 2014 16:58:42 +0000 Subject: [issue826897] Proto 2 pickle vs dict subclass Message-ID: <1410195522.54.0.684000628399.issue826897@psf.upfronthosting.co.za> Andres Riancho added the comment: Django's issue [0] shows the ugly code people write to work around this python bug. [0] https://code.djangoproject.com/ticket/15863 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 19:01:52 2014 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 08 Sep 2014 17:01:52 +0000 Subject: [issue22353] re.findall() documentation lacks information about finding THE LAST iteration of repeated capturing group (greedy) In-Reply-To: <1410093332.63.0.87948506622.issue22353@psf.upfronthosting.co.za> Message-ID: <1410195712.47.0.599537056041.issue22353@psf.upfronthosting.co.za> Guido van Rossum added the comment: Then let's close this issue. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 19:03:16 2014 From: report at bugs.python.org (Andres Riancho) Date: Mon, 08 Sep 2014 17:03:16 +0000 Subject: [issue826897] Proto 2 pickle vs dict subclass Message-ID: <1410195796.63.0.648656338805.issue826897@psf.upfronthosting.co.za> Changes by Andres Riancho : ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 19:03:43 2014 From: report at bugs.python.org (Andres Riancho) Date: Mon, 08 Sep 2014 17:03:43 +0000 Subject: [issue826897] Proto 2 pickle vs dict subclass Message-ID: <1410195823.04.0.662729358852.issue826897@psf.upfronthosting.co.za> Changes by Andres Riancho : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 19:35:32 2014 From: report at bugs.python.org (Paul Moore) Date: Mon, 08 Sep 2014 17:35:32 +0000 Subject: [issue22253] ConfigParser does not handle files without sections In-Reply-To: <1408731768.17.0.221948826268.issue22253@psf.upfronthosting.co.za> Message-ID: <1410197732.95.0.329963365957.issue22253@psf.upfronthosting.co.za> Paul Moore added the comment: It's not unreasonable as a new feature, but the default behaviour shouldn't change. It matches ini files (like it or not, ConfigParser parses ini-style files - the docs even say so), and sectionless values are not standard ini format. I'd suggest a new __init__ option, allow_unnamed_section (default False) that permits variables to be placed before the first section header. I'd further suggest that the names be treated as if they were in a section with name '', for consistency of access with other sections. It's plausible that people might want the defaults section to be the unnamed section. If so, that could be another option, default_is_unnamed (default False, if True this implies allow_unnamed_section). But I'm not sure the additional complexity is worth it. ---------- nosy: +pmoore _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 19:45:52 2014 From: report at bugs.python.org (Alex Gaynor) Date: Mon, 08 Sep 2014 17:45:52 +0000 Subject: [issue22366] urllib.request.urlopen shoudl take a "context" (SSLContext) argument Message-ID: <1410198352.63.0.605714024836.issue22366@psf.upfronthosting.co.za> New submission from Alex Gaynor: Instead of the ca* arguments it currently takes, these can all be encapsulated into an SSLContext argument, which the underlying http.client already supports. ---------- components: Library (Lib) messages: 226594 nosy: alex, christian.heimes, dstufft, giampaolo.rodola, janssen, orsenthil, pitrou priority: normal severity: normal status: open title: urllib.request.urlopen shoudl take a "context" (SSLContext) argument versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 20:21:44 2014 From: report at bugs.python.org (Alex Gaynor) Date: Mon, 08 Sep 2014 18:21:44 +0000 Subject: [issue22366] urllib.request.urlopen shoudl take a "context" (SSLContext) argument In-Reply-To: <1410198352.63.0.605714024836.issue22366@psf.upfronthosting.co.za> Message-ID: <1410200504.59.0.499190422651.issue22366@psf.upfronthosting.co.za> Alex Gaynor added the comment: Attached patch against the default branch adds support for this. ---------- keywords: +needs review, patch Added file: http://bugs.python.org/file36573/urlopen-context.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 20:24:26 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 08 Sep 2014 18:24:26 +0000 Subject: [issue16662] load_tests not invoked in package/__init__.py In-Reply-To: <1355217291.85.0.41912767842.issue16662@psf.upfronthosting.co.za> Message-ID: <3hsHvZ17MKz7Ljb@mail.python.org> Roundup Robot added the comment: New changeset d0ff527c53da by Barry Warsaw in branch 'default': - Issue #16662: load_tests() is now unconditionally run when it is present in http://hg.python.org/cpython/rev/d0ff527c53da ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 20:41:12 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 08 Sep 2014 18:41:12 +0000 Subject: [issue16662] load_tests not invoked in package/__init__.py In-Reply-To: <1355217291.85.0.41912767842.issue16662@psf.upfronthosting.co.za> Message-ID: <1410201672.87.0.377649722689.issue16662@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 20:58:53 2014 From: report at bugs.python.org (Jeffrey Armstrong) Date: Mon, 08 Sep 2014 18:58:53 +0000 Subject: [issue21931] Nonsense errors reported by msilib.FCICreate for bad argument In-Reply-To: <1404737590.72.0.85327158616.issue21931@psf.upfronthosting.co.za> Message-ID: <1410202733.7.0.827406156095.issue21931@psf.upfronthosting.co.za> Jeffrey Armstrong added the comment: Is this patch going to be accepted? It fixes actual incorrect code in msilib, and it seems to have stagnated ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 21:00:44 2014 From: report at bugs.python.org (Jeffrey Armstrong) Date: Mon, 08 Sep 2014 19:00:44 +0000 Subject: [issue20597] PATH_MAX already defined on some Windows compilers In-Reply-To: <1392124275.46.0.750764006124.issue20597@psf.upfronthosting.co.za> Message-ID: <1410202844.45.0.307134346578.issue20597@psf.upfronthosting.co.za> Jeffrey Armstrong added the comment: Was this ever accepted? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 21:30:18 2014 From: report at bugs.python.org (Steven D'Aprano) Date: Mon, 08 Sep 2014 19:30:18 +0000 Subject: [issue22364] Unify error messages of re and regex In-Reply-To: <1410178976.27.0.421938794422.issue22364@psf.upfronthosting.co.za> Message-ID: <1410204618.19.0.455450584127.issue22364@psf.upfronthosting.co.za> Steven D'Aprano added the comment: I'm dubious about this issue. It suggests that the wording of the exceptions is part of the API of the two modules. If the idea is just to copy the best error messages from one module to the other, then I guess there is no harm. But if the idea is to guarantee to keep the two modules' messages in sync, then I think it is unnecessary and harmful. ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 21:32:23 2014 From: report at bugs.python.org (Robert Collins) Date: Mon, 08 Sep 2014 19:32:23 +0000 Subject: [issue16662] load_tests not invoked in package/__init__.py In-Reply-To: <1355217291.85.0.41912767842.issue16662@psf.upfronthosting.co.za> Message-ID: <1410204743.11.0.646927316891.issue16662@psf.upfronthosting.co.za> Robert Collins added the comment: Thanks for landing this barry, there's a couple quirks with your improvements - loadTestsFromModule(mod, foo, bar) will raise a TypeError but not warn about foo the way loadTestsFromModule(mod, foo) will. Secondly, the TypeError has an off-by-one error in its output: loadTestsFromModule(mod, foo, bar) will claim 2 arguments were passed. Three were. diff -r d0ff527c53da Lib/unittest/loader.py --- a/Lib/unittest/loader.py Mon Sep 08 14:21:37 2014 -0400 +++ b/Lib/unittest/loader.py Tue Sep 09 07:32:05 2014 +1200 @@ -79,12 +79,12 @@ # use_load_tests argument. For backward compatibility, we still # accept the argument (which can also be the first position) but we # ignore it and issue a deprecation warning if it's present. - if len(args) == 1 or 'use_load_tests' in kws: + if len(args) or 'use_load_tests' in kws: warnings.warn('use_load_tests is deprecated and ignored', DeprecationWarning) kws.pop('use_load_tests', None) if len(args) > 1: - raise TypeError('loadTestsFromModule() takes 1 positional argument but {} were given'.format(len(args))) + raise TypeError('loadTestsFromModule() takes 1 positional argument but {} were given'.format(len(args) + 1)) if len(kws) != 0: # Since the keyword arguments are unsorted (see PEP 468), just # pick the alphabetically sorted first argument to complain about, diff -r d0ff527c53da Lib/unittest/test/test_loader.py --- a/Lib/unittest/test/test_loader.py Mon Sep 08 14:21:37 2014 -0400 +++ b/Lib/unittest/test/test_loader.py Tue Sep 09 07:32:05 2014 +1200 @@ -272,7 +272,7 @@ # however use_load_tests (which sorts first) is ignored. self.assertEqual( str(cm.exception), - 'loadTestsFromModule() takes 1 positional argument but 2 were given') + 'loadTestsFromModule() takes 1 positional argument but 3 were given') @warningregistry def test_loadTestsFromModule__use_load_tests_other_bad_keyword(self): ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 21:36:10 2014 From: report at bugs.python.org (Robert Collins) Date: Mon, 08 Sep 2014 19:36:10 +0000 Subject: [issue16662] load_tests not invoked in package/__init__.py In-Reply-To: <1355217291.85.0.41912767842.issue16662@psf.upfronthosting.co.za> Message-ID: <1410204970.79.0.00980776031654.issue16662@psf.upfronthosting.co.za> Robert Collins added the comment: OH! One more thing I just spotted, which is that this change causes non-'discover' unittest test loading to invoke load_tests. IMO this is the Right Thing - its what I intended when I described the protocol a few years back, but we should document it, no? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 21:36:17 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 08 Sep 2014 19:36:17 +0000 Subject: [issue826897] Proto 2 pickle vs dict subclass Message-ID: <1410204977.86.0.445220580014.issue826897@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Alexandre or Antoine, do either of you want to either reopen or verify that this dict subclass pickle issue was properly closed as won't fix? ---------- nosy: +alexandre.vassalotti, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 21:39:44 2014 From: report at bugs.python.org (Robert Collins) Date: Mon, 08 Sep 2014 19:39:44 +0000 Subject: [issue17401] io.FileIO closefd parameter is not documented nor shown in repr In-Reply-To: <1363057927.36.0.00381165430664.issue17401@psf.upfronthosting.co.za> Message-ID: <1410205184.02.0.162284443563.issue17401@psf.upfronthosting.co.za> Robert Collins added the comment: Its more than just a docs issue - "AFAICT it isn't possible to tell if closefd is set after the object is created." The presence of the parameter in the signature is there, but it isn't documented *where the bulk of the FileIO parameters are* - there are docs for mode for instance. Why would we force users to follow breadcrumbs for one parameter but not other ones? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 21:43:05 2014 From: report at bugs.python.org (Michael Foord) Date: Mon, 08 Sep 2014 19:43:05 +0000 Subject: [issue16662] load_tests not invoked in package/__init__.py In-Reply-To: <1355217291.85.0.41912767842.issue16662@psf.upfronthosting.co.za> Message-ID: <1410205385.43.0.969665935428.issue16662@psf.upfronthosting.co.za> Michael Foord added the comment: I agree, load_tests should be honoured even when not invoked through discovery. If that wasn't the case it was an unfortunate oversight on my part! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 21:44:13 2014 From: report at bugs.python.org (Andres Riancho) Date: Mon, 08 Sep 2014 19:44:13 +0000 Subject: [issue826897] Proto 2 pickle vs dict subclass Message-ID: <1410205453.88.0.539527632621.issue826897@psf.upfronthosting.co.za> Andres Riancho added the comment: FYI, I'm using Python 2.7.6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 21:54:31 2014 From: report at bugs.python.org (paul j3) Date: Mon, 08 Sep 2014 19:54:31 +0000 Subject: [issue22240] argparse support for "python -m module" in help In-Reply-To: <1408564751.42.0.897410433728.issue22240@psf.upfronthosting.co.za> Message-ID: <1410206071.42.0.970662492391.issue22240@psf.upfronthosting.co.za> paul j3 added the comment: When I apply `prog3.diff` to my 3.5.0dev, and run python3 -m unittest Lib/test/test_argparse.py I get 2 failures, both over 'usage: python3 -m [unit]test'. It also fails with python3 test_argparse.py I suspect it would also fail if I ran the tests with `nosetests` (though I'm not setup to use that in the development version). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 21:56:44 2014 From: report at bugs.python.org (Robert Collins) Date: Mon, 08 Sep 2014 19:56:44 +0000 Subject: [issue17401] io.FileIO closefd parameter is not documented nor shown in repr In-Reply-To: <1363057927.36.0.00381165430664.issue17401@psf.upfronthosting.co.za> Message-ID: <1410206204.36.0.108166812266.issue17401@psf.upfronthosting.co.za> Robert Collins added the comment: Oh - the the 'open' function docs are fine - they are just a pointer. I was specifically referring to the class docs around line 513 of Doc/library/io.rst. Attached is a patch that changes repr to show this attribute and extends the docs to document this as part of FileIO. ---------- keywords: +patch Added file: http://bugs.python.org/file36574/issue17401.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 21:58:14 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 08 Sep 2014 19:58:14 +0000 Subject: [issue17381] IGNORECASE breaks unicode literal range matching In-Reply-To: <1362689552.47.0.00880933015098.issue17381@psf.upfronthosting.co.za> Message-ID: <1410206294.26.0.243168505005.issue17381@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: No, issue12728 is more complicate case. Here is a patch which fixes this issue and issue3511. ---------- assignee: -> serhiy.storchaka keywords: +patch stage: -> patch review versions: +Python 3.4, Python 3.5 -Python 3.3 Added file: http://bugs.python.org/file36575/re_ignore_case_range.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 22:12:22 2014 From: report at bugs.python.org (Alex Gaynor) Date: Mon, 08 Sep 2014 20:12:22 +0000 Subject: [issue22366] urllib.request.urlopen shoudl take a "context" (SSLContext) argument In-Reply-To: <1410198352.63.0.605714024836.issue22366@psf.upfronthosting.co.za> Message-ID: <1410207142.86.0.199217312006.issue22366@psf.upfronthosting.co.za> Alex Gaynor added the comment: Added a versionchanged directive to the docs. ---------- Added file: http://bugs.python.org/file36576/urlopen-context.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 22:18:49 2014 From: report at bugs.python.org (Andrew Lutomirski) Date: Mon, 08 Sep 2014 20:18:49 +0000 Subject: [issue22367] Please add F_OFD_SETLK, etc support to fcntl.lockf Message-ID: <1410207529.54.0.778133775349.issue22367@psf.upfronthosting.co.za> New submission from Andrew Lutomirski: Linux 3.15 and newer support a vastly superior API for file locking, in which locks are owned by open file descriptions instead of by processes. This is how everyone seems to expect POSIX locks to work, but now they can finally work that way. Please add some interface to these locks to fcntl.lockf. One option would be to use them by default and to fall back to standard POSIX locks if they're not available. I don't know whether this would break existing code. See http://man7.org/linux/man-pages/man2/fcntl.2.html for details. ---------- components: Library (Lib) messages: 226610 nosy: Andrew.Lutomirski priority: normal severity: normal status: open title: Please add F_OFD_SETLK, etc support to fcntl.lockf type: enhancement versions: Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 22:55:34 2014 From: report at bugs.python.org (Robert Collins) Date: Mon, 08 Sep 2014 20:55:34 +0000 Subject: [issue16662] load_tests not invoked in package/__init__.py In-Reply-To: <1355217291.85.0.41912767842.issue16662@psf.upfronthosting.co.za> Message-ID: <1410209734.14.0.371853080595.issue16662@psf.upfronthosting.co.za> Robert Collins added the comment: @michael - ah I think I inverted the sense of the old parameter. It was defaulting True. So - no need to document anything extra:) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 23:27:16 2014 From: report at bugs.python.org (Robert Collins) Date: Mon, 08 Sep 2014 21:27:16 +0000 Subject: [issue19746] No introspective way to detect ModuleImportFailure in unittest In-Reply-To: <1385262963.63.0.210713286499.issue19746@psf.upfronthosting.co.za> Message-ID: <1410211636.99.0.554246027125.issue19746@psf.upfronthosting.co.za> Robert Collins added the comment: Here is an implementation. I'm probably missing some finesse in the docs. ---------- keywords: +patch Added file: http://bugs.python.org/file36577/issue19746.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 23:29:10 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 08 Sep 2014 21:29:10 +0000 Subject: [issue16662] load_tests not invoked in package/__init__.py In-Reply-To: <1355217291.85.0.41912767842.issue16662@psf.upfronthosting.co.za> Message-ID: <3hsN0j2pfHz7LkJ@mail.python.org> Roundup Robot added the comment: New changeset 92b292d68104 by Barry Warsaw in branch 'default': A few tweaks for issue16662 based on feedback from Robert Collins. http://hg.python.org/cpython/rev/92b292d68104 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 23:42:23 2014 From: report at bugs.python.org (Robert Collins) Date: Mon, 08 Sep 2014 21:42:23 +0000 Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za> Message-ID: <1410212543.51.0.921032536885.issue7559@psf.upfronthosting.co.za> Robert Collins added the comment: I've just put a patch up for the related issue http://bugs.python.org/issue19746 I'll poke at this one briefly now, since I'm across the related code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 8 23:54:38 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Mon, 08 Sep 2014 21:54:38 +0000 Subject: [issue22361] Ability to join() threads in concurrent.futures.ThreadPoolExecutor In-Reply-To: <1410172185.62.0.239101325071.issue22361@psf.upfronthosting.co.za> Message-ID: <1410213278.73.0.148916761807.issue22361@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Can you explain what benefit this would provide? Forcing the thread to exit gets you relatively little benefit. If it's an infrequently used executor, I suppose you avoid the cost of leaving worker threads blocked waiting for work, but that cost is tiny, and you pay for it with increased overhead to dispatch new tasks since they have to create new threads instead of using existing worker threads. ---------- nosy: +josh.rosenberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 01:22:17 2014 From: report at bugs.python.org (Robert Collins) Date: Mon, 08 Sep 2014 23:22:17 +0000 Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za> Message-ID: <1410218537.91.0.451521829326.issue7559@psf.upfronthosting.co.za> Robert Collins added the comment: Ok, here is an implementation that I believe covers everything Michael wanted. I examined the other patches, and can rearrange my implementation to be more like them if desired - but at the heart of this this bug really has two requested changes: - deferred reporting of error per Michaels request - report missing attributes on packages as an ImportError (if one occurred) and thus my implementation focuses on those changes. ---------- Added file: http://bugs.python.org/file36578/issue7559.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 01:27:07 2014 From: report at bugs.python.org (Robert Collins) Date: Mon, 08 Sep 2014 23:27:07 +0000 Subject: [issue18232] running a suite with no tests is not an error In-Reply-To: <1371411159.89.0.919313216558.issue18232@psf.upfronthosting.co.za> Message-ID: <1410218827.47.0.421857733743.issue18232@psf.upfronthosting.co.za> Robert Collins added the comment: @Terry in principle you're right, there are an arbitrary number of things that can go wrong, but in practice what we see is either catastrophic failure where nothing is loaded at all *and* no error is returned or localised failure where the deferred reporting of failed imports serves quite well enough. The former is caused by things like the wrong path in a configuration file. @ezio sure - a boolean option would meet the needs reported to me, I was suggesting a specific implementation in an attempt to be generic enough to not need to maintain two things if more was added in future. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 04:30:19 2014 From: report at bugs.python.org (Ned Deily) Date: Tue, 09 Sep 2014 02:30:19 +0000 Subject: [issue22361] Ability to join() threads in concurrent.futures.ThreadPoolExecutor In-Reply-To: <1410172185.62.0.239101325071.issue22361@psf.upfronthosting.co.za> Message-ID: <1410229819.43.0.492750102481.issue22361@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +bquinlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 05:22:11 2014 From: report at bugs.python.org (Zacrath) Date: Tue, 09 Sep 2014 03:22:11 +0000 Subject: [issue22363] argparse AssertionError with add_mutually_exclusive_group and help=SUPPRESS In-Reply-To: <1410176787.11.0.945188170372.issue22363@psf.upfronthosting.co.za> Message-ID: <1410232931.16.0.457782886141.issue22363@psf.upfronthosting.co.za> Zacrath added the comment: This assert statement is only reached when the usage line is long enough that it needs to be wrapped. Which is why the assertion does not happen when an argument is removed. opt_usage is being compared to this string: "[-h] [--arg2 ARG2] [--arg3 ARG3] [--arg4 ARG4] [--arg5 ARG5] [--arg6 ARG6]" opt_usage in this case has the value: "[-h] [--arg2 ARG2] [--arg3 ARG3] [--arg4 ARG4] [--arg5 ARG5] [--arg6 ARG6]" There is an extra space after "[-h]". The value of opt_usage comes from _format_actions_usage. And that is where the bug is. Just before _format_actions_usage returns, the usage string is: "[-h] [ ] [--arg2 ARG2] [--arg3 ARG3] [--arg4 ARG4] [--arg5 ARG5] [--arg6 ARG6]" The method uses this regexp: "[ *]" To remove the extra brackets. But that leaves the extra space after the brackets. The attached patch changes the regexp to: "[ *] ?" So that the extra space is also removed. The patch also adds a testcase based on the script that reproduces the ---------- keywords: +patch Added file: http://bugs.python.org/file36579/bugfix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 05:48:36 2014 From: report at bugs.python.org (Alex Gaynor) Date: Tue, 09 Sep 2014 03:48:36 +0000 Subject: [issue22366] urllib.request.urlopen shoudl take a "context" (SSLContext) argument In-Reply-To: <1410198352.63.0.605714024836.issue22366@psf.upfronthosting.co.za> Message-ID: <1410234516.1.0.301923005195.issue22366@psf.upfronthosting.co.za> Alex Gaynor added the comment: New patch switches to a ValueError and includes a test case that it's raised. ---------- Added file: http://bugs.python.org/file36580/urlopen-context.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 05:58:15 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 09 Sep 2014 03:58:15 +0000 Subject: [issue18232] running a suite with no tests is not an error In-Reply-To: <1371411159.89.0.919313216558.issue18232@psf.upfronthosting.co.za> Message-ID: <1410235095.87.0.0132933806111.issue18232@psf.upfronthosting.co.za> Terry J. Reedy added the comment: You missed my point, which is that tools consuming subunit streams are already able to consider 'no tests found' to be an error. Conversely, when I run the suite on my Windows box, I usually consider only 1 or 2 errors to be success. After unittest reports actual results, the summary pass/fail judgment is only advisory. To be really flexible and meet all needs for automated adjustment of pass/fail, the new parameter should be function that gets the numbers and at least the set of tests that 'failed'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 06:29:42 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 09 Sep 2014 04:29:42 +0000 Subject: [issue22253] ConfigParser does not handle files without sections In-Reply-To: <1408731768.17.0.221948826268.issue22253@psf.upfronthosting.co.za> Message-ID: <1410236982.38.0.669278662648.issue22253@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The MS function GetPrivateProfileString appears to require sections. http://msdn.microsoft.com/en-us/library/ms724353.aspx On the other hand, it does not appear to do interpolation, so we have already not restricted ourselves to the MS function. In looking through the .ini files in my game directory, which includes some old games, I found a couple with no section header. So such files do exist in the wild. I am dubious that there are any with a mixture of both sections and additional option lines at the top without a section. Anyone writing an app and planning to parse a .ini file can add [Start] or [Setup] at the top. So there is only an issue for 3rd party software parsing a file without. I think a more useful new configparser feature would be to keep comment lines and write them back out after a configuration is changed. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 07:43:58 2014 From: report at bugs.python.org (paul j3) Date: Tue, 09 Sep 2014 05:43:58 +0000 Subject: [issue22240] argparse support for "python -m module" in help In-Reply-To: <1408564751.42.0.897410433728.issue22240@psf.upfronthosting.co.za> Message-ID: <1410241438.15.0.363369936387.issue22240@psf.upfronthosting.co.za> paul j3 added the comment: In argparse.py, I would put a utility function like `_prog_name` near the start in the 'Utility functions and classes' block. In test_argparse.py, I don't see the purpose of the `progname` changes in the TestParentParsers class. That class wasn't producing an error, even though 'unittest' has a '__main__'. Is there some other way of running the test that produces an error with the existing code? Most tests for 'usage' and 'help', use 'prog="PROG"' to get around the various ways that the tests can be run. I don't see what TestParentParsers gains by not doing the same. The 'prog' attribute has nothing to do with 'parents', at least not that I can tell. I think a patch like this needs a new test(s), one that fails with existing code, and run fine with the patch. It also needs to work with almost any method of running the tests. But writing such a test might be lot harder than writing the fix, since it involves system issues, and possibly mocking a package and a zip file. Nick's suggestion regarding '__spec__' also needs to be considered. It is an area of active development. I'm not sure that 'argparse' should be getting into these details regarding how the script is invoked and/or packaged. Finally, does this patch accomplish anything that the user can't do by directly setting the 'prog' attribute? The user could even use a function like '_prog_name' to create that name on the fly. 'unittest.__main__' is an example of a package that gets around this '__main__' problem by redefining 'sys.argv[0]' before invoking the parser (optparse). 'Nose' also does this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 07:44:28 2014 From: report at bugs.python.org (Christoph Wruck) Date: Tue, 09 Sep 2014 05:44:28 +0000 Subject: [issue22360] Adding manually offset parameter to str/bytes split function In-Reply-To: <1410168542.37.0.66219638693.issue22360@psf.upfronthosting.co.za> Message-ID: <1410241468.77.0.95833469804.issue22360@psf.upfronthosting.co.za> Christoph Wruck added the comment: David, I'll reflect on it. @ALL - Thank's for all answers. Should I close this ticket? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 08:10:56 2014 From: report at bugs.python.org (paul j3) Date: Tue, 09 Sep 2014 06:10:56 +0000 Subject: [issue22363] argparse AssertionError with add_mutually_exclusive_group and help=SUPPRESS In-Reply-To: <1410176787.11.0.945188170372.issue22363@psf.upfronthosting.co.za> Message-ID: <1410243056.05.0.854300071538.issue22363@psf.upfronthosting.co.za> paul j3 added the comment: This assertion has triggered several bug issues, either due to an empty group like this, or certain characters in the metavars. http://bugs.python.org/issue17890 'argparse: mutually exclusive groups full of suppressed args can cause AssertionErrors' http://bugs.python.org/issue11874 'argparse assertion failure with brackets in metavars' http://bugs.python.org/issue16360 'argparse: comma in metavar causes assertion failure when formatting long usage message' I think this is a duplicate of 17890, though I'll have to look more closely at your patch to see what it adds. For 11874 I proposed a major rewrite of the usage formatting. There I format each group and/or action separately, and keep the pieces in a list. That way it's easier to filter out empty pieces, and avoids the complex split that gives headaches when the usage is long enough to wrap. ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 08:38:11 2014 From: report at bugs.python.org (Chris Rose) Date: Tue, 09 Sep 2014 06:38:11 +0000 Subject: [issue20752] Difflib should provide the option of overriding the SequenceMatcher In-Reply-To: <1393193816.17.0.662615840954.issue20752@psf.upfronthosting.co.za> Message-ID: <1410244691.48.0.76335026399.issue20752@psf.upfronthosting.co.za> Chris Rose added the comment: What's the word on this change? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 08:46:25 2014 From: report at bugs.python.org (Ralph Broenink) Date: Tue, 09 Sep 2014 06:46:25 +0000 Subject: [issue22365] SSLContext.load_verify_locations(cadata) does not accept CRLs In-Reply-To: <1410188086.75.0.333692035483.issue22365@psf.upfronthosting.co.za> Message-ID: <1410245185.74.0.401434989521.issue22365@psf.upfronthosting.co.za> Ralph Broenink added the comment: Here's a minimal example of the issue, assuming you have obtained a CRL in PEM format, e.g. from https://www.emulab.net/genicrl.bundle: import ssl context = ssl.create_default_context() path = 'path/to/crl.crl' # Working: context.load_verify_locations(cafile=path) # Not working: with open(path, 'r') as f: context.load_verify_locations(cadata=f.read()) Replacing the path to the CRL with a path to a CA works in both cases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 09:40:53 2014 From: report at bugs.python.org (Zacrath) Date: Tue, 09 Sep 2014 07:40:53 +0000 Subject: [issue11874] argparse assertion failure with brackets in metavars In-Reply-To: <1303201252.58.0.236363581255.issue11874@psf.upfronthosting.co.za> Message-ID: <1410248453.31.0.659223411768.issue11874@psf.upfronthosting.co.za> Changes by Zacrath : ---------- nosy: +Zacrath _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 09:48:29 2014 From: report at bugs.python.org (Zacrath) Date: Tue, 09 Sep 2014 07:48:29 +0000 Subject: [issue22363] argparse AssertionError with add_mutually_exclusive_group and help=SUPPRESS In-Reply-To: <1410176787.11.0.945188170372.issue22363@psf.upfronthosting.co.za> Message-ID: <1410248909.89.0.60548997065.issue22363@psf.upfronthosting.co.za> Zacrath added the comment: I've confirmed that this is a duplicate of issue 17890. In case anyone needs it, a workaround is to move the mutually exclusive group to the end of the arguments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 10:33:39 2014 From: report at bugs.python.org (Frank Thommen) Date: Tue, 09 Sep 2014 08:33:39 +0000 Subject: [issue22326] tempfile.TemporaryFile fails on NFS v4 filesystems In-Reply-To: <1409659206.56.0.836891924559.issue22326@psf.upfronthosting.co.za> Message-ID: <1410251619.4.0.224311113303.issue22326@psf.upfronthosting.co.za> Frank Thommen added the comment: It might be an issue of strict ACL mapping (http://wiki.linux-nfs.org/wiki/index.php/ACLs) is implemented. On our ZFS based NFS v4 server this is the case, on CentOS based NFS v4 servers this doesn't seem to be implemented/enforced. It becomes then still a Python problem, as tempfile.TemporaryFile is not generally usable any more. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 10:35:47 2014 From: report at bugs.python.org (Luca Falavigna) Date: Tue, 09 Sep 2014 08:35:47 +0000 Subject: [issue22361] Ability to join() threads in concurrent.futures.ThreadPoolExecutor In-Reply-To: <1410172185.62.0.239101325071.issue22361@psf.upfronthosting.co.za> Message-ID: <1410251747.33.0.128445890489.issue22361@psf.upfronthosting.co.za> Luca Falavigna added the comment: There is indeed little benefit in freeing up resources left open by a unused thread, but it could be worth closing it for specific needs (e.g. thread processes sensible information) or in embedded systems with very low resources. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 10:41:35 2014 From: report at bugs.python.org (Matej Cepl) Date: Tue, 09 Sep 2014 08:41:35 +0000 Subject: [issue19494] urllib2.HTTPBasicAuthHandler (or urllib.request.HTTPBasicAuthHandler) doesn't work with GitHub API v3 and similar In-Reply-To: <1383577219.47.0.139805262488.issue19494@psf.upfronthosting.co.za> Message-ID: <1410252095.7.0.126411834816.issue19494@psf.upfronthosting.co.za> Matej Cepl added the comment: > The patch for Python 3.5, however, looks great. So, could we get some resolution here, please? Before this bug celebrates a first birthday, could somebody decide what to do? Whom should I pester? Who has the responsibility to make a decision? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 10:55:16 2014 From: report at bugs.python.org (Philippe Devalkeneer) Date: Tue, 09 Sep 2014 08:55:16 +0000 Subject: [issue1525806] Tkdnd mouse cursor handling patch Message-ID: <1410252916.79.0.368259285465.issue1525806@psf.upfronthosting.co.za> Changes by Philippe Devalkeneer : ---------- nosy: +flupke _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 11:03:49 2014 From: report at bugs.python.org (Michael Foord) Date: Tue, 09 Sep 2014 09:03:49 +0000 Subject: [issue18232] running a suite with no tests is not an error In-Reply-To: <1371411159.89.0.919313216558.issue18232@psf.upfronthosting.co.za> Message-ID: <1410253429.59.0.263153687318.issue18232@psf.upfronthosting.co.za> Michael Foord added the comment: I'd agree that a test run that actually runs zero tests almost always indicates an error, and it would be better if this was made clear. I have this problem a great deal with Go, where the test tools are awful, and it's very easy to think you have a successful test run (PASS) when you actually ran zero tests. Particularly with discovery you will want to know your invocation is wrong. I'm agnostic on a new "--min-tests" parameter, but having zero tests found should return a non-zero exit code and display a warning. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 13:42:20 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 09 Sep 2014 11:42:20 +0000 Subject: [issue22359] Remove incorrect uses of recursive make In-Reply-To: <1410165869.76.0.203082844365.issue22359@psf.upfronthosting.co.za> Message-ID: <1410262940.78.0.328553497374.issue22359@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 14:26:48 2014 From: report at bugs.python.org (Michael R. Bernstein) Date: Tue, 09 Sep 2014 12:26:48 +0000 Subject: [issue7744] Allow site.addsitedir insert to beginning of sys.path In-Reply-To: <1264018763.75.0.862537731081.issue7744@psf.upfronthosting.co.za> Message-ID: <1410265608.45.0.436703242866.issue7744@psf.upfronthosting.co.za> Michael R. Bernstein added the comment: The lack of a left-append option for site.addsitedir(path), or an site.insertsitedir(index, path) (which is what I would consider a better solution), causes quite a few contortions on some hosted platforms, notably Google App Engine, for vendored packages. I've been trying to find a more elegant solution than the following code, but haven't been able to find anything: import os import site import sys dirname = 'lib' dirpath = os.path.join(os.path.dirname(__file__), dirname) sys.path, remainder = sys.path[:1], sys.path[1:] site.addsitedir(dirpath) sys.path.extend(remainder) And even asked on StackOverflow: http://stackoverflow.com/questions/25709832/what-is-the-cleanest-way-to-add-a-directory-of-third-party-packages-to-the-begin Having a site.insertsitedir(index, path) available would make things so much simpler. ---------- nosy: +webmaven versions: +Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 15:32:22 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 09 Sep 2014 13:32:22 +0000 Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za> Message-ID: <1410269542.6.0.678850898452.issue7559@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks for tackling this. It's been bugging me almost daily this past week, but as usual when this bug is in my face I had no time to actually work on a fix. I applied this patch to default, put an invalid import in test_os, and this is the result: rdmurray at pydev:~/python/p35>./python -m unittest test.test_os Traceback (most recent call last): File "/home/rdmurray/python/p35/Lib/unittest/loader.py", line 140, in loadTestsFromName module = __import__(module_name) File "/home/rdmurray/python/p35/Lib/test/test_os.py", line 5, in import foobar ImportError: No module named 'foobar' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/rdmurray/python/p35/Lib/runpy.py", line 170, in _run_module_as_main "__main__", mod_spec) File "/home/rdmurray/python/p35/Lib/runpy.py", line 85, in _run_code exec(code, run_globals) File "/home/rdmurray/python/p35/Lib/unittest/__main__.py", line 18, in main(module=None) File "/home/rdmurray/python/p35/Lib/unittest/main.py", line 92, in __init__ self.parseArgs(argv) File "/home/rdmurray/python/p35/Lib/unittest/main.py", line 139, in parseArgs self.createTests() File "/home/rdmurray/python/p35/Lib/unittest/main.py", line 146, in createTests self.module) File "/home/rdmurray/python/p35/Lib/unittest/loader.py", line 202, in loadTestsFromNames suites = [self.loadTestsFromName(name, module) for name in names] File "/home/rdmurray/python/p35/Lib/unittest/loader.py", line 202, in suites = [self.loadTestsFromName(name, module) for name in names] File "/home/rdmurray/python/p35/Lib/unittest/loader.py", line 145, in loadTestsFromName next_attribute, self.suiteClass) ValueError: need more than 1 value to unpack I get similar errors if I misspell the module name in on the command line. >From my point of view this is still an improvement over the status quo, but I don't think it is what you had in mind :). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 15:51:15 2014 From: report at bugs.python.org (Kushal Das) Date: Tue, 09 Sep 2014 13:51:15 +0000 Subject: [issue21270] unittest.mock.call object has inherited count method In-Reply-To: <1397681359.44.0.204245756188.issue21270@psf.upfronthosting.co.za> Message-ID: <1410270675.55.0.990533706533.issue21270@psf.upfronthosting.co.za> Kushal Das added the comment: Forgot to attach the patch. Includes NEWS entry. Overriden methods count() and index(). ---------- keywords: +patch Added file: http://bugs.python.org/file36581/issue21270.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 16:15:41 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 09 Sep 2014 14:15:41 +0000 Subject: [issue22364] Unify error messages of re and regex In-Reply-To: <1410178976.27.0.421938794422.issue22364@psf.upfronthosting.co.za> Message-ID: <1410272141.64.0.352764367615.issue22364@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, the idea of this issue is to enhance the re module (and the regex module if Matthew will) be picking the best error messages (or writing a new one). ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 16:45:35 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 09 Sep 2014 14:45:35 +0000 Subject: [issue22338] test_json crash on memory allocation failure In-Reply-To: <1409873237.86.0.801776520079.issue22338@psf.upfronthosting.co.za> Message-ID: <1410273935.14.0.712349065822.issue22338@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Besides my nitpick on Rietveld the patch LGTM. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 16:51:07 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 09 Sep 2014 14:51:07 +0000 Subject: [issue21951] tcl test change crashes AIX In-Reply-To: <1405013926.74.0.877232363604.issue21951@psf.upfronthosting.co.za> Message-ID: <1410274267.59.0.724908746446.issue21951@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 16:59:56 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 09 Sep 2014 14:59:56 +0000 Subject: [issue21951] tcl test change crashes AIX In-Reply-To: <1405013926.74.0.877232363604.issue21951@psf.upfronthosting.co.za> Message-ID: <1410274796.1.0.249759765598.issue21951@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: As Victor noted on IRC, ckalloc() panics and doesn't returns NULL in case of error. We should use attemptckalloc() instead. ---------- stage: needs patch -> patch review Added file: http://bugs.python.org/file36582/tkinter_ckallock.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 17:21:58 2014 From: report at bugs.python.org (Matthew Barnett) Date: Tue, 09 Sep 2014 15:21:58 +0000 Subject: [issue14076] sqlite3 module ignores placeholders in CREATE TRIGGER code In-Reply-To: <1329853172.58.0.728674289337.issue14076@psf.upfronthosting.co.za> Message-ID: <1410276118.69.0.213450267208.issue14076@psf.upfronthosting.co.za> Matthew Barnett added the comment: For comparison: Python 3.1.3: [(b'',)] Python 3.2.5: [(None,)] Python 3.3.5: [(b'',)] Python 3.4.1: sqlite3.OperationalError: trigger cannot use variables ---------- nosy: +mrabarnett _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 18:00:03 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 09 Sep 2014 16:00:03 +0000 Subject: [issue4972] context management support in imaplib, smtplib, ftplib In-Reply-To: <1232213338.37.0.108210239108.issue4972@psf.upfronthosting.co.za> Message-ID: <1410278403.71.0.46273967639.issue4972@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks Berker. ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 18:08:09 2014 From: report at bugs.python.org (Matthew Barnett) Date: Tue, 09 Sep 2014 16:08:09 +0000 Subject: [issue22364] Unify error messages of re and regex In-Reply-To: <1410178976.27.0.421938794422.issue22364@psf.upfronthosting.co.za> Message-ID: <1410278889.96.0.239905162.issue22364@psf.upfronthosting.co.za> Matthew Barnett added the comment: > re: Cannot process flags argument with a compiled pattern > regex: can't process flags argument with a compiled pattern Error messages usually start with a lowercase letter, and I think that all the other ones in the re module do. By the way, which is preferred, "cannot" or "can't"? The regex module always uses "can't", but re module uses "cannot" except for "TypeError: can't use a bytes pattern on a string-like object", I think. Also, you said that one of the re module's messages was better, but didn't say which! Did you mean this one? > re: expected bytes, bytearray, or an object with the buffer interface, str found > regex: expected bytes instance, str found ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 18:14:43 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 09 Sep 2014 16:14:43 +0000 Subject: [issue4972] context management support in imaplib, smtplib, ftplib In-Reply-To: <1232213338.37.0.108210239108.issue4972@psf.upfronthosting.co.za> Message-ID: <1410279283.5.0.579286667372.issue4972@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think that's all with this issue. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 18:21:20 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 09 Sep 2014 16:21:20 +0000 Subject: [issue22369] "context management protocol" vs "context manager protocol" Message-ID: <1410279680.04.0.486393108686.issue22369@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Both terms are used in the documentation. Currently "context manager" wins (with score 225:19 in rst files). We should unify terminology across the documentation. ---------- assignee: docs at python components: Documentation messages: 226643 nosy: docs at python, eric.araujo, ezio.melotti, georg.brandl, serhiy.storchaka priority: normal severity: normal status: open title: "context management protocol" vs "context manager protocol" versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 18:24:51 2014 From: report at bugs.python.org (Antony Lee) Date: Tue, 09 Sep 2014 16:24:51 +0000 Subject: [issue22370] pathlib OS detection Message-ID: <1410279891.7.0.749304743952.issue22370@psf.upfronthosting.co.za> New submission from Antony Lee: Currently, pathlib contains the following check for the OS in the import section: try: import nt except ImportError: nt = None else: if sys.getwindowsversion()[:2] >= (6, 0): from nt import _getfinalpathname else: supports_symlinks = False _getfinalpathname = None I would like to suggest to switch this on testing for the value of `os.name` (as `PurePath.__new__` does), or possibly testing whether `sys.getwindowsversion` exists: the `nt` module is not publicly defined, so it wouldn't be unreasonable to have a file named `nt.py` on an Unix system (where this shouldn't cause any problems), in which case importing `pathlib` raises an AttributeError at the `getwindowsversion` line. ---------- components: Library (Lib) messages: 226644 nosy: Antony.Lee priority: normal severity: normal status: open title: pathlib OS detection versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 18:37:46 2014 From: report at bugs.python.org (Jonas Wagner) Date: Tue, 09 Sep 2014 16:37:46 +0000 Subject: [issue21122] CPython fails to build modules with LLVM LTO on Mac OS X In-Reply-To: <1396354260.96.0.514432416417.issue21122@psf.upfronthosting.co.za> Message-ID: <1410280666.03.0.993939494359.issue21122@psf.upfronthosting.co.za> Jonas Wagner added the comment: No response for a while, and problem solved... closing. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 18:40:16 2014 From: report at bugs.python.org (Jonas Wagner) Date: Tue, 09 Sep 2014 16:40:16 +0000 Subject: [issue5309] distutils doesn't parallelize extension module compilation In-Reply-To: <1235007592.93.0.0598331575131.issue5309@psf.upfronthosting.co.za> Message-ID: <1410280816.78.0.375958061323.issue5309@psf.upfronthosting.co.za> Jonas Wagner added the comment: I've checked the `dlopen` issue. This was due to a problem with UndefinedBehaviorSanitizer, and was solved by upgrading to Clang 3.5. It has little to do with this patch. Using this patch and http://bugs.python.org/issue22359 , I now get reliable parallel builds. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 19:11:06 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 09 Sep 2014 17:11:06 +0000 Subject: [issue22369] "context management protocol" vs "context manager protocol" In-Reply-To: <1410279680.04.0.486393108686.issue22369@psf.upfronthosting.co.za> Message-ID: <1410282666.43.0.578999550412.issue22369@psf.upfronthosting.co.za> R. David Murray added the comment: I think "context management protocol" is the better English phrasing. (grepping just for the full phrase I make it 38 vs 22, but I of course I may have missed some that are broken across lines). ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 19:57:08 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 09 Sep 2014 17:57:08 +0000 Subject: [issue21147] sqlite3 doesn't complain if the request contains a null character In-Reply-To: <1396544845.43.0.82545828662.issue21147@psf.upfronthosting.co.za> Message-ID: <1410285428.68.0.98734969476.issue21147@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is revised patch. There is yet one way to create Statement instance (Connection.__call__) and this patch covers it too. ---------- stage: needs patch -> patch review Added file: http://bugs.python.org/file36583/sqlite_null_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 19:59:09 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 09 Sep 2014 17:59:09 +0000 Subject: [issue22284] decimal module contains less symbols when the _decimal module is missing In-Reply-To: <1409133580.95.0.644404743555.issue22284@psf.upfronthosting.co.za> Message-ID: <3hsvHw4cyXz7Ll7@mail.python.org> Roundup Robot added the comment: New changeset 2b3dbbd2bd92 by Stefan Krah in branch '3.4': Issue #22284: Update decimal.__all__ http://hg.python.org/cpython/rev/2b3dbbd2bd92 New changeset 5bc23c111de1 by Stefan Krah in branch 'default': Issue #22284: Merge 3.4 http://hg.python.org/cpython/rev/5bc23c111de1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 20:00:20 2014 From: report at bugs.python.org (Matthias Klose) Date: Tue, 09 Sep 2014 18:00:20 +0000 Subject: [issue22371] tests failing with -uall and http_proxy and https_proxy set Message-ID: <1410285620.78.0.374799566495.issue22371@psf.upfronthosting.co.za> New submission from Matthias Klose: there are some tests failing when http_proxy and https_proxy is set and the network resource is enabled. I didn't analyze things, but I assume there needs some more fine-grained control about the network resource. the log of such a run is attached. the system doesn't have any outward connection besides the http_proxy and https_proxies. ---------- files: python3.4-net-tests messages: 226650 nosy: doko priority: normal severity: normal status: open title: tests failing with -uall and http_proxy and https_proxy set Added file: http://bugs.python.org/file36584/python3.4-net-tests _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 20:01:35 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 09 Sep 2014 18:01:35 +0000 Subject: [issue22284] decimal module contains less symbols when the _decimal module is missing In-Reply-To: <1409133580.95.0.644404743555.issue22284@psf.upfronthosting.co.za> Message-ID: <1410285695.2.0.0196337336398.issue22284@psf.upfronthosting.co.za> Stefan Krah added the comment: I didn't add __all__ to _decimal because of this thread here: https://mail.python.org/pipermail/python-dev/2001-February/012591.html ---------- components: +Library (Lib) dependencies: -Speed up _decimal import resolution: -> fixed stage: -> resolved status: open -> closed type: -> behavior versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 20:04:18 2014 From: report at bugs.python.org (Matthias Klose) Date: Tue, 09 Sep 2014 18:04:18 +0000 Subject: [issue22371] tests failing with -uall and http_proxy and https_proxy set In-Reply-To: <1410285620.78.0.374799566495.issue22371@psf.upfronthosting.co.za> Message-ID: <1410285858.66.0.468070297546.issue22371@psf.upfronthosting.co.za> Matthias Klose added the comment: forgot: some tests fail as well with -uall,-network and configured proxies. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 20:25:12 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 09 Sep 2014 18:25:12 +0000 Subject: [issue22369] "context management protocol" vs "context manager protocol" In-Reply-To: <1410279680.04.0.486393108686.issue22369@psf.upfronthosting.co.za> Message-ID: <1410287112.86.0.131014684333.issue22369@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: You are right, I missed that the "context manager" is separate term. Here is a patch. ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file36585/doc_context_management_protocol.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 20:28:41 2014 From: report at bugs.python.org (Riccardo) Date: Tue, 09 Sep 2014 18:28:41 +0000 Subject: [issue22373] PyArray_FromAny tries to deallocate double: 12 (d) Message-ID: <8938213B-EE74-4E68-B8F4-F30C79AF45B5@vodafone.it> New submission from Riccardo: Hi, I found this strange behaviour of PyArray_FromAny that manifest only inside a parallel region of openmp. I am using python 2.7.4 and numpy 1.8.0 *** Reference count error detected an attempt was made to deallocate 12 (d) *** and this is due to the PyArray_FromAny function that apparently does something also to the reference of NPY_DOUBLE or invisibly uses some kind of global variable generating race condition in a parallel implementation? If i insert PyArray_FromAny in a critical region the error never pops up. Best Regards, Riccardo P.s. i tried to send you more details and a piece of code but some characters are not accepted by your e-mail, ask me if you want more details ---------- messages: 226655 nosy: Il_Fox priority: normal severity: normal status: open title: PyArray_FromAny tries to deallocate double: 12 (d) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 21:24:12 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 09 Sep 2014 19:24:12 +0000 Subject: [issue22369] "context management protocol" vs "context manager protocol" In-Reply-To: <1410279680.04.0.486393108686.issue22369@psf.upfronthosting.co.za> Message-ID: <1410290652.68.0.630165275664.issue22369@psf.upfronthosting.co.za> R. David Murray added the comment: Patch looks fine to me. I don't know that the HISTORY/NEWS changes are really needed, but I suppose they don't hurt. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 22:09:12 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 09 Sep 2014 20:09:12 +0000 Subject: [issue20752] Difflib should provide the option of overriding the SequenceMatcher In-Reply-To: <1393193816.17.0.662615840954.issue20752@psf.upfronthosting.co.za> Message-ID: <1410293352.93.0.240103519055.issue20752@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Current status: Tim is currently not actively involved in Python development and no one who is active is enthusiastic about the proposal. Your proposal is to add dependency injection to the initializer for the 4 diff classes by adding 6 new parameters. I will comment on the proposal itself below. But first... Your initial message in support of the proposal was about as weak as possible: "it would be possible to ...". Lots of things are possible. For instance, we could add a Socket class replacement parameter to all stdlib functions and classes that use socket.Socket (and this has been requested in at least one case). However, only a few changes actually get done. Recognizing this ... Your later message gave one use case: Bazaar's experiments with an alternate implementation. To me, this example is still inadequate justification for a change. We agree that cut-and-paste is bad (though not terrible for one-off experiments). That is why Python allows dynamic patching ('monkeypatching') of modules and Python-coded classes as an alternative (though subclassing is often better for classes). import difflib # either class MyDiff: pass # not really ;-) # MyDiff might or might not subclass SequenceMatcher difflib.SequenceMatcher = MyDiff # or def f(self, *args): pass # again, not really difflib.SequenceMatcher.somemethod = f # either way, use difflib functions with alternate matcher. I consider subclassing + dynamic patching an adequate solution* for the one use case you mention and likely other uses. So I am inclined to reject the proposal as 'unnecessary'. (If multiple people were routinely monkeypatching difflib like this, I might change my mind.) * A context manager can be used to make the monkeypatching temporary and therefore local in effect. The following works. @contextlib.contextmanager def mp(ob, attr, new): old = getattr(ob, attr) setattr(ob, attr, new) yield setattr(ob, attr, old) As for the proposal itself: you mention possible API alternatives. I am more concerned about expanding our responsibility and corresponding test requirements. If you monkeypatch the module, then you are responsible for the results. If we add what amount to monkeypatching parameters, then we become responsible. We would have to make sure that the requirements for replacements are adequately defined and design at least one non-trivial replacement and run all the appropriate tests with that replacement. Your patch does not do this. I would not want to do this. We would also have to be prepared to maintain the expanded definition of the classes. Extending the mandate of the four classes from "work reasonably well with the builtin diff engine" to "work reasonably well with any 'similar' diff engine passed in by a user" is not as trivial as implied by the patch. For a simple function like filter, the requirement for the function parameter is simple. It must be a predicate with respect to the items yielded by the iterable arguments. That means returning False or True and never raising when applied to each item. It is easy to create alternatives such as lambda x: False, lambda x: True, lambda x: bool(x), and lambda x: x < 0, and test with appropriate iterables. I hope this explains a bit why function parameters are routine in Python while class parameters are much less common. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 22:43:11 2014 From: report at bugs.python.org (Robert Collins) Date: Tue, 09 Sep 2014 20:43:11 +0000 Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za> Message-ID: <1410295391.68.0.405746732804.issue7559@psf.upfronthosting.co.za> Robert Collins added the comment: You may need to apply the patch from http://bugs.python.org/issue19746 first as well - I was testing with both applied. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 22:52:39 2014 From: report at bugs.python.org (Rose Ames) Date: Tue, 09 Sep 2014 20:52:39 +0000 Subject: [issue13272] 2to3 fix_renames doesn't rename string.lowercase/uppercase/letters In-Reply-To: <1319700425.9.0.635731429373.issue13272@psf.upfronthosting.co.za> Message-ID: <1410295959.6.0.502478960614.issue13272@psf.upfronthosting.co.za> Rose Ames added the comment: Changing the imports only is straightforward, but I'm having trouble detecting and changing future uses of the variables, without also clobbering user-defined variables with the same names. I notice some of the current fixers have similar problems, for example the itertools fixer changes: ``` def imap(): pass imap() ``` to ``` def imap(): pass map() ``` This patch is a little smarter than that, but it only detects top-level definitions. For example, the lowercase in ``` class Foo: def __init__(self): self.lowercase = "blargh" ``` still gets renamed. I can work on this more, but would like to know: a) whether this fix is still wanted b) how smart it needs to be c) whether my approach is reasonable. I feel like there should be an easier way. ---------- keywords: +patch nosy: +superluser Added file: http://bugs.python.org/file36586/string_partial.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 22:55:39 2014 From: report at bugs.python.org (Rose Ames) Date: Tue, 09 Sep 2014 20:55:39 +0000 Subject: [issue13272] 2to3 fix_renames doesn't rename string.lowercase/uppercase/letters In-Reply-To: <1319700425.9.0.635731429373.issue13272@psf.upfronthosting.co.za> Message-ID: <1410296139.75.0.54936074403.issue13272@psf.upfronthosting.co.za> Rose Ames added the comment: ... d) how to format code :\ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 22:58:12 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 09 Sep 2014 20:58:12 +0000 Subject: [issue22374] Replace contextmanager example and improve explanation Message-ID: <1410296292.35.0.34327651623.issue22374@psf.upfronthosting.co.za> New submission from Terry J. Reedy: https://docs.python.org/3/library/contextlib.html#contextlib.contextmanager The current html contextmanager example is 'not recommended' for actual use, because there are better ways to accomplish the same goal. To me, is also unsatifactory in that the context management is only metaphorical (conceptual) and not actual. I propose the following as a replacement. It actually manages context and is, I believe, both useful and currently* the best way to accomplish the goal of temporarily monkeypatching a module, It was directly inspired by #20752, see msg226657, though there have been other issues where monkeypatching as a solution has been discussed. --- from contextlib import contextmanager import itertools as its @contextmanager def mp(ob, attr, new): old = getattr(ob, attr) setattr(ob, attr, new) yield setattr(ob, attr, old) def f(): pass print(its.count, its.cycle) with mp(its, 'count', f), mp(its, 'cycle', f): print(its.count, its.cycle) print(its.count, its.cycle) # # # --- I am aware that the above does not follow the current style, which I dislike, of confusingly mixing together batch file code and interactive input code. I think the above is how the example should be written. It would work even better if Sphinx gave comment lines a different background color. (A '##' prefix could be used to differentiate code comments from commented-out output lines.) In the same section, I find the following paragraph a bit confusing (perhaps is tries to say too much): "contextmanager() uses ContextDecorator so the context managers it creates can be used as decorators as well as in with statements. When used as a decorator, a new generator instance is implicitly created on each function call (this allows the otherwise ?one-shot? context managers created by contextmanager() to meet the requirement that context managers support multiple invocations in order to be used as decorators)." I am guessing that this means, among other things, that ContextDecorator is necessary and sufficient to use mp twice in one with statement. I intentionally added the double use to the example to make this possibility clear. * The only better way I know of would be if mp (spelled out as 'monkeypatch' were considered useful enough to be added to contextlib. ---------- assignee: docs at python components: Documentation messages: 226661 nosy: docs at python, ncoghlan, terry.reedy priority: normal severity: normal status: open title: Replace contextmanager example and improve explanation versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 23:50:05 2014 From: report at bugs.python.org (Alan Evangelista) Date: Tue, 09 Sep 2014 21:50:05 +0000 Subject: [issue22375] urllib2.urlopen().read().splitlines() opening a directory in a FTP server randomly returns incorrect results Message-ID: <1410299405.34.0.167812211508.issue22375@psf.upfronthosting.co.za> New submission from Alan Evangelista: Examples in Python command line: Try 1 ----- >>> import urllib2 urllib2.urlopen('ftp://:@/packages/repodata').read().splitlines() Output: Try 2 ----- >>> import urllib2 urllib2.urlopen('ftp://:@/packages/repodata').read().splitlines() Output: [] If I split urllib2.urlopen().read().splitlines() statement in 2 statements (urllib2.urlopen() and read().splitlines()), I always get correct results. import urllib2 a = urllib2.urlopen('ftp://alan_infinite:pass4root at 9.8.234.55/packages/repodata') >>> a.read().splitlines() Output: Verified in Python 2.6.6 in RHEL 6.4, Python 2.7.x in RHEL 7 and Python 2.7.3 in Ubuntu 14.04 ---------- components: Library (Lib) messages: 226662 nosy: alanoe priority: normal severity: normal status: open title: urllib2.urlopen().read().splitlines() opening a directory in a FTP server randomly returns incorrect results type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 23:51:52 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 09 Sep 2014 21:51:52 +0000 Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za> Message-ID: <1410299512.07.0.39517498388.issue7559@psf.upfronthosting.co.za> R. David Murray added the comment: OK, with both patches applied the output looks good. With a bit of luck I'll have some time to actually review the patches in a couple of hours. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 23:52:34 2014 From: report at bugs.python.org (Alan Evangelista) Date: Tue, 09 Sep 2014 21:52:34 +0000 Subject: [issue22375] urllib2.urlopen().read().splitlines() opening a directory in a FTP server randomly returns incorrect results In-Reply-To: <1410299405.34.0.167812211508.issue22375@psf.upfronthosting.co.za> Message-ID: <1410299554.23.0.416373393974.issue22375@psf.upfronthosting.co.za> Changes by Alan Evangelista : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 9 23:53:40 2014 From: report at bugs.python.org (Alan Evangelista) Date: Tue, 09 Sep 2014 21:53:40 +0000 Subject: [issue22376] urllib2.urlopen().read().splitlines() opening a directory in a FTP server randomly returns incorrect result Message-ID: <1410299620.11.0.341288273378.issue22376@psf.upfronthosting.co.za> New submission from Alan Evangelista: Examples in Python command line: Try 1 ----- >>> import urllib2 urllib2.urlopen('ftp://:@/packages/repodata').read().splitlines() Output: Try 2 ----- >>> import urllib2 urllib2.urlopen('ftp://:@/packages/repodata').read().splitlines() Output: [] If I split urllib2.urlopen().read().splitlines() statement in 2 statements (urllib2.urlopen() and read().splitlines()), I always get correct results. import urllib2 a = urllib2.urlopen('ftp://:@/packages/repodata') >>> a.read().splitlines() Output: Verified in Python 2.6.6 in RHEL 6.4, Python 2.7.x in RHEL 7 and Python 2.7.3 in Ubuntu 14.04 ---------- components: Library (Lib) messages: 226664 nosy: alanoe priority: normal severity: normal status: open title: urllib2.urlopen().read().splitlines() opening a directory in a FTP server randomly returns incorrect result type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 00:04:01 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 09 Sep 2014 22:04:01 +0000 Subject: [issue22375] urllib2.urlopen().read().splitlines() opening a directory in a FTP server randomly returns incorrect results In-Reply-To: <1410299405.34.0.167812211508.issue22375@psf.upfronthosting.co.za> Message-ID: <1410300241.07.0.152704979541.issue22375@psf.upfronthosting.co.za> R. David Murray added the comment: I think this was already fixed in issue 15002. ---------- nosy: +orsenthil, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 00:06:43 2014 From: report at bugs.python.org (Robert Collins) Date: Tue, 09 Sep 2014 22:06:43 +0000 Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za> Message-ID: <1410300403.8.0.694292873632.issue7559@psf.upfronthosting.co.za> Robert Collins added the comment: This is what I see in my tree: E ====================================================================== ERROR: test_os (unittest.loader.ModuleImportFailure) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/robertc/work/cpython/Lib/unittest/case.py", line 58, in testPartExecutor yield File "/home/robertc/work/cpython/Lib/unittest/case.py", line 577, in run testMethod() File "/home/robertc/work/cpython/Lib/unittest/loader.py", line 36, in testFailure raise exception ImportError: Failed to import test module: test_os Traceback (most recent call last): File "/home/robertc/work/cpython/Lib/unittest/loader.py", line 146, in loadTestsFromName module = __import__(module_name) File "/home/robertc/work/cpython/Lib/test/test_os.py", line 5, in import broken ImportError: No module named 'broken' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 00:07:24 2014 From: report at bugs.python.org (Robert Collins) Date: Tue, 09 Sep 2014 22:07:24 +0000 Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za> Message-ID: <1410300444.79.0.513208323116.issue7559@psf.upfronthosting.co.za> Robert Collins added the comment: Raced with your comment. Great - and thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 00:24:15 2014 From: report at bugs.python.org (Ram Rachum) Date: Tue, 09 Sep 2014 22:24:15 +0000 Subject: [issue22377] %Z in strptime doesn't match EST and others Message-ID: <1410301455.57.0.912701656833.issue22377@psf.upfronthosting.co.za> New submission from Ram Rachum: The documentation for %Z ( https://docs.python.org/3/library/datetime.html#strftime-strptime-behavior ) says it matches `EST` among others, but in practice it doesn't: Python 3.4.0 (v3.4.0:04f714765c13, Mar 16 2014, 19:25:23) [MSC v.1600 64 bit (AMD64)] on win32 Type "copyright", "credits" or "license()" for more information. DreamPie 1.2.1 >>> import datetime >>> datetime.datetime.strptime('2016-12-04 08:00:00 UTC', '%Y-%m-%d %H:%M:%S %Z') 0: datetime.datetime(2016, 12, 4, 8, 0) >>> datetime.datetime.strptime('2016-12-04 08:00:00 EST', '%Y-%m-%d %H:%M:%S %Z') Traceback (most recent call last): File "", line 1, in datetime.datetime.strptime('2016-12-04 08:00:00 EST', '%Y-%m-%d %H:%M:%S %Z') File "C:\Python34\lib\_strptime.py", line 500, in _strptime_datetime tt, fraction = _strptime(data_string, format) File "C:\Python34\lib\_strptime.py", line 337, in _strptime (data_string, format)) ValueError: time data '2016-12-04 08:00:00 EST' does not match format '%Y-%m-%d %H:%M:%S %Z' >>> ---------- components: Library (Lib) messages: 226668 nosy: cool-RR priority: normal severity: normal status: open title: %Z in strptime doesn't match EST and others type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 02:46:31 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Wed, 10 Sep 2014 00:46:31 +0000 Subject: [issue22373] PyArray_FromAny tries to deallocate double: 12 (d) In-Reply-To: <8938213B-EE74-4E68-B8F4-F30C79AF45B5@vodafone.it> Message-ID: <1410309991.81.0.627830131594.issue22373@psf.upfronthosting.co.za> Josh Rosenberg added the comment: This sounds like a bug in Numpy. You should probably post it to their tracker: https://github.com/numpy/numpy/issues ---------- nosy: +josh.rosenberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 02:57:50 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 10 Sep 2014 00:57:50 +0000 Subject: [issue22377] %Z in strptime doesn't match EST and others In-Reply-To: <1410301455.57.0.912701656833.issue22377@psf.upfronthosting.co.za> Message-ID: <1410310670.98.0.319673887084.issue22377@psf.upfronthosting.co.za> R. David Murray added the comment: Looking at the code, the only timezone strings it recognizes are utc, gmt, and whatever is in time.tzname (EST and EDT, in my case). This seems...barely useful, although clearly not useless :) And does not seem to be documented. ---------- nosy: +belopolsky, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 03:11:06 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 10 Sep 2014 01:11:06 +0000 Subject: [issue19746] No introspective way to detect ModuleImportFailure in unittest In-Reply-To: <1385262963.63.0.210713286499.issue19746@psf.upfronthosting.co.za> Message-ID: <1410311466.23.0.835063431778.issue19746@psf.upfronthosting.co.za> Changes by R. David Murray : Added file: http://bugs.python.org/file36587/issue19746-rebased.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 03:36:22 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 10 Sep 2014 01:36:22 +0000 Subject: [issue19746] No introspective way to detect ModuleImportFailure in unittest In-Reply-To: <1385262963.63.0.210713286499.issue19746@psf.upfronthosting.co.za> Message-ID: <1410312982.11.0.238062930521.issue19746@psf.upfronthosting.co.za> R. David Murray added the comment: Your patch isn't diffed against a revision from the cpython repo, and apparently didn't apply cleanly to tip, so no review link was generated. I uploaded a rebased patch to review, but don't actually have any line by line comments. You are right about the docs. Reading that, I thought it was saying that errors would have a list of the errors that show up in the summary as Errors=N, and not the ones that show up as Failures=N, which of course is completely off base for two reasons (but, then, I can never remember the difference between Failure and Error and always ignore what type the test failures are). Anyway, you probably want to talk about actual error types. I understand ImportError, but I have no idea what would trigger the 'Failed to call load_tests' error. Nor is it clear what would be a fatal error (easier just to say which errors are trapped, I think). It should also be mentioned that the contents of the list are an error message followed by a full traceback. And, frankly, I'm not sure why this is useful, and in particular why this implementation satisfies your use case. (I'm more interested in the issue 7559 patch, but since it based on this one I don't think I can just rebase it to review it.) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 03:42:24 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 10 Sep 2014 01:42:24 +0000 Subject: [issue22366] urllib.request.urlopen shoudl take a "context" (SSLContext) argument In-Reply-To: <1410198352.63.0.605714024836.issue22366@psf.upfronthosting.co.za> Message-ID: <1410313344.57.0.938319818238.issue22366@psf.upfronthosting.co.za> Senthil Kumaran added the comment: With the final review comment addressed, this could go in. Since you have commit rights, please feel free to commit it. (else, please assign this to me and I will commit and follow up with the buildbots) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 03:42:53 2014 From: report at bugs.python.org (jpv) Date: Wed, 10 Sep 2014 01:42:53 +0000 Subject: [issue22378] SO_MARK support for Linux Message-ID: <1410313373.25.0.741471917751.issue22378@psf.upfronthosting.co.za> New submission from jpv: Please add support for SO_MARK in socket module. >From man 7 socket: SO_MARK (since Linux 2.6.25): Set the mark for each packet sent through this socket (similar to the netfilter MARK target but socket-based). Changing the mark can be used for mark-based routing without netfilter or for packet filtering. Setting this option requires the CAP_NET_ADMIN capability. ---------- components: Extension Modules files: python-so_mark.patch keywords: patch messages: 226673 nosy: jpv priority: normal severity: normal status: open title: SO_MARK support for Linux type: enhancement versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file36588/python-so_mark.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 03:43:26 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 10 Sep 2014 01:43:26 +0000 Subject: [issue22366] urllib.request.urlopen shoudl take a "context" (SSLContext) argument In-Reply-To: <1410198352.63.0.605714024836.issue22366@psf.upfronthosting.co.za> Message-ID: <1410313406.11.0.74216079858.issue22366@psf.upfronthosting.co.za> Changes by Senthil Kumaran : ---------- assignee: -> alex _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 04:26:24 2014 From: report at bugs.python.org (Robert Collins) Date: Wed, 10 Sep 2014 02:26:24 +0000 Subject: [issue19746] No introspective way to detect ModuleImportFailure in unittest In-Reply-To: <1385262963.63.0.210713286499.issue19746@psf.upfronthosting.co.za> Message-ID: <1410315984.51.0.0529026550975.issue19746@psf.upfronthosting.co.za> Robert Collins added the comment: Thanks; I'm still learning how to get the system here to jump appropriately :). I thought I'd told hg to reset me to trunk... "You are right about the docs. Reading that, I thought it was saying that errors would have a list of the errors that show up in the summary as Errors=N, and not the ones that show up as Failures=N, which of course is completely off base for two reasons (but, then, I can never remember the difference between Failure and Error and always ignore what type the test failures are)." Ah, so this is specifically about *loader* errors, nothing to do with the ERROR and FAILURE concepts for the TestResult class; that definitely needs to be made more clear. "Anyway, you probably want to talk about actual error types. I understand ImportError, but I have no idea what would trigger the 'Failed to call load_tests' error. Nor is it clear what would be a fatal error (easier just to say which errors are trapped, I think)." 'Failed to call load_tests' is an existing error that can be triggered if a load_tests method errors. e.g. put this in a test_foo.py: def load_tests(loader, tests, pattern): raise Exception('fred') to see it with/without the patch. I'll take a stab at improving the docs in a bit. "It should also be mentioned that the contents of the list are an error message followed by a full traceback. And, frankly, I'm not sure why this is useful, and in particular why this implementation satisfies your use case." Ah! So I have an external runner which can enumerate the tests without running them. This is useful when the test suite is being distributed across many machines (simple hash based distribution can have very uneven running times, so enumerating the tests that need to run then scheduling based on runtime (or other metadata) gets better results). If the test suite can't be imported I need to show the failure of the import to users so they can fix it, but since the test suite may take hours (or even not be runnable locally) I need to do this without running the tests. Thus a simple list of the tracebacks encountered loading the test suite is sufficient. Where would be a good place to make this clearer? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 04:54:51 2014 From: report at bugs.python.org (Yongzhi Pan) Date: Wed, 10 Sep 2014 02:54:51 +0000 Subject: [issue22379] Empty exception message of str.join Message-ID: <1410317691.24.0.990266868285.issue22379@psf.upfronthosting.co.za> New submission from Yongzhi Pan: In the 2.7 branch, the exception message of str.join is missing when the argument is non-sequence: >>> ' '.join(None) Traceback (most recent call last): File "", line 1, in TypeError I fix this with a patch. After this: >>> ' '.join(None) Traceback (most recent call last): File "", line 1, in TypeError: can only join an iterable I also add test to this case. Can the test also be added to 3.x branches? ---------- components: ctypes files: str_join_exception_message.diff keywords: patch messages: 226675 nosy: fossilet priority: normal severity: normal status: open title: Empty exception message of str.join type: enhancement versions: Python 2.7 Added file: http://bugs.python.org/file36589/str_join_exception_message.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 04:57:40 2014 From: report at bugs.python.org (Alex Gaynor) Date: Wed, 10 Sep 2014 02:57:40 +0000 Subject: [issue22366] urllib.request.urlopen shoudl take a "context" (SSLContext) argument In-Reply-To: <1410198352.63.0.605714024836.issue22366@psf.upfronthosting.co.za> Message-ID: <1410317860.74.0.961545753547.issue22366@psf.upfronthosting.co.za> Alex Gaynor added the comment: Replied to the review; let me know if you agree with my comment. ---------- assignee: alex -> orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 04:58:53 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 10 Sep 2014 02:58:53 +0000 Subject: [issue22373] PyArray_FromAny tries to deallocate double: 12 (d) In-Reply-To: <8938213B-EE74-4E68-B8F4-F30C79AF45B5@vodafone.it> Message-ID: <1410317933.98.0.742109427482.issue22373@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> third party status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 05:50:04 2014 From: report at bugs.python.org (Stefan Behnel) Date: Wed, 10 Sep 2014 03:50:04 +0000 Subject: [issue22373] PyArray_FromAny tries to deallocate double: 12 (d) In-Reply-To: <8938213B-EE74-4E68-B8F4-F30C79AF45B5@vodafone.it> Message-ID: <1410321004.63.0.770250484874.issue22373@psf.upfronthosting.co.za> Stefan Behnel added the comment: Agreed that it's not a bug in CPython, but my guess is that it's not a bug in NumPy either. The C function you call (which IIRC creates a new NumPy array) almost certainly needs the GIL to protect it against race conditions, and since you mentioned OpenMP, you most likely released the GIL. So, just re-acquire the GIL around the call (and make sure you don't have any other threading problems in your code). ---------- nosy: +scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 07:07:24 2014 From: report at bugs.python.org (Elizabeth Myers) Date: Wed, 10 Sep 2014 05:07:24 +0000 Subject: [issue22380] Y2K compliance section in FAQ is 14 years too old Message-ID: <1410325644.2.0.420860619285.issue22380@psf.upfronthosting.co.za> New submission from Elizabeth Myers: As seen at https://docs.python.org/3/faq/general.html#is-python-y2k-year-2000-compliant; this is 2014 - Y2K compliance hasn't been a relevant topic for, well, 14 years, and I doubt this is a "frequently asked question" nowadays. The "As of August 2003" portion is even out of date (11 years old!). IMHO this ought to be taken out of the docs, unless this is still something people are asking about. ---------- assignee: docs at python components: Documentation messages: 226678 nosy: Elizacat, docs at python priority: normal severity: normal status: open title: Y2K compliance section in FAQ is 14 years too old type: enhancement versions: 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 Sep 10 07:16:57 2014 From: report at bugs.python.org (Martin Panter) Date: Wed, 10 Sep 2014 05:16:57 +0000 Subject: =?utf-8?q?=5Bissue20132=5D_Many_incremental_codecs_don=E2=80=99t_handle_f?= =?utf-8?q?ragmented_data?= In-Reply-To: <1388929738.44.0.851837204966.issue20132@psf.upfronthosting.co.za> Message-ID: <1410326217.24.0.956945864029.issue20132@psf.upfronthosting.co.za> Martin Panter added the comment: Stream reader interfaces suffer the same problem. Test cases: codecs.getreader("unicode-escape")(BytesIO(br"\u2013")).read(1) codecs.getreader("hex-codec")(BytesIO(b"33")).read(1) codecs.getreader("base64-codec")(BytesIO(b"AA==")).read(1) TestCase().assertEqual(b"=", codecs.getreader("quopri-codec")(BytesIO(b"=3D")).read(1)) Even though the ?zlib? incremental decoder is okay, its stream reader still suffers this problem. I was going to check for zip bomb behaviour when you call read() with a limited number of input ?characters?, but got this instead: >>> codecs.getreader("zlib-codec")(bomb).read(1, 1) zlib.error: Error -5 while decompressing data: incomplete or truncated stream Similar problems with stream writers, for instance: >>> w = codecs.getwriter("base64-codec")(BytesIO()) >>> w.write(b"1"); w.write(b"2"); w.reset(); w.getvalue() b'MQ==\nMg==\n' # Should be b"MTI=\n" I also noticed StreamWriter.writelines() assumes it is encoding text, and does not work at least with ?base64-codec?: >>>> codecs.getwriter("base64-codec")(BytesIO()).writelines((b"1", b"2")) TypeError: sequence item 0: expected str instance, bytes found ---------- versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 07:23:20 2014 From: report at bugs.python.org (Martin Panter) Date: Wed, 10 Sep 2014 05:23:20 +0000 Subject: [issue13881] Stream encoder for zlib_codec doesn't use the incremental encoder In-Reply-To: <1327606849.1.0.885842099772.issue13881@psf.upfronthosting.co.za> Message-ID: <1410326600.92.0.872137753743.issue13881@psf.upfronthosting.co.za> Martin Panter added the comment: The corresponding stream reader has a related issue which I mentioned in Issue 20132 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 07:29:41 2014 From: report at bugs.python.org (Martin Panter) Date: Wed, 10 Sep 2014 05:29:41 +0000 Subject: [issue13881] Stream encoder for zlib_codec doesn't use the incremental encoder In-Reply-To: <1327606849.1.0.885842099772.issue13881@psf.upfronthosting.co.za> Message-ID: <1410326981.9.0.944243697583.issue13881@psf.upfronthosting.co.za> Martin Panter added the comment: Even if all these issues aren?t worth fixing, I think the documentation should at least say which codecs work fully (e.g. most text encodings), which ones work suboptimally (e.g. UTF-7), and which ones only work for single-shot encoding and decoding. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 07:41:44 2014 From: report at bugs.python.org (Martin Panter) Date: Wed, 10 Sep 2014 05:41:44 +0000 Subject: [issue20506] Command to display all available Import Library In-Reply-To: <1391476994.58.0.915135187283.issue20506@psf.upfronthosting.co.za> Message-ID: <1410327704.56.0.909260126128.issue20506@psf.upfronthosting.co.za> Martin Panter added the comment: I wrote some code that does something like this for a hacky custom readline completer. See the import_list() method at . It looks like I?m using a combination of ?sys.builtin_module_names? and pkgutil.iter_modules(), with a whole lot of compatibility and bug workarounds. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 08:46:00 2014 From: report at bugs.python.org (Claudiu Popa) Date: Wed, 10 Sep 2014 06:46:00 +0000 Subject: [issue17442] code.InteractiveInterpreter doesn't display the exception cause In-Reply-To: <1363468664.92.0.794606977989.issue17442@psf.upfronthosting.co.za> Message-ID: <1410331560.06.0.181349113839.issue17442@psf.upfronthosting.co.za> Claudiu Popa added the comment: If the patch doesn't need anything else, can it be committed? ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 08:58:58 2014 From: report at bugs.python.org (Claudiu Popa) Date: Wed, 10 Sep 2014 06:58:58 +0000 Subject: [issue16104] Compileall script: add option to use multiple cores In-Reply-To: <1349124414.14.0.0730954283721.issue16104@psf.upfronthosting.co.za> Message-ID: <1410332338.68.0.925229440552.issue16104@psf.upfronthosting.co.za> Claudiu Popa added the comment: If there is nothing left to do for this patch, can it be committed? ---------- Added file: http://bugs.python.org/file36590/16104.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 09:01:35 2014 From: report at bugs.python.org (Claudiu Popa) Date: Wed, 10 Sep 2014 07:01:35 +0000 Subject: [issue20752] Difflib should provide the option of overriding the SequenceMatcher In-Reply-To: <1393193816.17.0.662615840954.issue20752@psf.upfronthosting.co.za> Message-ID: <1410332495.96.0.881316651814.issue20752@psf.upfronthosting.co.za> Changes by Claudiu Popa : ---------- nosy: -Claudiu.Popa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 09:11:22 2014 From: report at bugs.python.org (Martin Panter) Date: Wed, 10 Sep 2014 07:11:22 +0000 Subject: [issue15955] gzip, bz2, lzma: add option to limit output size In-Reply-To: <1347884562.79.0.801674791772.issue15955@psf.upfronthosting.co.za> Message-ID: <1410333082.04.0.698609442672.issue15955@psf.upfronthosting.co.za> Martin Panter added the comment: If people are worried about the best low-level decompressor API, maybe leave that as a future enhancement, and just rely on using the existing file reader APIs. I would expect them to have a sensible decompressed buffer size limit, however ?bzip2? and LZMA look susceptible to zip bombing: >>> GzipFile(fileobj=gzip_bomb).read(1) b'\x00' >>> BZ2File(bzip_bomb).read(1) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.4/bz2.py", line 293, in read return self._read_block(size) File "/usr/lib/python3.4/bz2.py", line 254, in _read_block while n > 0 and self._fill_buffer(): File "/usr/lib/python3.4/bz2.py", line 218, in _fill_buffer self._buffer = self._decompressor.decompress(rawblock) MemoryError >>> z = LZMAFile(lzma_bomb) >>> z.read(1) b'\x00' # Slight delay before returning >>> len(z._buffer) 55675075 # Decompressed much more data than I asked for ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 09:21:53 2014 From: report at bugs.python.org (Martin Panter) Date: Wed, 10 Sep 2014 07:21:53 +0000 Subject: [issue22374] Replace contextmanager example and improve explanation In-Reply-To: <1410296292.35.0.34327651623.issue22374@psf.upfronthosting.co.za> Message-ID: <1410333713.51.0.736097908905.issue22374@psf.upfronthosting.co.za> Martin Panter added the comment: You should probably use try / finally in your context manager to always restore the attribute. Having said that, I recently wrote a similar context manager, and then later discovered there is already ?unittest.mock.patch? and/or ?unittest.mock.patch.object? via Issue 11664, which apparently can do this job. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 09:23:46 2014 From: report at bugs.python.org (Martin Panter) Date: Wed, 10 Sep 2014 07:23:46 +0000 Subject: [issue16830] Add skip_host and skip_accept_encoding to httplib/http.client In-Reply-To: <1356998273.75.0.911756727263.issue16830@psf.upfronthosting.co.za> Message-ID: <1410333826.74.0.65975997468.issue16830@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 10:17:52 2014 From: report at bugs.python.org (Chris Lasher) Date: Wed, 10 Sep 2014 08:17:52 +0000 Subject: [issue9951] introduce bytes.hex method In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za> Message-ID: <1410337072.14.0.855279705878.issue9951@psf.upfronthosting.co.za> Changes by Chris Lasher : ---------- nosy: +gotgenes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 10:53:04 2014 From: report at bugs.python.org (Riccardo) Date: Wed, 10 Sep 2014 08:53:04 +0000 Subject: [issue22373] PyArray_FromAny tries to deallocate double: 12 (d) In-Reply-To: <1410321004.63.0.770250484874.issue22373@psf.upfronthosting.co.za> Message-ID: <4B937814-F907-40DD-B588-40C15806DFA2@vodafone.it> Riccardo added the comment: Great, i solved trying to avoid calls to python code in parallel regions. Thanks for pointing me in right direction, i wasn?t thinking at all to the GIL, i was convinced i had tryed everything and that it was a bug.. Regards On 10 Sep 2014, at 05:50, Stefan Behnel wrote: > > Stefan Behnel added the comment: > > Agreed that it's not a bug in CPython, but my guess is that it's not a bug in NumPy either. The C function you call (which IIRC creates a new NumPy array) almost certainly needs the GIL to protect it against race conditions, and since you mentioned OpenMP, you most likely released the GIL. So, just re-acquire the GIL around the call (and make sure you don't have any other threading problems in your code). > > ---------- > nosy: +scoder > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 11:34:37 2014 From: report at bugs.python.org (Matthias Klose) Date: Wed, 10 Sep 2014 09:34:37 +0000 Subject: [issue22381] update zlib in 2.7 to 1.2.8 Message-ID: <1410341675.94.0.179025133528.issue22381@psf.upfronthosting.co.za> New submission from Matthias Klose: I'd like to update zlib in 2.7 to 1.2.8. zlib isn't used at all for posix builds, because it requires a system installed zlib. However I don't know what is is used for Windows and MacOSX. Please could somebody check? My rationale for the update is that the .exe files require a zlib, and I'd like to build these on Linux with a mingw cross compiler. The patch brings zlib to the status as found on the 3.4 branch. ---------- assignee: ronaldoussoren components: Build, Macintosh, Windows files: zlib-update.diff keywords: patch messages: 226688 nosy: doko, hynek, ned.deily, ronaldoussoren, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: update zlib in 2.7 to 1.2.8 versions: Python 2.7 Added file: http://bugs.python.org/file36591/zlib-update.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 14:00:20 2014 From: report at bugs.python.org (Alan Evangelista) Date: Wed, 10 Sep 2014 12:00:20 +0000 Subject: [issue22376] urllib2.urlopen().read().splitlines() opening a directory in a FTP server randomly returns incorrect result In-Reply-To: <1410299620.11.0.341288273378.issue22376@psf.upfronthosting.co.za> Message-ID: <1410350420.5.0.612054428057.issue22376@psf.upfronthosting.co.za> Alan Evangelista added the comment: duplicate of #22375. I closed that one because I wanted to edit the original bug description and I could not, preferred to create a new bug. R. David Murray's comment in #22375: "I think this was already fixed in issue 15002" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 14:10:29 2014 From: report at bugs.python.org (Berker Peksag) Date: Wed, 10 Sep 2014 12:10:29 +0000 Subject: [issue17442] code.InteractiveInterpreter doesn't display the exception cause In-Reply-To: <1363468664.92.0.794606977989.issue17442@psf.upfronthosting.co.za> Message-ID: <1410351029.91.0.108653082379.issue17442@psf.upfronthosting.co.za> Berker Peksag added the comment: Claudiu, did you see Jim Jewett's review on Rietveld? ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 14:27:13 2014 From: report at bugs.python.org (Claudiu Popa) Date: Wed, 10 Sep 2014 12:27:13 +0000 Subject: [issue17442] code.InteractiveInterpreter doesn't display the exception cause In-Reply-To: <1363468664.92.0.794606977989.issue17442@psf.upfronthosting.co.za> Message-ID: <1410352033.1.0.316732476983.issue17442@psf.upfronthosting.co.za> Claudiu Popa added the comment: Actually, no, it seems that I didn't receive any mail regarding them. I'll update the patch accordingly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 14:29:40 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 10 Sep 2014 12:29:40 +0000 Subject: [issue9951] introduce bytes.hex method In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za> Message-ID: <1410352180.55.0.931059233712.issue9951@psf.upfronthosting.co.za> STINNER Victor added the comment: New features cannot be added to Python 2 anymore, only to the current development version which is now Python 3.5. If new methods are added to bytes, they should be added to bytearray too. Maybe we should also consider add them to memoryview? memoryview has already a .bytes() method and can be casted to type "B" (array of integers in range 0..255). The float type has .hex() and .fromhex() methods. We should kepe these names to stay consistent. Which kind of output do you prefer? "0xHH 0xHH ...", "HH HH HH ..." or "HHHHHH..."? Do you want to add parameters to choose the format? Current binascii format: >>> binascii.hexlify('abc') '616263' ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 14:42:16 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 10 Sep 2014 12:42:16 +0000 Subject: [issue19746] No introspective way to detect ModuleImportFailure in unittest In-Reply-To: <1385262963.63.0.210713286499.issue19746@psf.upfronthosting.co.za> Message-ID: <1410352936.52.0.499462768433.issue19746@psf.upfronthosting.co.za> R. David Murray added the comment: Yeah, I figured out it was loader only errors after I read the code :) "load_tests not called" is very different from "load_tests produced an exception", so the text of the error message should be changed accordingly. I understood your use case more-or-less, my question was, why is the error *string* the thing returned? Given that the synthetic test encapsulates and re-raises the error, might it be more useful to store the exception object in the errors attribute rather than the message strings? That would seem to provide more introspectability. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 14:44:51 2014 From: report at bugs.python.org (Claudiu Popa) Date: Wed, 10 Sep 2014 12:44:51 +0000 Subject: [issue17442] code.InteractiveInterpreter doesn't display the exception cause In-Reply-To: <1363468664.92.0.794606977989.issue17442@psf.upfronthosting.co.za> Message-ID: <1410353091.46.0.613722540731.issue17442@psf.upfronthosting.co.za> Claudiu Popa added the comment: Here's the new version which fixes the comments from the review. ---------- Added file: http://bugs.python.org/file36592/issue17442_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 14:55:55 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 10 Sep 2014 12:55:55 +0000 Subject: [issue22379] Empty exception message of str.join In-Reply-To: <1410317691.24.0.990266868285.issue22379@psf.upfronthosting.co.za> Message-ID: <1410353755.43.0.637082159196.issue22379@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks for the report and patch. The test doesn't fail before your patch. I think checkraises should be changed to make sure the message isn't empty. And yes, the tests should be added to 3.5. ---------- components: +Interpreter Core -ctypes nosy: +r.david.murray stage: -> needs patch type: enhancement -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 15:26:44 2014 From: report at bugs.python.org (Michael R. Bernstein) Date: Wed, 10 Sep 2014 13:26:44 +0000 Subject: [issue7744] Allow site.addsitedir insert to beginning of sys.path In-Reply-To: <1264018763.75.0.862537731081.issue7744@psf.upfronthosting.co.za> Message-ID: <1410355604.22.0.783276506972.issue7744@psf.upfronthosting.co.za> Michael R. Bernstein added the comment: And in case it isn't clear how such a method would help, here is what the earlier code would look like: import os import site dirname = 'lib' dirpath = os.path.join(os.path.dirname(__file__), dirname) site.insertsitedir(1, dirpath) But (other than the imports) it could even be reduced to a one-liner: site.insertsitedir(1, os.path.join(os.path.dirname(__file__), 'lib')) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 16:25:18 2014 From: report at bugs.python.org (Brett Cannon) Date: Wed, 10 Sep 2014 14:25:18 +0000 Subject: [issue16104] Compileall script: add option to use multiple cores In-Reply-To: <1349124414.14.0.0730954283721.issue16104@psf.upfronthosting.co.za> Message-ID: <1410359118.5.0.969608866065.issue16104@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 16:36:24 2014 From: report at bugs.python.org (Miki Tebeka) Date: Wed, 10 Sep 2014 14:36:24 +0000 Subject: [issue22240] argparse support for "python -m module" in help In-Reply-To: <1408564751.42.0.897410433728.issue22240@psf.upfronthosting.co.za> Message-ID: <1410359784.0.0.896847234764.issue22240@psf.upfronthosting.co.za> Miki Tebeka added the comment: Thanks Paul, will work on that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 16:51:50 2014 From: report at bugs.python.org (Steve Dower) Date: Wed, 10 Sep 2014 14:51:50 +0000 Subject: [issue22381] update zlib in 2.7 to 1.2.8 In-Reply-To: <1410341675.94.0.179025133528.issue22381@psf.upfronthosting.co.za> Message-ID: <1410360710.51.0.899148353503.issue22381@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 17:13:47 2014 From: report at bugs.python.org (Dan O'Reilly) Date: Wed, 10 Sep 2014 15:13:47 +0000 Subject: [issue22087] _UnixDefaultEventLoopPolicy should either create a new loop or explicilty fail when get_event_loop() is called from a multiprocessing child process In-Reply-To: <1406397670.19.0.283234608675.issue22087@psf.upfronthosting.co.za> Message-ID: <1410362027.8.0.435779072032.issue22087@psf.upfronthosting.co.za> Dan O'Reilly added the comment: Are any other changes needed here? I'm still not completely clear on what Victor meant with his last comment. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 17:16:27 2014 From: report at bugs.python.org (Dan O'Reilly) Date: Wed, 10 Sep 2014 15:16:27 +0000 Subject: [issue9205] Parent process hanging in multiprocessing if children terminate unexpectedly In-Reply-To: <1278619251.36.0.833806205056.issue9205@psf.upfronthosting.co.za> Message-ID: <1410362187.25.0.733980222976.issue9205@psf.upfronthosting.co.za> Dan O'Reilly added the comment: Is it possible to have this issue re-opened, so that the new patch is more likely to get attention? Or should I create a new issue for the multiprocessing patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 18:01:20 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 10 Sep 2014 16:01:20 +0000 Subject: [issue19232] Speed up _decimal import In-Reply-To: <1381579399.63.0.316110193187.issue19232@psf.upfronthosting.co.za> Message-ID: <3htSdX2FDcz7LjW@mail.python.org> Roundup Robot added the comment: New changeset 8bf51cf94405 by Stefan Krah in branch 'default': Issue #19232: Speed up decimal import. Additionally, since _decimal is http://hg.python.org/cpython/rev/8bf51cf94405 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 19:16:23 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 10 Sep 2014 17:16:23 +0000 Subject: [issue19232] Speed up _decimal import In-Reply-To: <1381579399.63.0.316110193187.issue19232@psf.upfronthosting.co.za> Message-ID: <1410369383.24.0.653674081216.issue19232@psf.upfronthosting.co.za> Stefan Krah added the comment: We could speed up the import further by not importing collections in _decimal. That could be done once structseq fully implements the namedtuple protocol (for DecimalTuple). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 19:45:21 2014 From: report at bugs.python.org (Ned Deily) Date: Wed, 10 Sep 2014 17:45:21 +0000 Subject: [issue22381] update zlib in 2.7 to 1.2.8 In-Reply-To: <1410341675.94.0.179025133528.issue22381@psf.upfronthosting.co.za> Message-ID: <1410371121.9.0.477945040547.issue22381@psf.upfronthosting.co.za> Ned Deily added the comment: OS X builds are posix builds so, by default, they dynamically link with the system-supplied zlib. The particular version varies by release: the most recent (10.9) supplies zlib 1.2.5. So updating the zlib in Modules should have no effect on OS X. Does that answer your question? ---------- assignee: ronaldoussoren -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 19:58:54 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 10 Sep 2014 17:58:54 +0000 Subject: [issue9951] introduce bytes.hex method In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za> Message-ID: <1410371934.49.0.889669199689.issue9951@psf.upfronthosting.co.za> Terry J. Reedy added the comment: To answer Serhiy, the goal is to have a bytes method that represents bytes as bytes rather than as a mixture of bytes and encoded ascii characters. This would aid people who work with bytes that are not encoded ascii and that do not embed encoded ascii. It should not be necessary to import anything. >>> hex(int.from_bytes(b'abc', 'big')) '0x616263' is a bit baroque and produces a hex representation of an int, not of multiple bytes. I think following the float precedent is a good idea. >>> float.fromhex(1.5.hex()) 1.5 >>> float.fromhex('0x1.8000000000000p+0').hex() '0x1.8000000000000p+0' The output of bytes.hex should be one that is accepted by bytes.fromhex, which is to say, hex 'digit' pairs. Spaces are optionally allowed between pairs. I would add a 'spaces' parameter, defaulting to False. to output spaces when set to true. (Or possible reverse the default -- what do potential users think?) A possible altermative for the parameter could be form='' (default), form=' ' (add spaces), and form='x' to add '\x' prefixes. I don't know that adding '\x' would be useful. The prefixes are not accepted by .fromhex. ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 20:30:15 2014 From: report at bugs.python.org (william tonkin) Date: Wed, 10 Sep 2014 18:30:15 +0000 Subject: [issue22382] sqlite3 connection built from apsw connection should raise IntegrityError, not DatabaseError Message-ID: <1410373815.55.0.143596528672.issue22382@psf.upfronthosting.co.za> New submission from william tonkin: python Python 2.7.6 (default, Dec 23 2013, 13:16:30) [GCC 4.1.2 20080704 (Red Hat 4.1.2-54)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> ----- test script ----- import apsw import sqlite3 print 'sqlite3.version:', sqlite3.version print 'sqlite3.sqlite_version:', sqlite3.sqlite_version print 'apsw.apswversion:', apsw.apswversion() sqlite3_not_from_apsw = sqlite3.connect(':memory:') apsw_conn = apsw.Connection(':memory:') sqlite3_from_apsw = sqlite3.connect(apsw_conn) cursor_not_from_apsw = sqlite3_not_from_apsw.cursor() cursor_from_apsw = sqlite3_from_apsw.cursor() sqlite3_not_from_apsw.execute( "create table foo ( a timestamp check(datetime(a) is not null))") try: sqlite3_not_from_apsw.execute( "insert into foo values (?)", ('',)) except sqlite3.DatabaseError as foo: print 'not from apsw, repr(foo)', repr(foo) sqlite3_from_apsw.execute( "create table foo ( a timestamp check(datetime(a) is not null))") try: sqlite3_from_apsw.execute( "insert into foo values (?)", ('',)) except sqlite3.DatabaseError as foo: print 'from apsw, repr(foo)', repr(foo) ------------- output: sqlite3.version: 2.6.0 sqlite3.sqlite_version: 3.8.2 apsw.apswversion: 3.8.2-r1 not from apsw, repr(foo) IntegrityError('CHECK constraint failed: foo',) from apsw, repr(foo) DatabaseError('CHECK constraint failed: foo',) -------- Note that when the sqlite3 connection is built from an apsw connection the insert statement that violates the check constraint raises 'DatabaseError' and not 'IntegrityError'. ---------- messages: 226704 nosy: wtonkin priority: normal severity: normal status: open title: sqlite3 connection built from apsw connection should raise IntegrityError, not DatabaseError versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 20:41:54 2014 From: report at bugs.python.org (Ned Deily) Date: Wed, 10 Sep 2014 18:41:54 +0000 Subject: [issue22382] sqlite3 connection built from apsw connection should raise IntegrityError, not DatabaseError In-Reply-To: <1410373815.55.0.143596528672.issue22382@psf.upfronthosting.co.za> Message-ID: <1410374514.76.0.271144387231.issue22382@psf.upfronthosting.co.za> Ned Deily added the comment: If you are reporting an issue with how apsw behaves, be aware that it is a third-party project, not in the Python standard library. As such, you should report the issue to its bug tracker (https://github.com/rogerbinns/apsw/issues) as listed in its PyPI entry: https://pypi.python.org/pypi/apsw/ If not about apsw, feel free to elaborate and reopen this issue. ---------- nosy: +ned.deily resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 20:52:57 2014 From: report at bugs.python.org (paul j3) Date: Wed, 10 Sep 2014 18:52:57 +0000 Subject: [issue22240] argparse support for "python -m module" in help In-Reply-To: <1408564751.42.0.897410433728.issue22240@psf.upfronthosting.co.za> Message-ID: <1410375177.56.0.348115714192.issue22240@psf.upfronthosting.co.za> paul j3 added the comment: One way to reduce the testing burden, and to be extra safe regarding backward compatibility is to make this action optional, rather than the default. For example, make `_prog_name` importable (i.e. change the name), and then expect the user to use it explicitly with: parser = argparse.ArgumentParser(prog=argparse.prog_name(), ...) and leave the `parse_args` stack unchanged. This would require an addition to the documentation. The user can then check for themselves whether `prog_name` gets the right name, given their packaging and calling method. It's a little more work for a package creator, but arguably it's a good thing to aware of. The added tests, if any, can focus on the output of this function, rather than the output of the 'print_help'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 21:04:36 2014 From: report at bugs.python.org (Miki Tebeka) Date: Wed, 10 Sep 2014 19:04:36 +0000 Subject: [issue22240] argparse support for "python -m module" in help In-Reply-To: <1408564751.42.0.897410433728.issue22240@psf.upfronthosting.co.za> Message-ID: <1410375876.64.0.373108296899.issue22240@psf.upfronthosting.co.za> Miki Tebeka added the comment: I don't like changing code just to accommodate testing. Will try to think of a way to solve this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 21:05:03 2014 From: report at bugs.python.org (Christian Kleineidam) Date: Wed, 10 Sep 2014 19:05:03 +0000 Subject: =?utf-8?q?=5Bissue22383=5D_Crazy_unicode_=3A_How_g_and_=C9=A1_look_the_sa?= =?utf-8?q?me_but_are_two_different_characters?= Message-ID: <1410375903.75.0.0668351290623.issue22383@psf.upfronthosting.co.za> New submission from Christian Kleineidam: g = 2 i = 2 ? = 1 a = g + i a >>> 4 Given the font on which this bug tracker runs it's possible to see why a is 4 and not 3. On the other hand there are plenty of fonts (such as Arial, Tahoma or Courier New) that display chr(103) and chr(609) the same way. If a programmer is not aware of the issue it will make it nearly impossible to spot bugs that come up when someone names variables or functions via using chr(609). Python should either forbid people from using chr(609) to name functions and variables or treat it as a synonym of chr(103). ---------- components: Unicode messages: 226708 nosy: Christian.Kleineidam, ezio.melotti, haypo priority: normal severity: normal status: open title: Crazy unicode : How g and ? look the same but are two different characters type: behavior versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 21:13:03 2014 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 10 Sep 2014 19:13:03 +0000 Subject: =?utf-8?q?=5Bissue22383=5D_Crazy_unicode_=3A_How_g_and_=C9=A1_look_the_sa?= =?utf-8?q?me_but_are_two_different_characters?= In-Reply-To: <1410375903.75.0.0668351290623.issue22383@psf.upfronthosting.co.za> Message-ID: <1410376383.23.0.581649853092.issue22383@psf.upfronthosting.co.za> Ezio Melotti added the comment: The same happens with 'l' and 'I' on some fonts. Forbid those chars or treat them as synonyms is not an option. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed versions: -Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 21:43:42 2014 From: report at bugs.python.org (Rose Ames) Date: Wed, 10 Sep 2014 19:43:42 +0000 Subject: [issue21739] Add hint about expression in list comprehensions (https://docs.python.org/2/tutorial/datastructures.html#list-comprehensions) In-Reply-To: <1402600679.26.0.179499997563.issue21739@psf.upfronthosting.co.za> Message-ID: <1410378222.14.0.0512328259251.issue21739@psf.upfronthosting.co.za> Rose Ames added the comment: Fwiw, I've seen a beginner be confused by this. Patch attached. ---------- keywords: +patch nosy: +superluser Added file: http://bugs.python.org/file36593/reword.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 21:51:11 2014 From: report at bugs.python.org (=?utf-8?q?Evens_Fortun=C3=A9?=) Date: Wed, 10 Sep 2014 19:51:11 +0000 Subject: [issue21228] Missing enumeration of HTTPResponse Objects methods of urllib.request.urlopen's http.client.HTTPResponse? In-Reply-To: <1397520483.48.0.224250148615.issue21228@psf.upfronthosting.co.za> Message-ID: <1410378671.63.0.911761188338.issue21228@psf.upfronthosting.co.za> Evens Fortun? added the comment: Well, there wasn't any indication before that the returned object was implementing the "addinfourl" interface. So I don't think we have lost anything. In what situation this interface is useful?? The following comment (that you had highlighted in your comment) gives the impression that theses methods are there only to provide compatibility with clients using old-styles responses. http://hg.python.org/cpython/file/c499cc2c4a06/Lib/http/client.py#l772 That would imply that newer clients would usually not use these methods. If you want to document this, I think the "addinfourl" interface should then be better described somewhere else where it would include the fact that the HTTPResponse class implements it. Anyway, I don't see the advantage of using a getter method (like geturl()) instead of accessing directly the attribute. For me, this is less pythonic. If you ever have to attach a behaviour to the access of this attribute, a property could then be defined. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 22:14:34 2014 From: report at bugs.python.org (Aivar Annamaa) Date: Wed, 10 Sep 2014 20:14:34 +0000 Subject: [issue22384] Tk.report_callback_exception kills process when run with pythonw.exe Message-ID: <1410380074.61.0.464879354999.issue22384@psf.upfronthosting.co.za> New submission from Aivar Annamaa: Seems that the statement 'sys.stderr.write("Exception in Tkinter callback\n")' in Tk.report_callback_exception fails when the program is run with pythonw.exe, and brings down the whole process. A simple sample is attached. ---------- files: demo.py messages: 226712 nosy: Aivar.Annamaa priority: normal severity: normal status: open title: Tk.report_callback_exception kills process when run with pythonw.exe Added file: http://bugs.python.org/file36594/demo.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 22:14:53 2014 From: report at bugs.python.org (Aivar Annamaa) Date: Wed, 10 Sep 2014 20:14:53 +0000 Subject: [issue22384] Tk.report_callback_exception kills process when run with pythonw.exe In-Reply-To: <1410380074.61.0.464879354999.issue22384@psf.upfronthosting.co.za> Message-ID: <1410380093.7.0.748208861441.issue22384@psf.upfronthosting.co.za> Changes by Aivar Annamaa : ---------- components: +Tkinter type: -> crash versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 22:22:13 2014 From: report at bugs.python.org (Georg Brandl) Date: Wed, 10 Sep 2014 20:22:13 +0000 Subject: [issue22380] Y2K compliance section in FAQ is 14 years too old In-Reply-To: <1410325644.2.0.420860619285.issue22380@psf.upfronthosting.co.za> Message-ID: <1410380533.41.0.660207663772.issue22380@psf.upfronthosting.co.za> Georg Brandl added the comment: +1 ---------- nosy: +georg.brandl versions: -Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 22:24:05 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 10 Sep 2014 20:24:05 +0000 Subject: [issue22369] "context management protocol" vs "context manager protocol" In-Reply-To: <1410279680.04.0.486393108686.issue22369@psf.upfronthosting.co.za> Message-ID: <1410380645.09.0.0809201921245.issue22369@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: docs at python -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 22:46:21 2014 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 10 Sep 2014 20:46:21 +0000 Subject: [issue22380] Y2K compliance section in FAQ is 14 years too old In-Reply-To: <1410325644.2.0.420860619285.issue22380@psf.upfronthosting.co.za> Message-ID: <1410381981.09.0.250909040448.issue22380@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +easy nosy: +ezio.melotti stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 22:55:10 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 10 Sep 2014 20:55:10 +0000 Subject: [issue21739] Add hint about expression in list comprehensions (https://docs.python.org/2/tutorial/datastructures.html#list-comprehensions) In-Reply-To: <1402600679.26.0.179499997563.issue21739@psf.upfronthosting.co.za> Message-ID: <1410382510.45.0.275029337464.issue21739@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks! While this patch does sort-of go into a detail, it seems to me like it does it in a tutorial-appropriate fashion. I'm +1 on applying this. ---------- stage: needs patch -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 22:59:48 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 10 Sep 2014 20:59:48 +0000 Subject: [issue22369] "context management protocol" vs "context manager protocol" In-Reply-To: <1410279680.04.0.486393108686.issue22369@psf.upfronthosting.co.za> Message-ID: <3htbFw0ng7z7Ll2@mail.python.org> Roundup Robot added the comment: New changeset cc5b183a2ad4 by Serhiy Storchaka in branch '3.4': Issue #22369: Change "context manager protocol" to "context management protocol". http://hg.python.org/cpython/rev/cc5b183a2ad4 New changeset ad568d52af4b by Serhiy Storchaka in branch 'default': Issue #22369: Change "context manager protocol" to "context management protocol". http://hg.python.org/cpython/rev/ad568d52af4b New changeset e62082a70b6b by Serhiy Storchaka in branch '2.7': Issue #22369: Change "context manager protocol" to "context management protocol". http://hg.python.org/cpython/rev/e62082a70b6b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 23:01:30 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 10 Sep 2014 21:01:30 +0000 Subject: [issue21228] Missing enumeration of HTTPResponse Objects methods of urllib.request.urlopen's http.client.HTTPResponse? In-Reply-To: <1397520483.48.0.224250148615.issue21228@psf.upfronthosting.co.za> Message-ID: <1410382890.96.0.529540838496.issue21228@psf.upfronthosting.co.za> R. David Murray added the comment: Indeed, geturl is deprecated. I'm not sure where you see it documented, I don't see it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 23:11:27 2014 From: report at bugs.python.org (Matej Cepl) Date: Wed, 10 Sep 2014 21:11:27 +0000 Subject: [issue19494] urllib2.HTTPBasicAuthHandler (or urllib.request.HTTPBasicAuthHandler) doesn't work with GitHub API v3 and similar In-Reply-To: <1383577219.47.0.139805262488.issue19494@psf.upfronthosting.co.za> Message-ID: <1410383487.21.0.0135243577241.issue19494@psf.upfronthosting.co.za> Matej Cepl added the comment: New version of the HTTPBasicPriorAuthHandler patch ---------- Added file: http://bugs.python.org/file36595/0001-Alternative-handler-adding-Authorization-header-even.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 23:13:50 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 10 Sep 2014 21:13:50 +0000 Subject: [issue22380] Y2K compliance section in FAQ is 14 years too old In-Reply-To: <1410325644.2.0.420860619285.issue22380@psf.upfronthosting.co.za> Message-ID: <3htbZ54SVlz7Lk5@mail.python.org> Roundup Robot added the comment: New changeset 071a2620917f by Benjamin Peterson in branch '3.4': y2k compliance, lol (closes #22380) http://hg.python.org/cpython/rev/071a2620917f New changeset 02c94b9451f8 by Benjamin Peterson in branch '2.7': y2k compliance, lol (closes #22380) http://hg.python.org/cpython/rev/02c94b9451f8 New changeset e3a3c8809d09 by Benjamin Peterson in branch 'default': merge 3.4 (#22380) http://hg.python.org/cpython/rev/e3a3c8809d09 ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 23:16:09 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 10 Sep 2014 21:16:09 +0000 Subject: =?utf-8?q?=5Bissue22383=5D_Crazy_unicode_=3A_How_g_and_=C9=A1_look_the_sa?= =?utf-8?q?me_but_are_two_different_characters?= In-Reply-To: <1410375903.75.0.0668351290623.issue22383@psf.upfronthosting.co.za> Message-ID: <1410383769.14.0.644495056174.issue22383@psf.upfronthosting.co.za> STINNER Victor added the comment: Just avoid using such symbols in your application. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 23:20:14 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 10 Sep 2014 21:20:14 +0000 Subject: [issue21147] sqlite3 doesn't complain if the request contains a null character In-Reply-To: <1396544845.43.0.82545828662.issue21147@psf.upfronthosting.co.za> Message-ID: <1410384014.46.0.573387733062.issue21147@psf.upfronthosting.co.za> STINNER Victor added the comment: sqlite_null_2.patch looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 23:24:04 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 10 Sep 2014 21:24:04 +0000 Subject: [issue21951] tcl test change crashes AIX In-Reply-To: <1405013926.74.0.877232363604.issue21951@psf.upfronthosting.co.za> Message-ID: <1410384244.41.0.78210677541.issue21951@psf.upfronthosting.co.za> STINNER Victor added the comment: I'm not sure that tkinter_ckallock.patch is correct. Extract of attemptckalloc() manual page: "If the allocation fails, these functions will return NULL. Note that on some platforms, but not all, attempting to allocate a zero-sized block of memory will also cause these functions to return NULL." http://linux.die.net/man/3/attemptckalloc It looks like you are fixing two different issues in the same patch: fix AIX and enhance handling of memory allocation failure. Can you please split your patch in two parts? For AIX, adding these two lines for list/tuple should be enough: if (size == 0) return Tcl_NewListObj(0, NULL); ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 23:25:06 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 10 Sep 2014 21:25:06 +0000 Subject: [issue22369] "context management protocol" vs "context manager protocol" In-Reply-To: <1410279680.04.0.486393108686.issue22369@psf.upfronthosting.co.za> Message-ID: <1410384306.53.0.494242395614.issue22369@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you David. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 23:26:55 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 10 Sep 2014 21:26:55 +0000 Subject: [issue21951] tcl test change crashes AIX In-Reply-To: <1405013926.74.0.877232363604.issue21951@psf.upfronthosting.co.za> Message-ID: <1410384415.13.0.927720983335.issue21951@psf.upfronthosting.co.za> STINNER Victor added the comment: "I'm not sure that tkinter_ckallock.patch is correct." Oh, when I read my message, I realized that I was not explicit enough. It looks like attemptckalloc() can be called with 0 at some places with tkinter_ckallock.patch. But I didn't check carefully, the patch is maybe correct. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 23:34:53 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 10 Sep 2014 21:34:53 +0000 Subject: [issue22338] test_json crash on memory allocation failure In-Reply-To: <1409873237.86.0.801776520079.issue22338@psf.upfronthosting.co.za> Message-ID: <3htc2N6xHBz7Lk5@mail.python.org> Roundup Robot added the comment: New changeset 3ac9f9576ce6 by Victor Stinner in branch '3.4': Issue #22338: Fix a crash in the json module on memory allocation failure. http://hg.python.org/cpython/rev/3ac9f9576ce6 New changeset 135fc23e475c by Victor Stinner in branch 'default': (Merge 3.4) Issue #22338: Fix a crash in the json module on memory allocation http://hg.python.org/cpython/rev/135fc23e475c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 23:36:57 2014 From: report at bugs.python.org (Matej Cepl) Date: Wed, 10 Sep 2014 21:36:57 +0000 Subject: [issue19494] urllib2.HTTPBasicAuthHandler (or urllib.request.HTTPBasicAuthHandler) doesn't work with GitHub API v3 and similar In-Reply-To: <1383577219.47.0.139805262488.issue19494@psf.upfronthosting.co.za> Message-ID: <1410385017.5.0.122379034997.issue19494@psf.upfronthosting.co.za> Matej Cepl added the comment: BTW, should I add anything for https://docs.python.org/3.5/whatsnew/3.5.html ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 23:37:27 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 10 Sep 2014 21:37:27 +0000 Subject: [issue22338] test_json crash on memory allocation failure In-Reply-To: <1409873237.86.0.801776520079.issue22338@psf.upfronthosting.co.za> Message-ID: <1410385047.36.0.32864030754.issue22338@psf.upfronthosting.co.za> STINNER Victor added the comment: > Modules/_json.c:1558: item = NULL; > You can move it outside of the loop. I prefer to set item to NULL just after PyList_SET_ITEM() to make it explicit that the list now owns the reference. > But may be it will be better to make this "item" variable local. "item" is also used below, and I don't want to have two "item" variables. I commited my to Python 3.4 & 3.5. Python 2.7 doesn't look to be affected, chunk and item are not cleared (Py_DECREF) in the error handler ("bail:" label). Thanks for the review. ---------- resolution: -> fixed status: open -> closed versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 10 23:40:15 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 10 Sep 2014 21:40:15 +0000 Subject: [issue22326] tempfile.TemporaryFile fails on NFS v4 filesystems In-Reply-To: <1409659206.56.0.836891924559.issue22326@psf.upfronthosting.co.za> Message-ID: <1410385215.89.0.0479132523228.issue22326@psf.upfronthosting.co.za> STINNER Victor added the comment: > It becomes then still a Python problem, as tempfile.TemporaryFile is not generally usable any more. Well, it looks like you are the first one to complain, whereas the module is at least 10 years old. So it looks more like an issue in your setup (as you wrote), than a bug in Python. Which syscalls fails with errno 5? Can you run your example with strace to identify the syscall? *If* a patch should be written, we need to identify which Python line should be modified. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 00:03:37 2014 From: report at bugs.python.org (=?utf-8?q?Evens_Fortun=C3=A9?=) Date: Wed, 10 Sep 2014 22:03:37 +0000 Subject: [issue21228] Missing enumeration of HTTPResponse Objects methods of urllib.request.urlopen's http.client.HTTPResponse? In-Reply-To: <1397520483.48.0.224250148615.issue21228@psf.upfronthosting.co.za> Message-ID: <1410386617.64.0.91037598042.issue21228@psf.upfronthosting.co.za> Evens Fortun? added the comment: To be honest, it may be inspired by what's written a few lines lower, for ftp, files dans data urls even though the return object is not the same as the http(s) urls http://hg.python.org/cpython/file/c499cc2c4a06/Doc/library/urllib.request.rst#l75 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 00:15:01 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 10 Sep 2014 22:15:01 +0000 Subject: [issue21228] Missing enumeration of HTTPResponse Objects methods of urllib.request.urlopen's http.client.HTTPResponse? In-Reply-To: <1397520483.48.0.224250148615.issue21228@psf.upfronthosting.co.za> Message-ID: <1410387301.0.0.77962574681.issue21228@psf.upfronthosting.co.za> R. David Murray added the comment: Ah, I was looking at the http docs. I wonder if we just missed the urllib docs when we made the changes. Either that, or I'm misremembering things. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 00:30:31 2014 From: report at bugs.python.org (HCT) Date: Wed, 10 Sep 2014 22:30:31 +0000 Subject: [issue9951] introduce bytes.hex method In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za> Message-ID: <1410388231.07.0.0835302690733.issue9951@psf.upfronthosting.co.za> HCT added the comment: @Victor binascii.hexlify('abc') doesn't work in 3.4. I assume this is a new thing for 3.5 >>> import binascii >>> binascii.hexlify('abc') Traceback (most recent call last): File "", line 1, in TypeError: 'str' does not support the buffer interface >>> >>> binascii.hexlify(b'abc') b'616263' @Terry I think that space shouldn't be done by the hex function. if you allow space between each hex, then what do you do if the bytes are actually from array of 64-bit ints? getting into support separating space for every X bytes is probably not the scope of this. I propose the hex functions for bytes/memoryview/bytearray should be as follow. I prefer to not have the '0x' prefix at all, but I understand all other hex functions adds it. would be good to have the option to not have the prefix. bytes.hex( byte_order = sys.byteorder ) returns a hex string in small letter. ex. c0ffee bytes.HEX( byte_order = sys.byteorder ) returns a hex string in capital letters. ex. DEADBEEF bytes.from_hex( hex_str, byte_order = sys.byteorder ) returns a bytes object. ex. b'\xFE\xFF' another more flexible way is to have hex function accept a format similar to how sscanf works, but this will probably bring lots of trouble for all kinds of variants to support and the required error checks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 01:04:07 2014 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 10 Sep 2014 23:04:07 +0000 Subject: [issue9951] introduce bytes.hex method In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za> Message-ID: <1410390247.33.0.30641506895.issue9951@psf.upfronthosting.co.za> Nick Coghlan added the comment: Just as a recap of at least some of the *current* ways to do a bytes -> hex conversion: >>> import codecs >>> codecs.encode(b"abc", "hex") b'616263' >>> import binascii >>> binascii.hexlify(b"abc") b'616263' >>> import base64 >>> base64.b16encode(b"abc") b'616263' >>> hex(int.from_bytes(b"abc", "big")) '0x616263' >>> hex(int.from_bytes(b"abc", "little")) '0x636261' Thus, the underlying purpose of this proposal is to provide a single "more obvious way to do it". As per the recent discussion on python-ideas, the point where that is most useful is in debugging output. However, rather than a new method on bytes/bytearray/memoryview for this, I instead suggest it would be appropriate to extend the default handling of the "x" and "X" format characters to accept arbitrary bytes-like objects. The processing of these characters would be as follows: "x": display a-f as lowercase digits "X": display A-F as uppercase digits "#": includes 0x prefix ".precision": chunks output, placing a space after every bytes ",": uses a comma as the separator, rather than a space Output order would match binascii.hexlify() Examples: format(b"xyz", "x") -> '78797a' format(b"xyz", "X") -> '78797A' format(b"xyz", "#x") -> '0x78797a' format(b"xyz", ".1x") -> '78 79 7a' format(b"abcdwxyz", ".4x") -> '61626364 7778797a' format(b"abcdwxyz", "#.4x") -> '0x61626364 0x7778797a' format(b"xyz", ",.1x") -> '78,79,7a' format(b"abcdwxyz", ",.4x") -> '61626364,7778797a' format(b"abcdwxyz", "#,.4x") -> '0x61626364,0x7778797a' This approach makes it easy to inspect binary data, with the ability to inject regular spaces or commas to improved readability. Those are the basic features needed to support debugging. Anything more complicated than that, and we're starting to want something more like the struct module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 01:29:34 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 10 Sep 2014 23:29:34 +0000 Subject: [issue9951] introduce bytes.hex method In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za> Message-ID: <1410391774.33.0.620860901273.issue9951@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The proposal is to add a .hex method (similar to binascii.hexlify) that is the inverse of .fromhex (similar to binascii.unhexlify), as originally specified in PEP 358. http://legacy.python.org/dev/peps/pep-0358/ "The object has a .hex() method that does the reverse [of .frombytes] >> bytes([92, 83, 80, 255]).hex() '5c5350ff' " If we add .hex, I think we should stick with this: no 0x or \x prefix. To aid debugging, I would change spaces to be None or a positive int n to insert a space every n bytes. So .hex(8) for an array of 64 bit ints. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 01:55:01 2014 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 10 Sep 2014 23:55:01 +0000 Subject: [issue22385] Allow 'x' and 'X' to accept bytes objects in string formatting Message-ID: <1410393301.25.0.193851592698.issue22385@psf.upfronthosting.co.za> New submission from Nick Coghlan: Inspired by the discussion in issue 9951, I believe it would be appropriate to extend the default handling of the "x" and "X" format characters to accept arbitrary bytes-like objects. The processing of these characters would be as follows: "x": display a-f as lowercase digits "X": display A-F as uppercase digits "#": includes 0x prefix ".precision": chunks output, placing a space after every bytes ",": uses a comma as the separator, rather than a space Output order would match binascii.hexlify() Examples: format(b"xyz", "x") -> '78797a' format(b"xyz", "X") -> '78797A' format(b"xyz", "#x") -> '0x78797a' format(b"xyz", ".1x") -> '78 79 7a' format(b"abcdwxyz", ".4x") -> '61626364 7778797a' format(b"abcdwxyz", "#.4x") -> '0x61626364 0x7778797a' format(b"xyz", ",.1x") -> '78,79,7a' format(b"abcdwxyz", ",.4x") -> '61626364,7778797a' format(b"abcdwxyz", "#,.4x") -> '0x61626364,0x7778797a' This approach makes it easy to inspect binary data, with the ability to inject regular spaces or commas to improved readability. Those are the basic features needed to support debugging. Anything more complicated than that, and we're starting to want something more like the struct module. ---------- components: Interpreter Core messages: 226733 nosy: ncoghlan priority: normal severity: normal status: open title: Allow 'x' and 'X' to accept bytes objects in string formatting versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 01:55:33 2014 From: report at bugs.python.org (HCT) Date: Wed, 10 Sep 2014 23:55:33 +0000 Subject: [issue9951] introduce bytes.hex method In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za> Message-ID: <1410393333.26.0.277146720069.issue9951@psf.upfronthosting.co.za> HCT added the comment: @Terry natural bytes do not have space between them. I would think adding space is for typesetting situation which should be done by user's post-processing. I agree to not have any prefix to make .hex and from_hex uniform. the \x is the str representation of bytes when you print a bytes object directly in Python. the actual bytes object doesn't have that \x prefix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 01:57:04 2014 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 10 Sep 2014 23:57:04 +0000 Subject: [issue9951] introduce bytes.hex method In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za> Message-ID: <1410393424.59.0.792274841666.issue9951@psf.upfronthosting.co.za> Nick Coghlan added the comment: Good point Terry - I split the proposal to support bytes-like objects for 'x' and 'X' in string formatting out to issue 22385. For bytes.hex, I'm inclined to stick with the dirt simple option described in PEP 358: the exact behaviour of the current binascii.hexlify(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 01:57:42 2014 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 10 Sep 2014 23:57:42 +0000 Subject: [issue22385] Allow 'x' and 'X' to accept bytes-like objects in string formatting In-Reply-To: <1410393301.25.0.193851592698.issue22385@psf.upfronthosting.co.za> Message-ID: <1410393462.26.0.837336784829.issue22385@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- title: Allow 'x' and 'X' to accept bytes objects in string formatting -> Allow 'x' and 'X' to accept bytes-like objects in string formatting _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 02:01:20 2014 From: report at bugs.python.org (Martin Panter) Date: Thu, 11 Sep 2014 00:01:20 +0000 Subject: [issue21228] Missing enumeration of HTTPResponse Objects methods of urllib.request.urlopen's http.client.HTTPResponse? In-Reply-To: <1397520483.48.0.224250148615.issue21228@psf.upfronthosting.co.za> Message-ID: <1410393680.91.0.627619860838.issue21228@psf.upfronthosting.co.za> Martin Panter added the comment: By removing the ?addinfourl? methods for HTTP responses, you are making it unnecessarily hard to handle header fields and metadata from the response. I do not know of any other documented way of getting the eventual redirect target, other than geturl(). And code to parse the Content-Type, which I understand is also returned for file: URLs, would start to get ugly (untested): info = getattr(response, "info", None) if info: type = info().get_content_type() # Easy! else: import cgi type = cgi.parse_header(response.getheader("Content-Type))[0] Since a HTTP status code only seems to be returned for HTTP responses, deprecating or removing getcode() in favour of ?HTTPResponse.status? might be okay, but I think info() and geturl() should stay. Maybe a ?url? attribute is more Pythonic, but as far as I am aware that has never been documented for Python 2 or 3 for any URL type. I would not expect much existing code to be using it, and deprecating geturl() seems like a needless annoyance. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 02:06:21 2014 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 11 Sep 2014 00:06:21 +0000 Subject: [issue9951] introduce bytes.hex method In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za> Message-ID: <1410393981.61.0.139206333273.issue9951@psf.upfronthosting.co.za> Nick Coghlan added the comment: Open question: the current patch adds bytes.hex() and bytearray.hex(). Should we also add memoryview.hex(), or split that suggestion out to a separate proposal? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 02:20:55 2014 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 11 Sep 2014 00:20:55 +0000 Subject: [issue9951] introduce bytes.hex method In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za> Message-ID: <1410394855.03.0.232871914781.issue9951@psf.upfronthosting.co.za> Mark Lawrence added the comment: I'd say add memoryview.hex() here as everything seems related. Victor has also mentioned memoryview in msg226692. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 03:09:58 2014 From: report at bugs.python.org (Clark Boylan) Date: Thu, 11 Sep 2014 01:09:58 +0000 Subject: [issue22386] Python 3.4 logging.getLevelName() no longer maps string to level. Message-ID: <1410397798.62.0.061648555693.issue22386@psf.upfronthosting.co.za> New submission from Clark Boylan: Prior to http://hg.python.org/cpython/rev/5629bf4c6bba?revcount=60 logging.getLevelName(lvl) would map string lvl args like 'INFO' to the integer level value 20. After this change the string to int level mapping is removed and you can only map level to string. This removes the only public method for doing this mapping in the logging module. Old Behavior: >>> logging.getLevelName('INFO') 20 >>> logging.getLevelName(20) 'INFO' >>> New Behavior: >>> logging.getLevelName('INFO') 'Level INFO' >>> logging.getLevelName(20) 'INFO' >>> logging.getLevelName(logging.INFO) 'INFO' >>> The old behavior is valuable because it allows you to sanity check log levels provided as strings before attempting to use them. It seems that without this public mapping you have to rely on Logger.setLevel(lvl) throwing a ValueError which it seems to do only in 2.7 and greater. ---------- components: Library (Lib) messages: 226739 nosy: cboylan priority: normal severity: normal status: open title: Python 3.4 logging.getLevelName() no longer maps string to level. type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 03:12:34 2014 From: report at bugs.python.org (Alex Gaynor) Date: Thu, 11 Sep 2014 01:12:34 +0000 Subject: [issue22386] Python 3.4 logging.getLevelName() no longer maps string to level. In-Reply-To: <1410397798.62.0.061648555693.issue22386@psf.upfronthosting.co.za> Message-ID: <1410397954.61.0.8233042716.issue22386@psf.upfronthosting.co.za> Alex Gaynor added the comment: I believe something like the following diff restores the previous behavior (untested!): diff --git a/Lib/logging/__init__.py b/Lib/logging/__init__.py index a61c2b0..4a8f83e 100644 --- a/Lib/logging/__init__.py +++ b/Lib/logging/__init__.py @@ -129,7 +129,7 @@ def getLevelName(level): Otherwise, the string "Level %s" % level is returned. """ - return _levelToName.get(level, ("Level %s" % level)) + return _levelToName.get(level, _nameToLevel.get(level, ("Level %s" % level))) def addLevelName(level, levelName): """ ---------- nosy: +alex _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 06:24:12 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 11 Sep 2014 04:24:12 +0000 Subject: [issue21228] Missing enumeration of HTTPResponse Objects methods of urllib.request.urlopen's http.client.HTTPResponse? In-Reply-To: <1397520483.48.0.224250148615.issue21228@psf.upfronthosting.co.za> Message-ID: <1410409452.9.0.221344279314.issue21228@psf.upfronthosting.co.za> R. David Murray added the comment: I think I'm thinking of the Request API, and not the Response API. So ignore my comments about deprecation, I'm not sure what the status is. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 07:20:47 2014 From: report at bugs.python.org (=?utf-8?q?Evens_Fortun=C3=A9?=) Date: Thu, 11 Sep 2014 05:20:47 +0000 Subject: [issue21228] Missing enumeration of HTTPResponse Objects methods of urllib.request.urlopen's http.client.HTTPResponse? In-Reply-To: <1397520483.48.0.224250148615.issue21228@psf.upfronthosting.co.za> Message-ID: <1410412847.09.0.415441717436.issue21228@psf.upfronthosting.co.za> Evens Fortun? added the comment: Look, the subject of this issue is to clarify the methods of the urllib.request.urlopen()'s return value for http(s) URLs. Nobody seemed to work on this for 4 months. That's why I tried to submit a patch after looking into the code to try to do my part to help. If you think that my patch is not clear enough and would need to be more precise or maybe even that it is plain wrong, please submit a new patch with your ideas so that we can close eventually this issue. I really didn't think that it would get this complicated? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 08:33:12 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 11 Sep 2014 06:33:12 +0000 Subject: [issue22381] update zlib in 2.7 to 1.2.8 In-Reply-To: <1410341675.94.0.179025133528.issue22381@psf.upfronthosting.co.za> Message-ID: <3htqzW4ldQz7Ljw@mail.python.org> Roundup Robot added the comment: New changeset 3c343588f6a6 by doko in branch '2.7': - Issue #22381: Update zlib to 1.2.8. http://hg.python.org/cpython/rev/3c343588f6a6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 09:06:41 2014 From: report at bugs.python.org (Piotr Dobrogost) Date: Thu, 11 Sep 2014 07:06:41 +0000 Subject: [issue2943] Distutils should generate a better error message when the SDK is not installed In-Reply-To: <1211455981.94.0.404413935613.issue2943@psf.upfronthosting.co.za> Message-ID: <1410419201.08.0.280418920413.issue2943@psf.upfronthosting.co.za> Changes by Piotr Dobrogost : ---------- nosy: +piotr.dobrogost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 09:09:17 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 11 Sep 2014 07:09:17 +0000 Subject: [issue22381] update zlib in 2.7 to 1.2.8 In-Reply-To: <1410341675.94.0.179025133528.issue22381@psf.upfronthosting.co.za> Message-ID: <3htrn8365dz7Lk0@mail.python.org> Roundup Robot added the comment: New changeset 769126143656 by doko in branch '2.7': - Issue #22381: Update zlib to 1.2.8. http://hg.python.org/cpython/rev/769126143656 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 09:09:25 2014 From: report at bugs.python.org (Chris Lasher) Date: Thu, 11 Sep 2014 07:09:25 +0000 Subject: [issue9951] introduce bytes.hex method In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za> Message-ID: <1410419365.1.0.00342527148671.issue9951@psf.upfronthosting.co.za> Chris Lasher added the comment: int has int.from_bytes and int.to_bytes. Currently, bytes has bytes.fromhex. Would the core developers please consider naming the method "bytes.tohex" instead of "bytes.hex", so there's at least a modicum of consistency in the method names of Python's builtin types? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 09:12:17 2014 From: report at bugs.python.org (Ned Deily) Date: Thu, 11 Sep 2014 07:12:17 +0000 Subject: [issue22385] Allow 'x' and 'X' to accept bytes-like objects in string formatting In-Reply-To: <1410393301.25.0.193851592698.issue22385@psf.upfronthosting.co.za> Message-ID: <1410419537.33.0.666276593483.issue22385@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 09:13:47 2014 From: report at bugs.python.org (Ned Deily) Date: Thu, 11 Sep 2014 07:13:47 +0000 Subject: [issue22386] Python 3.4 logging.getLevelName() no longer maps string to level. In-Reply-To: <1410397798.62.0.061648555693.issue22386@psf.upfronthosting.co.za> Message-ID: <1410419627.56.0.343226456454.issue22386@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 09:23:31 2014 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 11 Sep 2014 07:23:31 +0000 Subject: [issue22385] Allow 'x' and 'X' to accept bytes-like objects in string formatting In-Reply-To: <1410393301.25.0.193851592698.issue22385@psf.upfronthosting.co.za> Message-ID: <1410420211.26.0.868148705936.issue22385@psf.upfronthosting.co.za> Eric V. Smith added the comment: I think this would need to be implemented by adding bytes.__format__. I can't think of a way to make it work on bytes-like objects in general. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 09:23:36 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 11 Sep 2014 07:23:36 +0000 Subject: [issue16662] load_tests not invoked in package/__init__.py In-Reply-To: <1355217291.85.0.41912767842.issue16662@psf.upfronthosting.co.za> Message-ID: <1410420216.67.0.792863018364.issue16662@psf.upfronthosting.co.za> STINNER Victor added the comment: The changeset d0ff527c53da5b925b61a8a70afc686ca6e05960 related to this issue introduced a regression in test_unittest. The test now fails on Windows. Example: http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/5065/steps/test/logs/stdio ====================================================================== ERROR: test_discover_with_init_module_that_raises_SkipTest_on_import (unittest.test.test_discovery.TestDiscovery) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\test\test_discovery.py", line 451, in test_discover_with_init_module_that_raises_SkipTest_on_import suite = loader.discover('/foo') File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\loader.py", line 284, in discover tests = list(self._find_tests(start_dir, pattern)) File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\loader.py", line 319, in _find_tests paths = sorted(os.listdir(start_dir)) File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\test\test_discovery.py", line 388, in list_dir return list(vfs[path]) KeyError: 'C:\\foo' ---------- nosy: +haypo resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 09:25:21 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 11 Sep 2014 07:25:21 +0000 Subject: [issue22385] Allow 'x' and 'X' to accept bytes-like objects in string formatting In-Reply-To: <1410393301.25.0.193851592698.issue22385@psf.upfronthosting.co.za> Message-ID: <1410420321.12.0.70055076871.issue22385@psf.upfronthosting.co.za> STINNER Victor added the comment: > ".precision": chunks output, placing a space after every bytes I dislike this option. There is already "%.s" in Python 2 and Python 3 (and printf of the C language) which truncates the string. If you need such special output, please write your own function. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 09:34:35 2014 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 11 Sep 2014 07:34:35 +0000 Subject: [issue22385] Allow 'x' and 'X' to accept bytes-like objects in string formatting In-Reply-To: <1410393301.25.0.193851592698.issue22385@psf.upfronthosting.co.za> Message-ID: <1410420875.6.0.104328499043.issue22385@psf.upfronthosting.co.za> Eric V. Smith added the comment: I'm not particularly wild about the .precision syntax either, but I think the feature is generally useful. Adding bytes.__format__ is exactly what "special output for bytes" _is_, as far as format() is concerned. Another option would be to invent a new format specification for bytes. There's no reason it needs to follow the same syntax as for str, int, etc., except for ease of remembering the syntax, and some code reuse. For example, although it's insane, you could do: format(b'abcdwxyz', 'use_spaces,grouping=4,add_prefix') -> '0x61626364 0x7778797a' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 09:42:36 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 11 Sep 2014 07:42:36 +0000 Subject: [issue9951] introduce bytes.hex method In-Reply-To: <1410390247.33.0.30641506895.issue9951@psf.upfronthosting.co.za> Message-ID: <54115262.5080803@egenix.com> Marc-Andre Lemburg added the comment: On 11.09.2014 01:04, Nick Coghlan wrote: > > Nick Coghlan added the comment: > > Just as a recap of at least some of the *current* ways to do a bytes -> hex conversion: > >>>> import codecs >>>> codecs.encode(b"abc", "hex") > b'616263' >>>> import binascii >>>> binascii.hexlify(b"abc") > b'616263' >>>> import base64 >>>> base64.b16encode(b"abc") > b'616263' >>>> hex(int.from_bytes(b"abc", "big")) > '0x616263' >>>> hex(int.from_bytes(b"abc", "little")) > '0x636261' > > Thus, the underlying purpose of this proposal is to provide a single "more obvious way to do it". As per the recent discussion on python-ideas, the point where that is most useful is in debugging output. > > However, rather than a new method on bytes/bytearray/memoryview for this, I instead suggest it would be appropriate to extend the default handling of the "x" and "X" format characters to accept arbitrary bytes-like objects. The processing of these characters would be as follows: > > "x": display a-f as lowercase digits > "X": display A-F as uppercase digits > "#": includes 0x prefix > ".precision": chunks output, placing a space after every bytes > ",": uses a comma as the separator, rather than a space Hmm, but those would then work for str.format() as well, right ? Since "x" and "X" are already used to convert numbers to hex representation, opening these up for bytes sounds like it could easily mask TypeErrors for cases where you really want an integer to be formatted as hex and not bytes. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 10:02:57 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 11 Sep 2014 08:02:57 +0000 Subject: [issue22379] Empty exception message of str.join In-Reply-To: <1410317691.24.0.990266868285.issue22379@psf.upfronthosting.co.za> Message-ID: <1410422577.52.0.193428564487.issue22379@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 10:04:31 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 11 Sep 2014 08:04:31 +0000 Subject: [issue21951] tcl test change crashes AIX In-Reply-To: <1405013926.74.0.877232363604.issue21951@psf.upfronthosting.co.za> Message-ID: <3htt0t0knmz7Lk0@mail.python.org> Roundup Robot added the comment: New changeset ee969a717cb5 by Serhiy Storchaka in branch '2.7': Issue #21951: Use attemptckalloc() instead of ckalloc() in Tkinter. http://hg.python.org/cpython/rev/ee969a717cb5 New changeset 1223c882253f by Serhiy Storchaka in branch '3.4': Issue #21951: Use attemptckalloc() instead of ckalloc() in Tkinter. http://hg.python.org/cpython/rev/1223c882253f New changeset 499b60b7d067 by Serhiy Storchaka in branch 'default': Issue #21951: Use attemptckalloc() instead of ckalloc() in Tkinter. http://hg.python.org/cpython/rev/499b60b7d067 New changeset d6c7ab5a2065 by Serhiy Storchaka in branch '2.7': Issue #21951: Fixed a crash in Tkinter on AIX when called Tcl command with http://hg.python.org/cpython/rev/d6c7ab5a2065 New changeset 6a96c28f9474 by Serhiy Storchaka in branch '3.4': Issue #21951: Fixed a crash in Tkinter on AIX when called Tcl command with http://hg.python.org/cpython/rev/6a96c28f9474 New changeset 7b7bae546959 by Serhiy Storchaka in branch 'default': Issue #21951: Fixed a crash in Tkinter on AIX when called Tcl command with http://hg.python.org/cpython/rev/7b7bae546959 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 10:15:45 2014 From: report at bugs.python.org (Antony Lee) Date: Thu, 11 Sep 2014 08:15:45 +0000 Subject: [issue22387] Making tempfile.NamedTemporaryFile a class Message-ID: <1410423345.31.0.535332998594.issue22387@psf.upfronthosting.co.za> New submission from Antony Lee: Currently, tempfile.TemporaryFile and tempfile.NamedTemporaryFile are functions, not classes, despite what their names suggest, preventing subclassing. It would arguably be not so easy to make TemporaryFile a class, as its return value is whatever "_io.open" returns, which can be of various types, but NamedTemporaryFile can trivially converted into a class by reusing the body of _TemporaryFileWrapper (which is not used elsewhere). ---------- components: Library (Lib) messages: 226752 nosy: Antony.Lee priority: normal severity: normal status: open title: Making tempfile.NamedTemporaryFile a class versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 10:19:47 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 11 Sep 2014 08:19:47 +0000 Subject: [issue22336] _tkinter should use Python PyMem_Malloc() instead of Tcl ckalloc() In-Reply-To: <1409845570.99.0.729089959618.issue22336@psf.upfronthosting.co.za> Message-ID: <1410423587.73.0.240629520521.issue22336@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is updated patch which is synchronized with the tip after changes made in issue21951 and addresses my comments. ---------- Added file: http://bugs.python.org/file36596/tkinter_pymem_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 10:24:27 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 11 Sep 2014 08:24:27 +0000 Subject: [issue21951] tcl test change crashes AIX In-Reply-To: <1405013926.74.0.877232363604.issue21951@psf.upfronthosting.co.za> Message-ID: <1410423867.06.0.716806069416.issue21951@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Committed these two changes as separate patches. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 10:32:00 2014 From: report at bugs.python.org (Martin Panter) Date: Thu, 11 Sep 2014 08:32:00 +0000 Subject: [issue21228] Missing enumeration of HTTPResponse Objects methods of urllib.request.urlopen's http.client.HTTPResponse? In-Reply-To: <1397520483.48.0.224250148615.issue21228@psf.upfronthosting.co.za> Message-ID: <1410424320.33.0.320401704547.issue21228@psf.upfronthosting.co.za> Martin Panter added the comment: Fair enough, challenge accepted! Here is my attempt. I have explicitly made the info(), geturl() and getcode() methods available for all cases, and used Evens?s wording for the modified ?msg? attribute, but dropped mentioning the ?url? attribute. ---------- Added file: http://bugs.python.org/file36597/addinfourl-first.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 10:35:46 2014 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 11 Sep 2014 08:35:46 +0000 Subject: [issue22387] Making tempfile.NamedTemporaryFile a class In-Reply-To: <1410423345.31.0.535332998594.issue22387@psf.upfronthosting.co.za> Message-ID: <1410424546.7.0.186260788131.issue22387@psf.upfronthosting.co.za> Eric V. Smith added the comment: Can you explain why you want to subclass them? ---------- nosy: +eric.smith type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 11:23:10 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 11 Sep 2014 09:23:10 +0000 Subject: [issue13968] Support recursive globs In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za> Message-ID: <3htvld5DQ0z7LjS@mail.python.org> Roundup Robot added the comment: New changeset ff4b9d654691 by Serhiy Storchaka in branch 'default': Issue #13968: The glob module now supports recursive search in http://hg.python.org/cpython/rev/ff4b9d654691 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 11:24:08 2014 From: report at bugs.python.org (Antony Lee) Date: Thu, 11 Sep 2014 09:24:08 +0000 Subject: [issue22387] Making tempfile.NamedTemporaryFile a class In-Reply-To: <1410423345.31.0.535332998594.issue22387@psf.upfronthosting.co.za> Message-ID: <1410427448.25.0.907760158618.issue22387@psf.upfronthosting.co.za> Antony Lee added the comment: The initial idea was to solve #14243 (NamedTemporaryFile would be more useful on Windows if you could close it without deleting) by adding a "closed" keyword argument to the constructor of a subclass, that would set "delete" to False and then close it, e.g. class NTF(NamedTemporaryFile): def __init__(self, *args, closed=False, **kwargs): if closed: kwargs["delete"] = True super().__init__(*args, **kwargs) if closed: self.close() Actually, there are some not-so-nice interactions with the context-manager protocol though, as the file cannot be reopened. So it's not clear that this is such a good idea. Still, it somewhat confusing that a CamelCase object is not actually a type (especially when TemporaryDirectory is one). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 11:25:10 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 11 Sep 2014 09:25:10 +0000 Subject: [issue13968] Support recursive globs In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za> Message-ID: <1410427510.65.0.538226335372.issue13968@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your review Nick. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 11:44:58 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 11 Sep 2014 09:44:58 +0000 Subject: [issue22385] Allow 'x' and 'X' to accept bytes-like objects in string formatting In-Reply-To: <1410393301.25.0.193851592698.issue22385@psf.upfronthosting.co.za> Message-ID: <1410428698.37.0.333171246391.issue22385@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 12:33:39 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 11 Sep 2014 10:33:39 +0000 Subject: [issue21147] sqlite3 doesn't complain if the request contains a null character In-Reply-To: <1396544845.43.0.82545828662.issue21147@psf.upfronthosting.co.za> Message-ID: <3htxJy3rBQz7LjY@mail.python.org> Roundup Robot added the comment: New changeset 430865e9ea9f by Serhiy Storchaka in branch '2.7': Issue #21147: sqlite3 now raises an exception if the request contains a null http://hg.python.org/cpython/rev/430865e9ea9f New changeset 517f216d45ea by Serhiy Storchaka in branch '3.4': Issue #21147: sqlite3 now raises an exception if the request contains a null http://hg.python.org/cpython/rev/517f216d45ea New changeset b81f5652c2d7 by Serhiy Storchaka in branch 'default': Issue #21147: sqlite3 now raises an exception if the request contains a null http://hg.python.org/cpython/rev/b81f5652c2d7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 12:58:11 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 11 Sep 2014 10:58:11 +0000 Subject: [issue13968] Support recursive globs In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za> Message-ID: <1410433090.99.0.692925503876.issue13968@psf.upfronthosting.co.za> STINNER Victor added the comment: The test failed on a buildbot, I reopen the issue. http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/10607/steps/test/logs/stdio ====================================================================== FAIL: test_selflink (test.test_glob.SymlinkLoopGlobTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_glob.py", line 284, in test_selflink self.assertIn(path, results) AssertionError: '@test_23056_tmp_dir/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/file' not found in {'noodly2', '@test_23056_tmp-\udcff.py', '__pycache__'} ---------- nosy: +haypo resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 13:05:11 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 11 Sep 2014 11:05:11 +0000 Subject: [issue21951] tcl test change crashes AIX In-Reply-To: <1405013926.74.0.877232363604.issue21951@psf.upfronthosting.co.za> Message-ID: <1410433511.82.0.263205938387.issue21951@psf.upfronthosting.co.za> STINNER Victor added the comment: > Committed these two changes as separate patches. Thanks, it's clearer like that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 13:07:28 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 11 Sep 2014 11:07:28 +0000 Subject: [issue21951] tcl test change crashes AIX In-Reply-To: <1405013926.74.0.877232363604.issue21951@psf.upfronthosting.co.za> Message-ID: <1410433648.55.0.40549102891.issue21951@psf.upfronthosting.co.za> STINNER Victor added the comment: test_tcl now pass on AIX: http://buildbot.python.org/all/builders/PPC64%20AIX%203.x/builds/2592/steps/test/logs/stdio Thanks Serhiy for the fix. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 13:18:09 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 11 Sep 2014 11:18:09 +0000 Subject: [issue22336] _tkinter should use Python PyMem_Malloc() instead of Tcl ckalloc() In-Reply-To: <1409845570.99.0.729089959618.issue22336@psf.upfronthosting.co.za> Message-ID: <1410434289.32.0.896963264251.issue22336@psf.upfronthosting.co.za> STINNER Victor added the comment: I read tkinter_pymem_2.patch. Remaining calls to ckalloc(): * they are only used to allocate events passed later to Tcl_ThreadQueueEvent(). Tcl_ThreadQueueEvent doc explicitly says that the memory must be allocated by Tcl_Alloc or ckalloc, so it's correct (PyMem cannot be used). Remaining calls to ckfree(): * Tkapp_SplitList() calls ckfree() on memory allocated by Tcl_SplitList(), it's correct. * Tkapp_CallDeallocArgs() ckfree() on memory allocated by PyMem_Malloc() => wrong (see my review on Rietveld). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 13:35:34 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 11 Sep 2014 11:35:34 +0000 Subject: [issue21951] tcl test change crashes AIX In-Reply-To: <1410433648.55.0.40549102891.issue21951@psf.upfronthosting.co.za> Message-ID: <41485816.0b0Z03xVAU@raxxla> Serhiy Storchaka added the comment: Thank you Victor for great investigation of this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 14:19:39 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 11 Sep 2014 12:19:39 +0000 Subject: [issue22387] Making tempfile.NamedTemporaryFile a class In-Reply-To: <1410423345.31.0.535332998594.issue22387@psf.upfronthosting.co.za> Message-ID: <1410437979.22.0.726599206925.issue22387@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: You can do this with a function too: def NTF(*args, closed=False, **kwargs): if closed: kwargs["delete"] = True ntf = NamedTemporaryFile(*args, **kwargs) if closed: ntf.close() return ntf ---------- nosy: +georg.brandl, ncoghlan, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 14:31:16 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 11 Sep 2014 12:31:16 +0000 Subject: [issue22388] Unify style of "Contributed by" notes Message-ID: <1410438675.22.0.0998241704025.issue22388@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Here is a patch which converts "Contributed by" notes in whatsnews to most prevalent style. This means: * Previous sentence ends by a period and the "Contributed" is titled. * The note ends by a period and it is placed before closing parent. * The note is separated from previous sentence by two spaces or newline (as any sentences). Overwhelming majority of "Contributed by" notes are written in this style (except of unfinished 3.5 whatsnews). ---------- assignee: docs at python components: Documentation files: doc_contributed_by_style.patch keywords: patch messages: 226767 nosy: docs at python, r.david.murray, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Unify style of "Contributed by" notes type: enhancement versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file36598/doc_contributed_by_style.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 14:34:47 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 11 Sep 2014 12:34:47 +0000 Subject: [issue13968] Support recursive globs In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za> Message-ID: <3hv00k71hRz7Ljl@mail.python.org> Roundup Robot added the comment: New changeset 180f5bf7d1b9 by Serhiy Storchaka in branch 'default': Issue #13968: Fixed newly added recursive glob test. http://hg.python.org/cpython/rev/180f5bf7d1b9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 14:41:54 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 11 Sep 2014 12:41:54 +0000 Subject: [issue13968] Support recursive globs In-Reply-To: <1410433090.99.0.692925503876.issue13968@psf.upfronthosting.co.za> Message-ID: <1831789.djKdTLeFMd@raxxla> Serhiy Storchaka added the comment: Thank you Victor. The test was failed also when run it directly, omitting the test.regrtest module (which run a test inside temporary directory): ./python Lib/test/test_glob.py Now it is fixed. However perhaps we should consider as a bug if a test ran by regrtest doesn't clean created files or directories ('noodly2', '@test_23056_tmp-\udcff.py', and '__pycache__' are created by some previous tests). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 14:45:24 2014 From: report at bugs.python.org (=?utf-8?q?Evens_Fortun=C3=A9?=) Date: Thu, 11 Sep 2014 12:45:24 +0000 Subject: [issue21228] Missing enumeration of HTTPResponse Objects methods of urllib.request.urlopen's http.client.HTTPResponse? In-Reply-To: <1397520483.48.0.224250148615.issue21228@psf.upfronthosting.co.za> Message-ID: <1410439524.54.0.688753929296.issue21228@psf.upfronthosting.co.za> Evens Fortun? added the comment: I'm satisfied with this new patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 14:51:12 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 11 Sep 2014 12:51:12 +0000 Subject: [issue22336] _tkinter should use Python PyMem_Malloc() instead of Tcl ckalloc() In-Reply-To: <1410434289.32.0.896963264251.issue22336@psf.upfronthosting.co.za> Message-ID: <1748019.sY9dkH3MFg@raxxla> Serhiy Storchaka added the comment: > * Tkapp_CallDeallocArgs() ckfree() on memory allocated by PyMem_Malloc() => > wrong Oh, you are right, thanks. > (see my review on Rietveld). Perhaps you forgot to press the "Publish" button. ---------- Added file: http://bugs.python.org/file36599/tkinter_pymem_3.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 180f5bf7d1b9 Modules/_tkinter.c --- a/Modules/_tkinter.c Thu Sep 11 14:33:02 2014 +0300 +++ b/Modules/_tkinter.c Thu Sep 11 15:49:49 2014 +0300 @@ -605,7 +605,7 @@ Tcl_SetVar(v->interp, "tcl_interactive", "0", TCL_GLOBAL_ONLY); /* This is used to get the application class for Tk 4.1 and up */ - argv0 = (char*)attemptckalloc(strlen(className) + 1); + argv0 = (char*)PyMem_Malloc(strlen(className) + 1); if (!argv0) { PyErr_NoMemory(); Py_DECREF(v); @@ -616,7 +616,7 @@ if (Py_ISUPPER(Py_CHARMASK(argv0[0]))) argv0[0] = Py_TOLOWER(Py_CHARMASK(argv0[0])); Tcl_SetVar(v->interp, "argv0", argv0, TCL_GLOBAL_ONLY); - ckfree(argv0); + PyMem_Free(argv0); if (! wantTk) { Tcl_SetVar(v->interp, @@ -639,7 +639,7 @@ if (use) len += strlen(use) + sizeof "-use "; - args = (char*)attemptckalloc(len); + args = (char*)PyMem_Malloc(len); if (!args) { PyErr_NoMemory(); Py_DECREF(v); @@ -657,7 +657,7 @@ } Tcl_SetVar(v->interp, "argv", args, TCL_GLOBAL_ONLY); - ckfree(args); + PyMem_Free(args); } if (Tcl_AppInit(v->interp) != TCL_OK) { @@ -914,15 +914,15 @@ "list is too long"); return NULL; } - argv = (Tcl_Obj **) attemptckalloc(((size_t)size) * sizeof(Tcl_Obj *)); - if(!argv) { + argv = (Tcl_Obj **) PyMem_Malloc(((size_t)size) * sizeof(Tcl_Obj *)); + if (!argv) { PyErr_NoMemory(); return NULL; } for (i = 0; i < size; i++) argv[i] = AsObj(PySequence_Fast_GET_ITEM(value,i)); result = Tcl_NewListObj(size, argv); - ckfree(FREECAST argv); + PyMem_Free(argv); return result; } else if (PyUnicode_Check(value)) { @@ -948,7 +948,7 @@ if (kind == sizeof(Tcl_UniChar)) return Tcl_NewUnicodeObj(inbuf, size); allocsize = ((size_t)size) * sizeof(Tcl_UniChar); - outbuf = (Tcl_UniChar*)attemptckalloc(allocsize); + outbuf = (Tcl_UniChar*)PyMem_Malloc(allocsize); /* Else overflow occurred, and we take the next exit */ if (!outbuf) { PyErr_NoMemory(); @@ -965,14 +965,14 @@ "character U+%x is above the range " "(U+0000-U+FFFF) allowed by Tcl", ch); - ckfree(FREECAST outbuf); + PyMem_Free(outbuf); return NULL; } #endif outbuf[i] = ch; } result = Tcl_NewUnicodeObj(outbuf, size); - ckfree(FREECAST outbuf); + PyMem_Free(outbuf); return result; } else if(PyTclObject_Check(value)) { @@ -1084,7 +1084,7 @@ for (i = 0; i < objc; i++) Tcl_DecrRefCount(objv[i]); if (objv != objStore) - ckfree(FREECAST objv); + PyMem_Free(objv); } /* Convert Python objects to Tcl objects. This must happen in the @@ -1115,7 +1115,7 @@ "list is too long"); return NULL; } - objv = (Tcl_Obj **)attemptckalloc(((size_t)objc) * sizeof(Tcl_Obj *)); + objv = (Tcl_Obj **)PyMem_Malloc(((size_t)objc) * sizeof(Tcl_Obj *)); if (objv == NULL) { PyErr_NoMemory(); objc = 0; From report at bugs.python.org Thu Sep 11 15:13:10 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 11 Sep 2014 13:13:10 +0000 Subject: [issue22384] Tk.report_callback_exception kills process when run with pythonw.exe In-Reply-To: <1410380074.61.0.464879354999.issue22384@psf.upfronthosting.co.za> Message-ID: <1410441190.42.0.966290085766.issue22384@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: May be this patch would help. ---------- assignee: -> serhiy.storchaka keywords: +patch nosy: +serhiy.storchaka stage: -> patch review type: crash -> behavior versions: +Python 2.7, Python 3.5 Added file: http://bugs.python.org/file36600/tkinter_report_callback_exception.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 15:15:32 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 11 Sep 2014 13:15:32 +0000 Subject: [issue21199] Python on 64-bit Windows uses signed 32-bit type for read length In-Reply-To: <1397149133.44.0.946556558932.issue21199@psf.upfronthosting.co.za> Message-ID: <1410441332.41.0.425891615975.issue21199@psf.upfronthosting.co.za> Larry Hastings added the comment: Ping? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 16:25:13 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 11 Sep 2014 14:25:13 +0000 Subject: [issue22389] Generalize contextlib.redirect_stdout Message-ID: <1410445513.66.0.871890162607.issue22389@psf.upfronthosting.co.za> New submission from Barry A. Warsaw: redirect_stdout is almost exactly what I want, except I want to redirect stderr! redirect_stdout.__init__() should take a 'stream_name' argument (possibly keyword-only) which could be set to 'stderr'. I propose it's implemented as setattr(sys, stream_name, new_target) ---------- components: Library (Lib) messages: 226774 nosy: barry priority: normal severity: normal status: open title: Generalize contextlib.redirect_stdout versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 16:25:52 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 11 Sep 2014 14:25:52 +0000 Subject: [issue22389] Generalize contextlib.redirect_stdout In-Reply-To: <1410445513.66.0.871890162607.issue22389@psf.upfronthosting.co.za> Message-ID: <1410445552.68.0.23873846157.issue22389@psf.upfronthosting.co.za> STINNER Victor added the comment: Why not adding a new redirect_stderr() function? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 16:28:52 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 11 Sep 2014 14:28:52 +0000 Subject: [issue22389] Generalize contextlib.redirect_stdout In-Reply-To: <1410445552.68.0.23873846157.issue22389@psf.upfronthosting.co.za> Message-ID: <20140911102841.0f94a84a@anarchist.wooz.org> Barry A. Warsaw added the comment: On Sep 11, 2014, at 02:25 PM, STINNER Victor wrote: >Why not adding a new redirect_stderr() function? With a little refactoring redirect_stdout into a subclass, that would work too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 16:30:52 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 11 Sep 2014 14:30:52 +0000 Subject: [issue22390] test.regrtest should complain if a test doesn't remove temporary files Message-ID: <1410445852.03.0.724241204359.issue22390@psf.upfronthosting.co.za> New submission from STINNER Victor: A change in test_glob of issue #13968 started to fail because a previous test created temporary files but didn't remove them. test.regrtest should at least emit a warning if the temporary directory used to run tests is not empty before removing it. ---------- components: Tests messages: 226777 nosy: haypo, serhiy.storchaka priority: normal severity: normal status: open title: test.regrtest should complain if a test doesn't remove temporary files versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 16:31:20 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 11 Sep 2014 14:31:20 +0000 Subject: [issue13968] Support recursive globs In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za> Message-ID: <1410445880.51.0.479995078426.issue13968@psf.upfronthosting.co.za> STINNER Victor added the comment: > However perhaps we should consider as a bug if a test ran by regrtest doesn't clean created files or directories => yes, I opened the issue #22390. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 16:32:00 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 11 Sep 2014 14:32:00 +0000 Subject: [issue22336] _tkinter should use Python PyMem_Malloc() instead of Tcl ckalloc() In-Reply-To: <1409845570.99.0.729089959618.issue22336@psf.upfronthosting.co.za> Message-ID: <1410445920.05.0.829924441421.issue22336@psf.upfronthosting.co.za> STINNER Victor added the comment: tkinter_pymem_3.patch looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 16:43:46 2014 From: report at bugs.python.org (william tonkin) Date: Thu, 11 Sep 2014 14:43:46 +0000 Subject: [issue22382] sqlite3 connection built from apsw connection should raise IntegrityError, not DatabaseError In-Reply-To: <1410373815.55.0.143596528672.issue22382@psf.upfronthosting.co.za> Message-ID: <1410446626.8.0.129409732855.issue22382@psf.upfronthosting.co.za> william tonkin added the comment: sqlite3 allows a connection to be built from an apsw.Connection(). Using an apsw.Connection() to build an sqlite3.connect() implies that the underlying sqlite database engine will have extended error codes turned on (the default if for them to be turned off.) The problem is that Modules/_sqlite/util.c:_pysqlite_seterror() is not extended error code aware. In particular, the extended error code SQLITE_CONSTRAINT_CHECK will not be recognized as a kind of constraint violation and will fall into the "default:" arm of the case statement. This will result in raising the exception DatabaseError when the correct exception to raise is IntegrityError. One simple solution would be to convert the extended error code back to the base error code, that is: "errorcode = 0xffu % sqlite3_errcode(db);" ---------- status: closed -> open type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 16:48:15 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 11 Sep 2014 14:48:15 +0000 Subject: [issue21199] Python on 64-bit Windows uses signed 32-bit type for read length In-Reply-To: <1397149133.44.0.946556558932.issue21199@psf.upfronthosting.co.za> Message-ID: <1410446895.38.0.450173932166.issue21199@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I added comments to test on Rietveld. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 17:42:17 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 11 Sep 2014 15:42:17 +0000 Subject: [issue22336] _tkinter should use Python PyMem_Malloc() instead of Tcl ckalloc() In-Reply-To: <1410445920.05.0.829924441421.issue22336@psf.upfronthosting.co.za> Message-ID: <1414317.5MXQBiaDaS@raxxla> Serhiy Storchaka added the comment: And to me too. Please commit it, this is mainly your patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 17:49:10 2014 From: report at bugs.python.org (Antony Lee) Date: Thu, 11 Sep 2014 15:49:10 +0000 Subject: [issue22387] Making tempfile.NamedTemporaryFile a class In-Reply-To: <1410423345.31.0.535332998594.issue22387@psf.upfronthosting.co.za> Message-ID: <1410450550.72.0.0530206553715.issue22387@psf.upfronthosting.co.za> Antony Lee added the comment: Yes, but this will make the context-manager approach (with NamedTemporaryFile(closed=True): ) unusable, because the underlying file object will be closed before calling __enter__. I think the only reasonable way to implement this would be to have __enter__ return the file name (as for TemporaryDirectory), instead of the file object (which is reasonable because if I pass closed=True, it probably means all I care is that a file exists here for some other process to use!). But, with the function approach, I cannot override __enter__. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 17:52:36 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 11 Sep 2014 15:52:36 +0000 Subject: [issue22336] _tkinter should use Python PyMem_Malloc() instead of Tcl ckalloc() In-Reply-To: <1409845570.99.0.729089959618.issue22336@psf.upfronthosting.co.za> Message-ID: <3hv4Nz4BhHz7Ljc@mail.python.org> Roundup Robot added the comment: New changeset 9f1d3e6e6ce6 by Victor Stinner in branch 'default': Closes #22336: attemptckalloc() with PyMem_Malloc() in _tkinter http://hg.python.org/cpython/rev/9f1d3e6e6ce6 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 17:53:44 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 11 Sep 2014 15:53:44 +0000 Subject: [issue22336] _tkinter should use Python PyMem_Malloc() instead of Tcl ckalloc() In-Reply-To: <1409845570.99.0.729089959618.issue22336@psf.upfronthosting.co.za> Message-ID: <1410450824.4.0.435235200183.issue22336@psf.upfronthosting.co.za> STINNER Victor added the comment: > And to me too. Please commit it, this is mainly your patch. Ok, thanks, done. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 18:11:09 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 11 Sep 2014 16:11:09 +0000 Subject: [issue22390] test.regrtest should complain if a test doesn't remove temporary files In-Reply-To: <1410445852.03.0.724241204359.issue22390@psf.upfronthosting.co.za> Message-ID: <1410451869.49.0.628351800045.issue22390@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch. It warns if new files or directories are left after test run in current directory and removes those of them which starts with TESTFN (i.e. TESTFN_UNICODE, TESTFN + "2", TESTFN + ".py" and other names used in tests). ---------- keywords: +patch nosy: +ezio.melotti, michael.foord, pitrou stage: -> patch review type: -> enhancement versions: +Python 2.7, Python 3.4 Added file: http://bugs.python.org/file36601/regrtest_warn_lost_files.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 18:19:22 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 11 Sep 2014 16:19:22 +0000 Subject: [issue22390] test.regrtest should complain if a test doesn't remove temporary files In-Reply-To: <1410445852.03.0.724241204359.issue22390@psf.upfronthosting.co.za> Message-ID: <1410452362.09.0.950033884043.issue22390@psf.upfronthosting.co.za> STINNER Victor added the comment: I would prefer to fix tests instead of trying to remove arbitrary files. I'm not sure that "fn.startswith(support.TESTFN)" check is safe enough. Maybe we should not remove TESTFN neither. You are supposed to be able to run tests without regrtest. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 18:20:12 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 11 Sep 2014 16:20:12 +0000 Subject: [issue22390] test.regrtest should complain if a test doesn't remove temporary files In-Reply-To: <1410445852.03.0.724241204359.issue22390@psf.upfronthosting.co.za> Message-ID: <1410452412.25.0.434940833751.issue22390@psf.upfronthosting.co.za> STINNER Victor added the comment: I ran the test suite with the patch applied: 7 tests altered the execution environment: test_imp test_import test_pdb test_posix test_source_encoding test_support test_threaded_import I will try to investigate these warnings. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 18:53:29 2014 From: report at bugs.python.org (Kevin Phillips) Date: Thu, 11 Sep 2014 16:53:29 +0000 Subject: [issue22391] MSILIB truncates last character in summary information stream Message-ID: <1410454409.06.0.0184961474822.issue22391@psf.upfronthosting.co.za> New submission from Kevin Phillips: I recently exploited a subtle bug with the msilib module's GetProperty method on the SummaryInformation class. When retrieving string-typed properties from the stream the last character in the string gets truncated, replaced by a null-byte. I am using Python v3.2.5 64bit on Windows 7, and I've managed to reproduce the error with the following code snippet: filename = "sample.msp" patch_database = msilib.OpenDatabase(filename, msilib.MSIDBOPEN_READONLY | msilib.MSIDBOPEN_PATCHFILE) summary_info = patch_database.GetSummaryInformation(20) print (summary_info.GetProperty(msilib.PID_REVNUMBER)) The PID_REVNUMBER returns the patch-GUID for the Windows Installer patch file. In this example the GUID is returned properly however the character string is supposed to be delimited by curly braces - { }. Examination of the returned byte array shows that the leading curly brace is included by the final curly brace is not. Closer examination also shows that the last character in the byte array is \x00. While it is possible, in this situation, to circumvent the bug by simply removing the trailing bytes and replacing them with a closing curly brace, this may not be so easy to work around for general character strings if the last character in the sequence is not static. As such I'd highly recommend fixing this in the source for the msilib module. ---------- components: Library (Lib), Windows messages: 226789 nosy: Kevin.Phillips priority: normal severity: normal status: open title: MSILIB truncates last character in summary information stream type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 19:16:40 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 11 Sep 2014 17:16:40 +0000 Subject: [issue22364] Unify error messages of re and regex In-Reply-To: <1410278889.96.0.239905162.issue22364@psf.upfronthosting.co.za> Message-ID: <1559252.aknbLcFgp8@raxxla> Serhiy Storchaka added the comment: > By the way, which is preferred, "cannot" or "can't"? The regex module always > uses "can't", but re module uses "cannot" except for "TypeError: can't use > a bytes pattern on a string-like object", I think. It's interesting question. Grepping in CPython sources got results: Cannot 210 cannot 865 Can't 216 can't 796 Lowercase wins uppercase with score 4:1 and short and long forms are equivalent. I left the decision to English speakers. > Also, you said that one of the re module's messages was better, but didn't > say which! Did you mean this one? > > re: expected bytes, bytearray, or an object with the buffer interface, > > str found > > regex: expected bytes instance, str found Both are not good. re variant is too verbose, but it is more correct. May be 6, 7, 8, 10, 11, 16, 18 are better in re. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 19:21:51 2014 From: report at bugs.python.org (Kevin Phillips) Date: Thu, 11 Sep 2014 17:21:51 +0000 Subject: [issue22391] MSILIB truncates last character in summary information stream In-Reply-To: <1410454409.06.0.0184961474822.issue22391@psf.upfronthosting.co.za> Message-ID: <1410456111.57.0.455083373449.issue22391@psf.upfronthosting.co.za> Kevin Phillips added the comment: I should mention that I did discover some source code on GitHub, presumably for this wrapper module, and I believe I found a few questionable parts in the logic for this library that may help explain the cause of this problem: https://github.com/python-git/python/blob/master/PC/_msi.c Here are some snippets from the summary_getproperty function that may help: char sbuf[1000]; char *sval = sbuf; DWORD ssize = sizeof(sval); First, here, I believe the ssize value is not going to be initialized as one would expect at first glance. Since sval is a pointer and sizeof() returns the size of it's parameter, in this case a pointer, ssize will represent the pointer size on the target platform. In this case, on a 64bit OS, it's likely going to be set to 8, which I suspect the expected value for ssize is going to be 1000 - the size of the static array sbuff. status = MsiSummaryInfoGetProperty(si->h, field, &type, &ival, &fval, sval, &ssize); if (status == ERROR_MORE_DATA) { sval = malloc(ssize); status = MsiSummaryInfoGetProperty(si->h, field, &type, &ival, &fval, sval, &ssize); } Now, in this snippet it tries to load the string value from the file, and if the input buffer is not of sufficient size it reallocates the pointer to an appropriate size. Given the fact that ssize is probably initialized to 8 (or less) it is pretty safe to assume the first call to MsiSummaryInfoGetProperty changes this value to the length of the data stored in the file. Closer examination of the documentation for this Windows API function reveals that in this case ssize will be set to the number of characters required 'not including the terminating null character'. (http://msdn.microsoft.com/en-us/library/aa370409(v=vs.85).aspx) result = PyString_FromStringAndSize(sval, ssize); Then finally I noticed this function call. I suspect the problem may lie here. I'm not too familiar with the Python SDK but it sounds like when using Unicode strings - as all string are in Python 3 - you are supposed to use PyUnicode_FromStringAndSize instead. So perhaps there might be something getting lost in the translation, either via the use of this function or perhaps subsequent marshalling of the string object into the Python runtime, due to the encoding changes... not sure. It could be something as simple as one of the function calls used therein assume that the 'size' count includes a null-byte while others don't. It's hard to say without digging into the libs some more. I hope this helps. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 19:23:24 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 11 Sep 2014 17:23:24 +0000 Subject: [issue22390] test.regrtest should complain if a test doesn't remove temporary files In-Reply-To: <1410452362.09.0.950033884043.issue22390@psf.upfronthosting.co.za> Message-ID: <3476489.TiIOIQzxZa@raxxla> Serhiy Storchaka added the comment: > I would prefer to fix tests instead of trying to remove arbitrary files. I'm > not sure that "fn.startswith(support.TESTFN)" check is safe enough. This allow other tests which leaks the same file to be reported too. support.TESTFN contains process ID so it is unique enough. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 19:37:09 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 11 Sep 2014 17:37:09 +0000 Subject: [issue22390] test.regrtest should complain if a test doesn't remove temporary files In-Reply-To: <1410452412.25.0.434940833751.issue22390@psf.upfronthosting.co.za> Message-ID: <1648266.NazDK5CVBY@raxxla> Serhiy Storchaka added the comment: > I will try to investigate these warnings. Run tests with the -vv option. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 20:29:12 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 11 Sep 2014 18:29:12 +0000 Subject: [issue9205] Parent process hanging in multiprocessing if children terminate unexpectedly In-Reply-To: <1278619251.36.0.833806205056.issue9205@psf.upfronthosting.co.za> Message-ID: <1410460152.33.0.426821006809.issue9205@psf.upfronthosting.co.za> Antoine Pitrou added the comment: You should certainly create a new issue! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 20:30:50 2014 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 11 Sep 2014 18:30:50 +0000 Subject: [issue22391] MSILIB truncates last character in summary information stream In-Reply-To: <1410454409.06.0.0184961474822.issue22391@psf.upfronthosting.co.za> Message-ID: <1410460250.69.0.561194643115.issue22391@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: +steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 20:44:25 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 11 Sep 2014 18:44:25 +0000 Subject: [issue13968] Support recursive globs In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za> Message-ID: <1410461065.34.0.765879322927.issue13968@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 20:47:07 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 11 Sep 2014 18:47:07 +0000 Subject: [issue21147] sqlite3 doesn't complain if the request contains a null character In-Reply-To: <1396544845.43.0.82545828662.issue21147@psf.upfronthosting.co.za> Message-ID: <1410461227.12.0.806684173985.issue21147@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 20:51:36 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 11 Sep 2014 18:51:36 +0000 Subject: [issue22386] Python 3.4 logging.getLevelName() no longer maps string to level. In-Reply-To: <1410397798.62.0.061648555693.issue22386@psf.upfronthosting.co.za> Message-ID: <1410461496.33.0.737862462787.issue22386@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +larry priority: normal -> release blocker versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 20:52:32 2014 From: report at bugs.python.org (David Gilman) Date: Thu, 11 Sep 2014 18:52:32 +0000 Subject: [issue22392] Clarify documentation of __getinitargs__ Message-ID: <1410461552.96.0.589396040073.issue22392@psf.upfronthosting.co.za> New submission from David Gilman: Implementations of __getinitargs__ return a tuple of the positional arguments for __init__. This wasn't initially apparent to me after reading the docs: I thought you were passing a tuple (args, kwargs) that would get called f(*args, **kwargs) and had to go to the pickle implementation to find out what you were supposed to do. The proposed documentation enhancement: mention that you're just supposed to return a tuple of positional args and that it doesn't support kwargs. ---------- assignee: docs at python components: Documentation messages: 226795 nosy: David.Gilman, docs at python priority: normal severity: normal status: open title: Clarify documentation of __getinitargs__ type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 21:14:32 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 11 Sep 2014 19:14:32 +0000 Subject: [issue22299] resolve() on Windows makes some pathological paths unusable In-Reply-To: <1409318228.27.0.489471733533.issue22299@psf.upfronthosting.co.za> Message-ID: <1410462872.35.0.864959574012.issue22299@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Really, the test for whether to keep or remove the prefix should be to > remove the prefix and try and resolve the path again. If it succeeds, > remove the prefix; otherwise, keep it. This can only really be done as > part of the resolve() call, which would address the original issue, > but it may be quite a perf. hit. It would also be prone to race conditions. All in all it sounds like a bad idea. I still think it should be asked for explicitly. I don't know how the method should be called, .extended() perhaps? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 21:19:38 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 11 Sep 2014 19:19:38 +0000 Subject: [issue22359] Remove incorrect uses of recursive make In-Reply-To: <1410165869.76.0.203082844365.issue22359@psf.upfronthosting.co.za> Message-ID: <1410463178.83.0.552834842949.issue22359@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Martin, Matthias, do you think this would break any legitimate use? ---------- nosy: +loewis, pitrou stage: -> patch review type: compile error -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 21:20:11 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 11 Sep 2014 19:20:11 +0000 Subject: [issue22362] Warn about octal escapes > 0o377 in re In-Reply-To: <1410174440.93.0.911211496637.issue22362@psf.upfronthosting.co.za> Message-ID: <1410463211.46.0.537082190149.issue22362@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I think we should simply raise ValueError in 3.5. There's no reason to accept such invalid escapes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 21:50:24 2014 From: report at bugs.python.org (Steve Dower) Date: Thu, 11 Sep 2014 19:50:24 +0000 Subject: [issue22299] resolve() on Windows makes some pathological paths unusable In-Reply-To: <1409318228.27.0.489471733533.issue22299@psf.upfronthosting.co.za> Message-ID: <1410465024.42.0.124205844878.issue22299@psf.upfronthosting.co.za> Steve Dower added the comment: Another alternative is to always leave the prefix there after calling resolve() (as opposed to the current behaviour which is to always remove it). If the Win32 API says that the path should include the prefix, then it should. There's no reliable way for a developer to decide that an arbitrary path should include the prefix other than by resolving it. I still like the idea of a format character to omit the prefix, as that correctly implies that the only reason you should remove it is for displaying to the user. Alternatively, a ".without_prefix" property seems like a safer route than requiring the user to add it. Long paths are the only time you may want to add it, but even that doesn't guarantee that the path will work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 21:52:37 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 11 Sep 2014 19:52:37 +0000 Subject: [issue22391] MSILIB truncates last character in summary information stream In-Reply-To: <1410454409.06.0.0184961474822.issue22391@psf.upfronthosting.co.za> Message-ID: <1410465157.85.0.376815460977.issue22391@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 22:17:08 2014 From: report at bugs.python.org (william tonkin) Date: Thu, 11 Sep 2014 20:17:08 +0000 Subject: [issue22382] sqlite3 connection built from apsw connection should raise IntegrityError, not DatabaseError In-Reply-To: <1410373815.55.0.143596528672.issue22382@psf.upfronthosting.co.za> Message-ID: <1410466628.08.0.357925082724.issue22382@psf.upfronthosting.co.za> william tonkin added the comment: The following worked for me: --- util.c 2014-09-11 15:15:11.480266548 -0400 +++ util.c.fixed 2014-09-11 15:17:19.214878592 -0400 @@ -54,7 +54,7 @@ (void)sqlite3_reset(st); } - errorcode = sqlite3_errcode(db); + errorcode = 0xffu & sqlite3_errcode(db); switch (errorcode) { ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 22:34:36 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 11 Sep 2014 20:34:36 +0000 Subject: [issue22362] Warn about octal escapes > 0o377 in re In-Reply-To: <1410463211.46.0.537082190149.issue22362@psf.upfronthosting.co.za> Message-ID: <6472494.3V8FTKk85Z@raxxla> Serhiy Storchaka added the comment: Well, here is a patch which makes re raise an exception on suspicious octals. ---------- Added file: http://bugs.python.org/file36602/re_octal_escape_overflow_raise.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 180f5bf7d1b9 Lib/sre_parse.py --- a/Lib/sre_parse.py Thu Sep 11 14:33:02 2014 +0300 +++ b/Lib/sre_parse.py Thu Sep 11 23:31:31 2014 +0300 @@ -283,7 +283,11 @@ def _class_escape(source, escape): elif c in OCTDIGITS: # octal escape (up to three digits) escape += source.getwhile(2, OCTDIGITS) - return LITERAL, int(escape[1:], 8) & 0xff + c = int(escape[1:], 8) + if c > 0o377: + raise error('octal escape value %r outside of ' + 'range 0-0o377' % escape) + return LITERAL, c elif c in DIGITS: raise ValueError if len(escape) == 2: @@ -325,7 +329,7 @@ def _escape(source, escape, state): elif c == "0": # octal escape escape += source.getwhile(2, OCTDIGITS) - return LITERAL, int(escape[1:], 8) & 0xff + return LITERAL, int(escape[1:], 8) elif c in DIGITS: # octal escape *or* decimal group reference (sigh) if source.next in DIGITS: @@ -334,7 +338,11 @@ def _escape(source, escape, state): source.next in OCTDIGITS): # got three octal digits; this is an octal escape escape = escape + source.get() - return LITERAL, int(escape[1:], 8) & 0xff + c = int(escape[1:], 8) + if c > 0o377: + raise error('octal escape value %r outside of ' + 'range 0-0o377' % escape) + return LITERAL, c # not an octal escape, so this is a group reference group = int(escape[1:]) if group < state.groups: @@ -825,7 +833,11 @@ def parse_template(source, pattern): s.next in OCTDIGITS): this += sget() isoctal = True - lappend(chr(int(this[1:], 8) & 0xff)) + c = int(this[1:], 8) + if c > 0o377: + raise error('octal escape value %r outside of ' + 'range 0-0o377' % this) + lappend(chr(c)) if not isoctal: addgroup(int(this[1:])) else: diff -r 180f5bf7d1b9 Lib/test/test_re.py --- a/Lib/test/test_re.py Thu Sep 11 14:33:02 2014 +0300 +++ b/Lib/test/test_re.py Thu Sep 11 23:31:31 2014 +0300 @@ -154,8 +154,8 @@ class ReTests(unittest.TestCase): self.assertEqual(re.sub('x', r'\09', 'x'), '\0' + '9') self.assertEqual(re.sub('x', r'\0a', 'x'), '\0' + 'a') - self.assertEqual(re.sub('x', r'\400', 'x'), '\0') - self.assertEqual(re.sub('x', r'\777', 'x'), '\377') + self.assertRaises(re.error, re.sub, 'x', r'\400', 'x') + self.assertRaises(re.error, re.sub, 'x', r'\777', 'x') self.assertRaises(re.error, re.sub, 'x', r'\1', 'x') self.assertRaises(re.error, re.sub, 'x', r'\8', 'x') @@ -691,7 +691,7 @@ class ReTests(unittest.TestCase): self.assertIsNotNone(re.match(r"\08", "\0008")) self.assertIsNotNone(re.match(r"\01", "\001")) self.assertIsNotNone(re.match(r"\018", "\0018")) - self.assertIsNotNone(re.match(r"\567", chr(0o167))) + self.assertRaises(re.error, re.match, r"\567", "") self.assertRaises(re.error, re.match, r"\911", "") self.assertRaises(re.error, re.match, r"\x1", "") self.assertRaises(re.error, re.match, r"\x1z", "") @@ -719,6 +719,7 @@ class ReTests(unittest.TestCase): self.assertIsNotNone(re.match(r"[\U%08x]" % i, chr(i))) self.assertIsNotNone(re.match(r"[\U%08x0]" % i, chr(i)+"0")) self.assertIsNotNone(re.match(r"[\U%08xz]" % i, chr(i)+"z")) + self.assertRaises(re.error, re.match, r"[\567]", "") self.assertIsNotNone(re.match(r"[\U0001d49c-\U0001d4b5]", "\U0001d49e")) self.assertRaises(re.error, re.match, r"[\911]", "") self.assertRaises(re.error, re.match, r"[\x1z]", "") @@ -740,7 +741,7 @@ class ReTests(unittest.TestCase): self.assertIsNotNone(re.match(br"\08", b"\0008")) self.assertIsNotNone(re.match(br"\01", b"\001")) self.assertIsNotNone(re.match(br"\018", b"\0018")) - self.assertIsNotNone(re.match(br"\567", bytes([0o167]))) + self.assertRaises(re.error, re.match, br"\567", b"") self.assertRaises(re.error, re.match, br"\911", b"") self.assertRaises(re.error, re.match, br"\x1", b"") self.assertRaises(re.error, re.match, br"\x1z", b"") @@ -755,6 +756,7 @@ class ReTests(unittest.TestCase): self.assertIsNotNone(re.match((r"[\x%02x]" % i).encode(), bytes([i]))) self.assertIsNotNone(re.match((r"[\x%02x0]" % i).encode(), bytes([i]))) self.assertIsNotNone(re.match((r"[\x%02xz]" % i).encode(), bytes([i]))) + self.assertRaises(re.error, re.match, br"[\567]", b"") self.assertIsNotNone(re.match(br"[\u]", b'u')) self.assertIsNotNone(re.match(br"[\U]", b'U')) self.assertRaises(re.error, re.match, br"[\911]", "") From report at bugs.python.org Thu Sep 11 23:21:36 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 11 Sep 2014 21:21:36 +0000 Subject: [issue16662] load_tests not invoked in package/__init__.py In-Reply-To: <1410420216.67.0.792863018364.issue16662@psf.upfronthosting.co.za> Message-ID: <20140911172125.20138a74@anarchist.wooz.org> Barry A. Warsaw added the comment: On Sep 11, 2014, at 07:23 AM, STINNER Victor wrote: >The changeset d0ff527c53da5b925b61a8a70afc686ca6e05960 related to this issue >introduced a regression in test_unittest. The test now fails on >Windows. Darn. I don't have Windows handy to work out a fix. I'll try to get a VM running but wouldn't mind if someone beats me to it. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 11 23:32:43 2014 From: report at bugs.python.org (Michael Foord) Date: Thu, 11 Sep 2014 21:32:43 +0000 Subject: [issue21270] unittest.mock.call object has inherited count method In-Reply-To: <1397681359.44.0.204245756188.issue21270@psf.upfronthosting.co.za> Message-ID: <1410471163.76.0.263561281202.issue21270@psf.upfronthosting.co.za> Michael Foord added the comment: Thanks for this Kushal. It's not quite right though, count and index need to do the same as other attributes looked up with __getattr__. In fact delegating to __getattr__ is probably the easiest way of achieving that. (With the current patch the calls will be incorrect for call.foo.index() or similar I believe.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 00:09:00 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 11 Sep 2014 22:09:00 +0000 Subject: [issue22386] Python 3.4 logging.getLevelName() no longer maps string to level. In-Reply-To: <1410397798.62.0.061648555693.issue22386@psf.upfronthosting.co.za> Message-ID: <3hvDlJ0hV4z7LjQ@mail.python.org> Roundup Robot added the comment: New changeset a4c5effb8698 by Vinay Sajip in branch '3.4': Issue #22386: fixed regression. http://hg.python.org/cpython/rev/a4c5effb8698 New changeset 070fed5b7b9d by Vinay Sajip in branch 'default': Closes #22386: merged fix from 3.4. http://hg.python.org/cpython/rev/070fed5b7b9d ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 00:33:07 2014 From: report at bugs.python.org (Dan O'Reilly) Date: Thu, 11 Sep 2014 22:33:07 +0000 Subject: [issue22393] multiprocessing.Pool shouldn't hang forever if a worker process dies unexpectedly Message-ID: <1410474786.78.0.264797717105.issue22393@psf.upfronthosting.co.za> New submission from Dan O'Reilly: This is essentially a dupe of issue9205, but it was suggested I open a new issue, since that one ended up being used to fix this same problem in concurrent.futures, and was subsequently closed. Right now, should a worker process in a Pool unexpectedly get terminated while a blocking Pool method is running (e.g. apply, map), the method will hang forever. This isn't a normal occurrence, but it does occasionally happen (either because someone sends a SIGTERM, or because of a bug in the interpreter or a C-extension). It would be preferable for multiprocessing to follow the lead of concurrent.futures.ProcessPoolExecutor when this happens, and abort all running tasks and close down the Pool. Attached is a patch that implements this behavior. Should a process in a Pool unexpectedly exit (meaning, *not* because of hitting the maxtasksperchild limit), the Pool will be closed/terminated and all cached/running tasks will raise a BrokenProcessPool exception. These changes also prevent the Pool from going into a bad state if the "initializer" function raises an exception (previously, the pool would end up infinitely starting new processes, which would immediately die because of the exception). One concern with the patch: The way timings are altered with these changes, the Pool seems to be particularly susceptible to issue6721 in certain cases. If processes in the Pool are being restarted due to maxtasksperchild just as the worker is being closed or joined, there is a chance the worker will be forked while some of the debug logging inside of Pool is running (and holding locks on either sys.stdout or sys.stderr). When this happens, the worker deadlocks on startup, which will hang the whole program. I believe the current implementation is susceptible to this as well, but I could reproduce it much more consistently with this patch. I think its rare enough in practice that it shouldn't prevent the patch from being accepted, but thought I should point it out. (I do think issue6721 should be addressed, or at the very least internal I/O locks should always reset after forking.) ---------- components: Library (Lib) files: multiproc_broken_pool.diff keywords: patch messages: 226805 nosy: dan.oreilly, jnoller, pitrou, sbt priority: normal severity: normal status: open title: multiprocessing.Pool shouldn't hang forever if a worker process dies unexpectedly type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file36603/multiproc_broken_pool.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 00:34:12 2014 From: report at bugs.python.org (Dan O'Reilly) Date: Thu, 11 Sep 2014 22:34:12 +0000 Subject: [issue9205] Parent process hanging in multiprocessing if children terminate unexpectedly In-Reply-To: <1278619251.36.0.833806205056.issue9205@psf.upfronthosting.co.za> Message-ID: <1410474852.8.0.424301082966.issue9205@psf.upfronthosting.co.za> Dan O'Reilly added the comment: Thanks, Antoine. I've opened issue22393. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 06:30:45 2014 From: report at bugs.python.org (Donald Stufft) Date: Fri, 12 Sep 2014 04:30:45 +0000 Subject: [issue22224] docs.python.org is prone to political blocking in Russia In-Reply-To: <1408359444.49.0.206425741793.issue22224@psf.upfronthosting.co.za> Message-ID: <1410496245.87.0.82577225578.issue22224@psf.upfronthosting.co.za> Donald Stufft added the comment: Just to close the gap on this, most of the PSF web properties that go through Fastly have been switched over to a set of IP addresses that are dedicated to the PSF. So if someone does an IP ban they are blocking us. I just made the switch in DNS so it'll take hold as that propagates. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 08:58:33 2014 From: report at bugs.python.org (Yongzhi Pan) Date: Fri, 12 Sep 2014 06:58:33 +0000 Subject: [issue22379] Empty exception message of str.join In-Reply-To: <1410317691.24.0.990266868285.issue22379@psf.upfronthosting.co.za> Message-ID: <1410505113.97.0.525189821666.issue22379@psf.upfronthosting.co.za> Changes by Yongzhi Pan : ---------- versions: +Python 3.5 Added file: http://bugs.python.org/file36604/str_join_exception_message_1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 09:01:26 2014 From: report at bugs.python.org (Yongzhi Pan) Date: Fri, 12 Sep 2014 07:01:26 +0000 Subject: [issue22379] Empty exception message of str.join In-Reply-To: <1410317691.24.0.990266868285.issue22379@psf.upfronthosting.co.za> Message-ID: <1410505286.58.0.397277089927.issue22379@psf.upfronthosting.co.za> Yongzhi Pan added the comment: I updated the patches. Since exceptions in 3 do not have a message attribute, I did not check them. Are they OK? ---------- Added file: http://bugs.python.org/file36605/test_for_35.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 09:36:30 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 12 Sep 2014 07:36:30 +0000 Subject: [issue22362] Warn about octal escapes > 0o377 in re In-Reply-To: <1410174440.93.0.911211496637.issue22362@psf.upfronthosting.co.za> Message-ID: <1410507390.05.0.545596204151.issue22362@psf.upfronthosting.co.za> STINNER Victor added the comment: re_octal_escape_overflow_raise.patch: you should write a subfunction to not repeat the error message 3 times. + if c > 0o377: Hum, I never use octal. 255 instead of 0o377 would be less surprising :-p By the way, you should also check for negative numbers. >>> -3 & 0xff 253 Before, "& 0xff" also converted negative numbers to positive in range 0..255. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 09:38:34 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 12 Sep 2014 07:38:34 +0000 Subject: [issue22389] Generalize contextlib.redirect_stdout In-Reply-To: <1410445513.66.0.871890162607.issue22389@psf.upfronthosting.co.za> Message-ID: <1410507514.92.0.40864910508.issue22389@psf.upfronthosting.co.za> Raymond Hettinger added the comment: +1 on Victor's suggestion. I don't think hypergeneralizing it is the way to go. That adds too much complexity for too little benefit. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 09:38:51 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 12 Sep 2014 07:38:51 +0000 Subject: [issue22389] Generalize contextlib.redirect_stdout In-Reply-To: <1410445513.66.0.871890162607.issue22389@psf.upfronthosting.co.za> Message-ID: <1410507531.9.0.341349901768.issue22389@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> ncoghlan nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 09:41:11 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 12 Sep 2014 07:41:11 +0000 Subject: [issue22389] Generalize contextlib.redirect_stdout In-Reply-To: <1410445513.66.0.871890162607.issue22389@psf.upfronthosting.co.za> Message-ID: <1410507671.37.0.0118019312259.issue22389@psf.upfronthosting.co.za> STINNER Victor added the comment: redirect_stdout("stderr", stream) looks wrong to be: you want to redirect "stdout" or "stderr"? If you want to redirect something else (ex: stdin), you can still implement the very simple pattern: old_stdin = sys.stdin try: sys.stdin = mock_input ... finally: sys.stdin = old_stdin By the way, I'm not convinced that we should add redirect_stderr. @Barry: How many usage of this new functions do you see in the standard library? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 09:43:19 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 12 Sep 2014 07:43:19 +0000 Subject: [issue19232] Speed up _decimal import In-Reply-To: <1381579399.63.0.316110193187.issue19232@psf.upfronthosting.co.za> Message-ID: <1410507799.81.0.0825272989881.issue19232@psf.upfronthosting.co.za> STINNER Victor added the comment: "We could speed up the import further by not importing collections in _decimal. That could be done once structseq fully implements the namedtuple protocol (for DecimalTuple)." I suggest to close this issue. I guess that importing decimal is already fast enough, and enhance structseq is a completly different issue. (Is there an open issue, just to get the link?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 09:49:54 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 12 Sep 2014 07:49:54 +0000 Subject: [issue22348] Documentation of asyncio.StreamWriter.drain() In-Reply-To: <1410008027.32.0.320660376013.issue22348@psf.upfronthosting.co.za> Message-ID: <1410508194.15.0.711233821045.issue22348@psf.upfronthosting.co.za> STINNER Victor added the comment: IMO we should mention the write buffer limits ("high- and low-water limits for write flow control"). get_write_buffer_limits() and set_write_buffer_limits() methods of the transport are public, there is no reason to "hide" them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 10:07:05 2014 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 12 Sep 2014 08:07:05 +0000 Subject: [issue22389] Generalize contextlib.redirect_stdout In-Reply-To: <1410507671.37.0.0118019312259.issue22389@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: I'm fine with adding "redirect_stderr" - better to have the obvious counterpart, rather than hypergeneralising, or having to explain why it's missing. It's *currently* missing largely on a "wait for someone to ask" basis, and Barry asked. (Tangentially related, I should do a contextlib2 release at some point, but my previous CI provider shut down...) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 10:42:32 2014 From: report at bugs.python.org (Martin Richard) Date: Fri, 12 Sep 2014 08:42:32 +0000 Subject: [issue22348] Documentation of asyncio.StreamWriter.drain() In-Reply-To: <1410008027.32.0.320660376013.issue22348@psf.upfronthosting.co.za> Message-ID: <1410511352.45.0.74198475454.issue22348@psf.upfronthosting.co.za> Martin Richard added the comment: Here is an other patch which mentions high and low water limits. I think it's better to talk about it, since it tells extactly what a "full buffer" and "partially drained" means. On the other hand, StreamWriter wraps the transport but does not expose the set/get_write_buffer_limits() directly, you reach then through stream_writer.transport (which makes sense, StreamWriter is here to help writing, not to do plumbery) - so I did not mention the functions. ---------- Added file: http://bugs.python.org/file36606/asyncio-streams-drain-doc-water-limits.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 11:55:05 2014 From: report at bugs.python.org (Stefan Krah) Date: Fri, 12 Sep 2014 09:55:05 +0000 Subject: [issue19232] Speed up _decimal import In-Reply-To: <1381579399.63.0.316110193187.issue19232@psf.upfronthosting.co.za> Message-ID: <1410515705.24.0.558858741196.issue19232@psf.upfronthosting.co.za> Stefan Krah added the comment: I'm fine with closing this. The structseq issue is #1820. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 14:19:40 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 12 Sep 2014 12:19:40 +0000 Subject: [issue22378] SO_MARK support for Linux In-Reply-To: <1410313373.25.0.741471917751.issue22378@psf.upfronthosting.co.za> Message-ID: <1410524380.94.0.0697784200287.issue22378@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 14:25:33 2014 From: report at bugs.python.org (Ismail Donmez) Date: Fri, 12 Sep 2014 12:25:33 +0000 Subject: [issue20631] python readline module crashing on NULL access In-Reply-To: <1392423131.28.0.0178138253347.issue20631@psf.upfronthosting.co.za> Message-ID: <1410524733.05.0.879914613433.issue20631@psf.upfronthosting.co.za> Ismail Donmez added the comment: Can we please get a review on this? ---------- nosy: +cartman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 15:10:50 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 12 Sep 2014 13:10:50 +0000 Subject: [issue20631] python readline module crashing on NULL access In-Reply-To: <1392423131.28.0.0178138253347.issue20631@psf.upfronthosting.co.za> Message-ID: <1410527450.6.0.452390602958.issue20631@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 15:33:53 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 12 Sep 2014 13:33:53 +0000 Subject: [issue22379] Empty exception message of str.join In-Reply-To: <1410317691.24.0.990266868285.issue22379@psf.upfronthosting.co.za> Message-ID: <1410528833.05.0.664950307271.issue22379@psf.upfronthosting.co.za> R. David Murray added the comment: You can check .args[0] in python3. Can you include a complete patch for python3? Your test_for_35 only has a change for test_bytes, not the ones for string_tests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 15:50:54 2014 From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=) Date: Fri, 12 Sep 2014 13:50:54 +0000 Subject: [issue21356] Support LibreSSL (instead of OpenSSL): make RAND_egd optional In-Reply-To: <1398522096.15.0.100207892067.issue21356@psf.upfronthosting.co.za> Message-ID: <1410529854.55.0.133087413488.issue21356@psf.upfronthosting.co.za> Micha? G?rny added the comment: > In CPython, the _ssl module is compiled in C. How can we check if libssl provides RAND_egd() or not at compile time? How about... checking whether the function is provided? Unless I'm missing some major point, AC_CHECK_FUNC should be good enough. > Is there a way to check if libssl is OpenSSL or LibreSSL? Why would you want to do that? Do you want to make silly assumptions on API depending on provider name, and then add extra conditionals for versions? ---------- nosy: +mgorny _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 16:26:03 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 12 Sep 2014 14:26:03 +0000 Subject: [issue20334] make inspect Signature hashable In-Reply-To: <1390323024.99.0.45103178025.issue20334@psf.upfronthosting.co.za> Message-ID: <1410531963.06.0.551794882018.issue20334@psf.upfronthosting.co.za> Yury Selivanov added the comment: Antonie, I'm attaching a patch (issue20334-2.01.patch) to this issue which should fix the problem. Please review. ---------- Added file: http://bugs.python.org/file36607/issue20334-2.01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 16:37:26 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 12 Sep 2014 14:37:26 +0000 Subject: [issue22394] Update documentation building to use venv and pip Message-ID: <1410532646.93.0.821580086561.issue22394@psf.upfronthosting.co.za> New submission from Brett Cannon: Now that we have ensurepip, is there any reason to not have the Doc/ Makefile create a venv for building the docs instead of requiring people to install sphinx into either their global Python interpreter or some venv outside of their checkout? Basically it would be like going back to the old Makefile of checking out the code but instead do a better isolation job and let pip manage fetching everything, updating the projects, etc. ---------- assignee: docs at python components: Documentation messages: 226821 nosy: brett.cannon, docs at python priority: low severity: normal stage: needs patch status: open title: Update documentation building to use venv and pip type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 16:40:06 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 12 Sep 2014 14:40:06 +0000 Subject: [issue16104] Compileall script: add option to use multiple cores In-Reply-To: <1349124414.14.0.0730954283721.issue16104@psf.upfronthosting.co.za> Message-ID: <3hvfks3B95z7LjX@mail.python.org> Roundup Robot added the comment: New changeset 9efefcab817e by Brett Cannon in branch 'default': Issue #16104: Allow compileall to do parallel bytecode compilation. http://hg.python.org/cpython/rev/9efefcab817e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 16:40:30 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 12 Sep 2014 14:40:30 +0000 Subject: [issue16104] Compileall script: add option to use multiple cores In-Reply-To: <1349124414.14.0.0730954283721.issue16104@psf.upfronthosting.co.za> Message-ID: <1410532830.63.0.211640646446.issue16104@psf.upfronthosting.co.za> Brett Cannon added the comment: Thanks for the patch, Claudiu! ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 16:41:27 2014 From: report at bugs.python.org (Claudiu Popa) Date: Fri, 12 Sep 2014 14:41:27 +0000 Subject: [issue16104] Compileall script: add option to use multiple cores In-Reply-To: <1349124414.14.0.0730954283721.issue16104@psf.upfronthosting.co.za> Message-ID: <1410532887.04.0.526156082029.issue16104@psf.upfronthosting.co.za> Claudiu Popa added the comment: Thank you for committing it. :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 16:49:56 2014 From: report at bugs.python.org (Matthias Klose) Date: Fri, 12 Sep 2014 14:49:56 +0000 Subject: [issue22381] update zlib in 2.7 to 1.2.8 In-Reply-To: <1410341675.94.0.179025133528.issue22381@psf.upfronthosting.co.za> Message-ID: <1410533396.89.0.753249092966.issue22381@psf.upfronthosting.co.za> Changes by Matthias Klose : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 17:32:41 2014 From: report at bugs.python.org (Berker Peksag) Date: Fri, 12 Sep 2014 15:32:41 +0000 Subject: [issue22389] Generalize contextlib.redirect_stdout In-Reply-To: <1410445513.66.0.871890162607.issue22389@psf.upfronthosting.co.za> Message-ID: <1410535961.52.0.873829244848.issue22389@psf.upfronthosting.co.za> Berker Peksag added the comment: Here's a simple implementation. I will add tests and update the documentation. ---------- keywords: +patch nosy: +berker.peksag stage: -> patch review Added file: http://bugs.python.org/file36608/issue22389.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 18:29:26 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 12 Sep 2014 16:29:26 +0000 Subject: [issue22362] Warn about octal escapes > 0o377 in re In-Reply-To: <1410507390.05.0.545596204151.issue22362@psf.upfronthosting.co.za> Message-ID: <2741323.Nh2q9boxnG@raxxla> Serhiy Storchaka added the comment: > By the way, you should also check for negative numbers. Not in this case. You can't construct negative number from three octal digits. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 18:46:15 2014 From: report at bugs.python.org (kernc) Date: Fri, 12 Sep 2014 16:46:15 +0000 Subject: [issue22253] ConfigParser does not handle files without sections In-Reply-To: <1410236982.38.0.669278662648.issue22253@psf.upfronthosting.co.za> Message-ID: kernc added the comment: > > I am dubious that there are any with a mixture of both sections and > additional option lines at the top without a section. > rsyncd.conf [1] is one such example, and I wouldn't say there aren't countless more in the wild. > Anyone writing an app and planning to parse a .ini file can add [Start] or > [Setup] at the top. > Indeed. Here lies the problem of this unfortunate issue: MissingSectionHeaderError is only ever caught [9] to mitigate this **awful default behavior** and attach a dummy section at the top, as you say. Or can anyone care to propose another relevant use case for this poorly (un-) thought through exception? > I think a more useful new configparser feature would be to keep comment > lines and write them back out after a configuration is changed. > While this is very much off-topic, configobj [3] does too seem to have done so since ages. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 18:49:47 2014 From: report at bugs.python.org (Justin Foo) Date: Fri, 12 Sep 2014 16:49:47 +0000 Subject: [issue22395] test_pathlib error for complex symlinks on Windows Message-ID: <1410540587.88.0.335092451275.issue22395@psf.upfronthosting.co.za> New submission from Justin Foo: The _check_complex_symlinks function compares paths for string equality instead of using the assertSame helper function. Patch attached. ---------- components: Tests messages: 226828 nosy: jfoo priority: normal severity: normal status: open title: test_pathlib error for complex symlinks on Windows type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 18:53:01 2014 From: report at bugs.python.org (Justin Foo) Date: Fri, 12 Sep 2014 16:53:01 +0000 Subject: [issue22395] test_pathlib error for complex symlinks on Windows In-Reply-To: <1410540587.88.0.335092451275.issue22395@psf.upfronthosting.co.za> Message-ID: <1410540781.34.0.334731536572.issue22395@psf.upfronthosting.co.za> Justin Foo added the comment: The _check_complex_symlinks function compares stringified paths for string equality instead of using the assertSame helper method. Patch attached. ---------- keywords: +patch Added file: http://bugs.python.org/file36609/issue22395.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 18:54:24 2014 From: report at bugs.python.org (Chris Rebert) Date: Fri, 12 Sep 2014 16:54:24 +0000 Subject: [issue22356] mention explicitly that stdlib assumes gmtime(0) epoch is 1970 In-Reply-To: <1410110444.5.0.966357232963.issue22356@psf.upfronthosting.co.za> Message-ID: <1410540864.24.0.193196865631.issue22356@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 18:57:22 2014 From: report at bugs.python.org (Chris Rebert) Date: Fri, 12 Sep 2014 16:57:22 +0000 Subject: [issue22393] multiprocessing.Pool shouldn't hang forever if a worker process dies unexpectedly In-Reply-To: <1410474786.78.0.264797717105.issue22393@psf.upfronthosting.co.za> Message-ID: <1410541042.56.0.468390702088.issue22393@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 19:58:50 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 12 Sep 2014 17:58:50 +0000 Subject: [issue22379] Empty exception message of str.join In-Reply-To: <1410317691.24.0.990266868285.issue22379@psf.upfronthosting.co.za> Message-ID: <1410544730.43.0.594243409845.issue22379@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > You can check .args[0] in python3. Or str(cm.exception). This works on 2.7 too. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 20:01:42 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 12 Sep 2014 18:01:42 +0000 Subject: [issue22395] test_pathlib error for complex symlinks on Windows In-Reply-To: <1410540587.88.0.335092451275.issue22395@psf.upfronthosting.co.za> Message-ID: <1410544902.27.0.460783662459.issue22395@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 20:02:14 2014 From: report at bugs.python.org (Antony Lee) Date: Fri, 12 Sep 2014 18:02:14 +0000 Subject: [issue20334] make inspect Signature hashable In-Reply-To: <1390323024.99.0.45103178025.issue20334@psf.upfronthosting.co.za> Message-ID: <1410544934.58.0.224860870564.issue20334@psf.upfronthosting.co.za> Antony Lee added the comment: While your patch works, I think it is a good opportunity to simplify the implementation of Signature.__eq__, which is *much* more complicated than what it should be. Please comment on the attached patch, which uses the helper method approach I suggested. ---------- Added file: http://bugs.python.org/file36610/signature-hash-and-equality.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 20:05:57 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 12 Sep 2014 18:05:57 +0000 Subject: [issue21356] Support LibreSSL (instead of OpenSSL): make RAND_egd optional In-Reply-To: <1398522096.15.0.100207892067.issue21356@psf.upfronthosting.co.za> Message-ID: <1410545157.68.0.0210489025714.issue21356@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Unless I'm missing some major point, AC_CHECK_FUNC should be good enough. Building extension modules such as ssl doesn't involve autoconf. > Do you want to make silly assumptions on API depending on provider name, and then add extra conditionals for versions? Arguably it would be better if LibreSSL exposed the same API as OpenSSL. We're not responsible for the discrepancy here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 20:06:58 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 12 Sep 2014 18:06:58 +0000 Subject: [issue22395] test_pathlib error for complex symlinks on Windows In-Reply-To: <1410540587.88.0.335092451275.issue22395@psf.upfronthosting.co.za> Message-ID: <1410545218.63.0.690645617586.issue22395@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Can you explain in which case the assertion breaks? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 20:20:03 2014 From: report at bugs.python.org (David Edelsohn) Date: Fri, 12 Sep 2014 18:20:03 +0000 Subject: [issue22396] AIX posix_fadvise and posix_fallocate Message-ID: <1410546003.27.0.984640019214.issue22396@psf.upfronthosting.co.za> New submission from David Edelsohn: As with Solaris and Issue10812, test_posix fadvise and fallocate fail on AIX. Python is compiled with _LARGE_FILES, which changes the function signature for posix_fadvise and posix_fallocate so that off_t is "long long" on 32 bit system passed in two registers. The Python call to those functions does not place the arguments in the correct registers, causing an EINVAL error. This patch fixes the failures in a similar way to Solaris ZFS kludge for Issue10812. ---------- components: Tests files: 10812_aix.patch keywords: patch messages: 226834 nosy: David.Edelsohn, pitrou priority: normal severity: normal status: open title: AIX posix_fadvise and posix_fallocate type: behavior versions: Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file36611/10812_aix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 20:23:54 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 12 Sep 2014 18:23:54 +0000 Subject: [issue22253] ConfigParser does not handle files without sections In-Reply-To: <1408731768.17.0.221948826268.issue22253@psf.upfronthosting.co.za> Message-ID: <1410546234.81.0.8372073638.issue22253@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Microsoft Windows INI files, "POSIX-compatible config files", and other formats (e.g. Java properties files) use different methods for escaping, quoting, line continuing, interpolations, etc. Actually there are more differences than similarity between them. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 20:24:03 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 12 Sep 2014 18:24:03 +0000 Subject: [issue22396] AIX posix_fadvise and posix_fallocate In-Reply-To: <1410546003.27.0.984640019214.issue22396@psf.upfronthosting.co.za> Message-ID: <1410546243.07.0.670789802599.issue22396@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > The Python call to those functions does not place the arguments in the correct registers Well... isn't there a way to fix this? I don't understand how this issue can come up. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 20:44:13 2014 From: report at bugs.python.org (David Edelsohn) Date: Fri, 12 Sep 2014 18:44:13 +0000 Subject: [issue22397] test_socket failure on AIX Message-ID: <1410547453.79.0.287492326275.issue22397@psf.upfronthosting.co.za> New submission from David Edelsohn: AIX has the same test_socket problem with FDPassSeparate as Darwin in Issue12958 so skip some tests. ---------- components: Library (Lib) files: 12958_aix.patch keywords: patch messages: 226837 nosy: David.Edelsohn, pitrou priority: normal severity: normal status: open title: test_socket failure on AIX type: behavior versions: Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file36612/12958_aix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 20:44:59 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 12 Sep 2014 18:44:59 +0000 Subject: [issue22396] AIX posix_fadvise and posix_fallocate In-Reply-To: <1410546003.27.0.984640019214.issue22396@psf.upfronthosting.co.za> Message-ID: <1410547499.97.0.871570461436.issue22396@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See similar Ruby issue: https://bugs.ruby-lang.org/issues/9914 . As workaround we can redeclare posix_fadvise as "int posix_fadvise(int fd, long offset, long len, int advice)" on 32-bit AIX with enabled _LARGE_FILES. More safe option is to disable posix_fadvise in such case (as Ruby had done). ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 20:46:13 2014 From: report at bugs.python.org (Steve Dower) Date: Fri, 12 Sep 2014 18:46:13 +0000 Subject: [issue22398] Tools/msi enhancements for 2.7 Message-ID: <1410547573.26.0.0466053668999.issue22398@psf.upfronthosting.co.za> New submission from Steve Dower: This patch has some minor changes to the build scripts for Python 2.7 on Windows. They're fully tested on my build machine, but I wanted someone who's more familiar with how the buildbots are set up to either confirm that the Tools/msi scripts are not used or that the changes won't have an impact. The Tools/msi/msi.py changes to use environment variables are mostly to make my life easier. Apparently the old way was to actually modify the file before making an official release... The Tools/msi/msilib.py fix is necessary because of some new files that were added for 2.7.9. Technically it's a release blocker, though it won't actually hold anything up since I spotted it. ---------- assignee: steve.dower components: Installation, Windows files: Tool_msi_27.patch keywords: patch messages: 226839 nosy: pitrou, steve.dower, tim.golden, zach.ware priority: normal severity: normal stage: patch review status: open title: Tools/msi enhancements for 2.7 type: enhancement versions: Python 2.7 Added file: http://bugs.python.org/file36613/Tool_msi_27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 20:47:35 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 12 Sep 2014 18:47:35 +0000 Subject: [issue22397] test_socket failure on AIX In-Reply-To: <1410547453.79.0.287492326275.issue22397@psf.upfronthosting.co.za> Message-ID: <1410547655.03.0.63078661785.issue22397@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 21:48:11 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 12 Sep 2014 19:48:11 +0000 Subject: [issue20334] make inspect Signature hashable In-Reply-To: <1390323024.99.0.45103178025.issue20334@psf.upfronthosting.co.za> Message-ID: <3hvnZL4mgxz7Ljf@mail.python.org> Roundup Robot added the comment: New changeset 3b974b61e74d by Yury Selivanov in branch 'default': inspect.Signature: Fix discrepancy between __eq__ and __hash__. http://hg.python.org/cpython/rev/3b974b61e74d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 21:50:37 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 12 Sep 2014 19:50:37 +0000 Subject: [issue20334] make inspect Signature hashable In-Reply-To: <1390323024.99.0.45103178025.issue20334@psf.upfronthosting.co.za> Message-ID: <1410551437.51.0.583447682111.issue20334@psf.upfronthosting.co.za> Yury Selivanov added the comment: Antony, I've tweaked the patch a bit and it's now in default branch. Thank you! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 22:08:24 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 12 Sep 2014 20:08:24 +0000 Subject: [issue22343] Install bash activate script on Windows when using venv In-Reply-To: <1409948648.7.0.892236136888.issue22343@psf.upfronthosting.co.za> Message-ID: <1410552504.98.0.730557926626.issue22343@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- stage: -> test needed versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 22:10:34 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 12 Sep 2014 20:10:34 +0000 Subject: [issue22398] Tools/msi enhancements for 2.7 In-Reply-To: <1410547573.26.0.0466053668999.issue22398@psf.upfronthosting.co.za> Message-ID: <1410552634.76.0.247347543484.issue22398@psf.upfronthosting.co.za> Zachary Ware added the comment: Actually, I think the method Martin used was to create a local config.py in Tools/msi/, which provided the proper settings for the release. See http://hg.python.org/cpython/file/2.7/Tools/msi/msi.py#l37 Either way, the buildbots are completely unaffected by Tools/msi, and I don't think anything actually uses PCbuild/build_tkinter.py (unless you do :)), so since the script is now yours, I'd say you're clear to change as you like. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 22:11:50 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 12 Sep 2014 20:11:50 +0000 Subject: [issue22351] NNTP constructor exception leaves socket for garbage collector In-Reply-To: <1410062828.01.0.535616885323.issue22351@psf.upfronthosting.co.za> Message-ID: <1410552710.21.0.725393839086.issue22351@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 22:18:17 2014 From: report at bugs.python.org (Steve Dower) Date: Fri, 12 Sep 2014 20:18:17 +0000 Subject: [issue22398] Tools/msi enhancements for 2.7 In-Reply-To: <1410547573.26.0.0466053668999.issue22398@psf.upfronthosting.co.za> Message-ID: <1410553097.32.0.34102927934.issue22398@psf.upfronthosting.co.za> Steve Dower added the comment: Thanks for confirming. Somehow I never noticed the import config line - guess that's a pattern I'm not really used to seeing. Still, I prefer having the env variables there as I invoke the scripts through some batch files (very specific to my machine, unfortunately, but the 3.5 ones will be more generic). And since you mention it, apparently I'm not using build_tkinter.py any more either. I was at one point, hence the fix. I'll leave it in there - we can probably remove the file completely but no harm in leaving it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 22:19:00 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 12 Sep 2014 20:19:00 +0000 Subject: [issue22398] Tools/msi enhancements for 2.7 In-Reply-To: <1410547573.26.0.0466053668999.issue22398@psf.upfronthosting.co.za> Message-ID: <3hvpFv4s96z7Ljg@mail.python.org> Roundup Robot added the comment: New changeset 5c55a7bfec0c by Steve Dower in branch '2.7': #22398 Tools/msi enhancements for 2.7 http://hg.python.org/cpython/rev/5c55a7bfec0c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 22:19:18 2014 From: report at bugs.python.org (Steve Dower) Date: Fri, 12 Sep 2014 20:19:18 +0000 Subject: [issue22398] Tools/msi enhancements for 2.7 In-Reply-To: <1410547573.26.0.0466053668999.issue22398@psf.upfronthosting.co.za> Message-ID: <1410553158.95.0.508513200862.issue22398@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 22:27:49 2014 From: report at bugs.python.org (Philippe Dessauw) Date: Fri, 12 Sep 2014 20:27:49 +0000 Subject: [issue22399] Doc: missing anchor for dict in library/functions.html Message-ID: <1410553668.99.0.783608222954.issue22399@psf.upfronthosting.co.za> New submission from Philippe Dessauw: There is a missing anchor for the dict functions in the documentation at library/functions.html. It is present in the documentation of all python version. It seems to impact cross-referencing in Sphinx (using intersphinx). ---------- assignee: docs at python components: Documentation messages: 226845 nosy: docs at python, pdessauw priority: normal severity: normal status: open title: Doc: missing anchor for dict in library/functions.html type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 23:41:10 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 12 Sep 2014 21:41:10 +0000 Subject: [issue22354] Idle: highlite tabs In-Reply-To: <1410095822.07.0.751550923398.issue22354@psf.upfronthosting.co.za> Message-ID: <1410558070.79.0.313515775085.issue22354@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I agree that this is an issue, and I believe others have made similar comments or requests, but I cannot find an existing issue for this. By experiment, it is possible to tag a tab and change the background color for the spaces a tab is visually converted to. import tkinter as tk root = tk.Tk() text = tk.Text(root) text.pack() text.insert('insert', 'a\tb') text.tag_add('TAB', 1.1, 1.2) text.tag_config('TAB', background='#ffd') # light yellow, or text.tag_config('TAB', background='#eee') # light gray http://infohost.nmt.edu/tcc/help/pubs/tkinter/web/text-methods.html The other tag configuration options that refer to text, such as overstrike and underline, have no visual effect. Neither does non-zero borderwidth. I am reluctant to add visible characters. The need to delete them would complicate converting tabs to spaces and saving files. Since Idle normally converts tabs to spaces on input, they are not common in edited files. The main issue, as you mention, is code imported from elsewhere. Some issue remain. 1. Tagging tabs: I presume this is no problem, but will not know until there is a patch. 2. The priority of the TAB tag relative to others. The importance of this depends on the next question. 3. Should tab space in comments and strings be shaded? I think so. If so, should the shading match the comment/string foreground color? ---------- nosy: +terry.reedy stage: -> test needed title: Highlite tabs in the IDLE -> Idle: highlite tabs versions: -Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 23:47:43 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 12 Sep 2014 21:47:43 +0000 Subject: [issue22355] inconsistent results with inspect.getsource / .getsourcelines In-Reply-To: <1410101141.24.0.25482778458.issue22355@psf.upfronthosting.co.za> Message-ID: <1410558463.87.0.675541082126.issue22355@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- title: inconsistent results with inspect.getsource() / inspect.getsourcelines() -> inconsistent results with inspect.getsource / .getsourcelines versions: +Python 2.7, Python 3.4, Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 12 23:51:58 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 12 Sep 2014 21:51:58 +0000 Subject: [issue22360] Adding manually offset parameter to str/bytes split function In-Reply-To: <1410168542.37.0.66219638693.issue22360@psf.upfronthosting.co.za> Message-ID: <1410558718.46.0.926078622811.issue22360@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 13 00:07:15 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 12 Sep 2014 22:07:15 +0000 Subject: [issue22364] Unify error messages of re and regex In-Reply-To: <1410178976.27.0.421938794422.issue22364@psf.upfronthosting.co.za> Message-ID: <1410559635.13.0.68852885184.issue22364@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I prefer "cannot" for error messages. "Can't" is an informal version of "cannot", used in speech, dialog representing speech, and 'informal' writing. It looks wrong to me in this context. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 13 00:13:24 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 12 Sep 2014 22:13:24 +0000 Subject: [issue22375] urllib2.urlopen().read().splitlines() opening a directory in a FTP server randomly returns incorrect results In-Reply-To: <1410299405.34.0.167812211508.issue22375@psf.upfronthosting.co.za> Message-ID: <1410560004.81.0.12249034419.issue22375@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- resolution: -> duplicate stage: -> resolved superseder: -> urllib2.urlopen().read().splitlines() opening a directory in a FTP server randomly returns incorrect result _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 13 00:38:00 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 12 Sep 2014 22:38:00 +0000 Subject: [issue22376] urllib2.urlopen().read().splitlines() opening a directory in a FTP server randomly returns incorrect result In-Reply-To: <1410299620.11.0.341288273378.issue22376@psf.upfronthosting.co.za> Message-ID: <1410561480.5.0.044305443038.issue22376@psf.upfronthosting.co.za> Terry J. Reedy added the comment: You should have just added a new message to #22375 with the revision. #15002 ends with "This is fixed in 3.4 and 3.5. I will backport to 2.7 ( I think, it is worth it)." Please check whether the backport has been done or whether current you still have a problem with the latest 2.7.8. If so, did the 3.4 patch, included in 3.4.1, fix the issue (ie, install 3.4.1 and test). If you code works on 3.4.1 and not on 2.7.8, you could add a request for a backport to #15002. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 13 00:38:56 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 12 Sep 2014 22:38:56 +0000 Subject: [issue22378] SO_MARK support for Linux In-Reply-To: <1410313373.25.0.741471917751.issue22378@psf.upfronthosting.co.za> Message-ID: <1410561536.12.0.644056957168.issue22378@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- stage: -> test needed versions: +Python 3.5 -Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 13 00:44:05 2014 From: report at bugs.python.org (koobs) Date: Fri, 12 Sep 2014 22:44:05 +0000 Subject: [issue17120] Mishandled _POSIX_C_SOURCE and _XOPEN_SOURCE in pyconfig.h In-Reply-To: <1359956347.87.0.611737971795.issue17120@psf.upfronthosting.co.za> Message-ID: <1410561845.96.0.169119357186.issue17120@psf.upfronthosting.co.za> koobs added the comment: See also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192365 ---------- nosy: +koobs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 13 01:04:54 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 12 Sep 2014 23:04:54 +0000 Subject: [issue22388] Unify style of "Contributed by" notes In-Reply-To: <1410438675.22.0.0998241704025.issue22388@psf.upfronthosting.co.za> Message-ID: <1410563093.99.0.0752332288692.issue22388@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I agree with making a complete and separate sentence. There are 3 variations. -- Add parenthetical note after last sentence. (Contributed by me.) -- Add note on next line after short line. (Contributed by me. -- Add note after a blank line. (Contributed by me.) -- I guess version 2 will be formatted the same as version 1. In 3.4 What's New I only say one instance of the 3rd, blank line style, for the multi-paragraph Improvements to Codec Handling, which it arguable was appropriate. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 13 01:07:27 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 12 Sep 2014 23:07:27 +0000 Subject: [issue20537] logging exc_info parameter should accept exception instances In-Reply-To: <1391730788.17.0.188838717397.issue20537@psf.upfronthosting.co.za> Message-ID: <1410563247.32.0.195145629295.issue20537@psf.upfronthosting.co.za> Yury Selivanov added the comment: Vinay, Please take a look at the second patch -- 'logging_02.patch' -- with updated docs ---------- Added file: http://bugs.python.org/file36614/logging_02.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 13 01:10:33 2014 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Fri, 12 Sep 2014 23:10:33 +0000 Subject: [issue22394] Update documentation building to use venv and pip In-Reply-To: <1410532646.93.0.821580086561.issue22394@psf.upfronthosting.co.za> Message-ID: <1410563433.8.0.555031809674.issue22394@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 13 03:50:48 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 13 Sep 2014 01:50:48 +0000 Subject: [issue22351] NNTP constructor exception leaves socket for garbage collector In-Reply-To: <1410062828.01.0.535616885323.issue22351@psf.upfronthosting.co.za> Message-ID: <1410573048.59.0.0726338984788.issue22351@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- keywords: +easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 13 15:10:29 2014 From: report at bugs.python.org (Justin Foo) Date: Sat, 13 Sep 2014 13:10:29 +0000 Subject: [issue22395] test_pathlib error for complex symlinks on Windows In-Reply-To: <1410540587.88.0.335092451275.issue22395@psf.upfronthosting.co.za> Message-ID: <1410613829.57.0.538111723043.issue22395@psf.upfronthosting.co.za> Justin Foo added the comment: The failing tests were: * test_complex_symlinks_absolute * test_complex_symlinks_relative * test_complex_symlinks_relative_dot_dot for both PathTest and WindowsPathTest, via inheritance from the _BasePathTest class. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 13 15:39:39 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 13 Sep 2014 13:39:39 +0000 Subject: [issue22388] Unify style of "Contributed by" notes In-Reply-To: <1410563093.99.0.0752332288692.issue22388@psf.upfronthosting.co.za> <1410563093.99.0.0752332288692.issue22388@psf.upfronthosting.co.za> Message-ID: <20140913133937.6880E250E0B@webabinitio.net> R. David Murray added the comment: Yep, that's exactly the logic I used for "trailing parenthetical sentence" versus "trailing parenthetical paragraph": whether or not what was being referenced was a single paragraph for a block of paragraphs. I went through and made 3.4 consistent, so there should be no changes there. Likewise the editors of earlier whats new should have made those consistent, and it is probably best not to second guess the editor absent a glaring typo. If you want to make 3.5 "currently consistent" by all means do so. However, a final edit pass (or passes) will be needed at release time whatever you do now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 13 18:05:07 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 13 Sep 2014 16:05:07 +0000 Subject: [issue22388] Unify style of "Contributed by" notes In-Reply-To: <1410438675.22.0.0998241704025.issue22388@psf.upfronthosting.co.za> Message-ID: <1410624307.48.0.891192288521.issue22388@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If don't make these editions now, inconsistent lines will provoke inconsistency in future additions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 13 18:07:12 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 13 Sep 2014 16:07:12 +0000 Subject: [issue22384] Tk.report_callback_exception kills process when run with pythonw.exe In-Reply-To: <1410380074.61.0.464879354999.issue22384@psf.upfronthosting.co.za> Message-ID: <1410624432.11.0.761391539778.issue22384@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +needs review nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 13 18:09:23 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 13 Sep 2014 16:09:23 +0000 Subject: [issue22220] Ttk extensions test failure In-Reply-To: <1408301671.8.0.626599352152.issue22220@psf.upfronthosting.co.za> Message-ID: <1410624563.17.0.670758977614.issue22220@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> works for me stage: test needed -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 13 18:17:03 2014 From: report at bugs.python.org (Berker Peksag) Date: Sat, 13 Sep 2014 16:17:03 +0000 Subject: [issue22398] Tools/msi enhancements for 2.7 In-Reply-To: <1410547573.26.0.0466053668999.issue22398@psf.upfronthosting.co.za> Message-ID: <1410625023.04.0.0176971535332.issue22398@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 13 23:06:38 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 13 Sep 2014 21:06:38 +0000 Subject: [issue22384] Tk.report_callback_exception kills process when run with pythonw.exe In-Reply-To: <1410380074.61.0.464879354999.issue22384@psf.upfronthosting.co.za> Message-ID: <1410642398.47.0.84930054247.issue22384@psf.upfronthosting.co.za> Terry J. Reedy added the comment: In a pythonw process, stdout and stderr are initially None unless and until changed. (This is something we need to do for the Idle process itself.) Writing to None generates an AttributeError. Uncaught exceptions stop the Python process. The patch works, for this particular case, in the sense of preventing process termination. Print suppresses the exception-reporting exception (after trying sys.stdout as a backup). It still fails at delivering the original exception message and traceback. 'Click', and nothing happens. A developer need to see the specific message and users should at least know that something is wrong. The following alternate delivers the message in addition to suppressing the AttributeError. It is a a copy and paste replacement for the existing "def report_callback_exception" statement. (It was easier for me to experiment with my installed, non-repository Pythons). class _Errbox: def __init__(self): self.txt=[] from tkinter.messagebox import showerror self.showerror = showerror def write(self, txt): self.txt.append(txt) def show(self): self.showerror( title="Exception in Tkinter callback", message=''.join(self.txt)) self.txt = [] def report_callback_exception(self, exc, val, tb): """Internal function. It reports exception on sys.stderr.""" import traceback try: sys.stderr.write("Exception in Tkinter callback\n") efile = sys.stderr except AttributeError: efile = self._Errbox() sys.last_type = exc sys.last_value = val sys.last_traceback = tb traceback.print_exception(exc, val, tb, file=efile) if isinstance(efile, self._Errbox): efile.show() I checked and this is the only direct .write in the file. There is only one other print (to the default sys.stdout). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 14 01:31:44 2014 From: report at bugs.python.org (Jeremy Kloth) Date: Sat, 13 Sep 2014 23:31:44 +0000 Subject: [issue22400] Stable API broken on Windows for PyUnicode_* Message-ID: <1410651104.92.0.853615369335.issue22400@psf.upfronthosting.co.za> New submission from Jeremy Kloth: When using any of the PyUnicode_* functions in an extension module compiled with Py_LIMITED_API defined, the resulting module cannot be imported due to: ImportError: DLL load failed: The specified procedure could not be found. Upon investigation, the error is in the EXPORTS for PC\python3.def. The PyUnicode_* functions still refer to the old PyUnicodeUCS2_* variants. ---------- components: Extension Modules, Windows messages: 226856 nosy: jkloth, loewis, steve.dower, zach.ware priority: normal severity: normal status: open title: Stable API broken on Windows for PyUnicode_* versions: Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 14 01:35:15 2014 From: report at bugs.python.org (Akira Li) Date: Sat, 13 Sep 2014 23:35:15 +0000 Subject: [issue22377] %Z in strptime doesn't match EST and others In-Reply-To: <1410301455.57.0.912701656833.issue22377@psf.upfronthosting.co.za> Message-ID: <1410651315.07.0.108395405731.issue22377@psf.upfronthosting.co.za> Akira Li added the comment: if PEP 431 is implemented (or anything that gives access to zoneinfo) then strptime could extend the list of timezones it accepts (utc + local timezone names) to include names from the tz database: import pytz # $ pip install pytz {tzname for tz in map(pytz.timezone, pytz.all_timezones) for _, _, tzname in getattr(tz, '_transition_info', [])} It includes EST. ---------- nosy: +akira _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 14 01:40:06 2014 From: report at bugs.python.org (Akira Li) Date: Sat, 13 Sep 2014 23:40:06 +0000 Subject: [issue22377] %Z in strptime doesn't match EST and others In-Reply-To: <1410301455.57.0.912701656833.issue22377@psf.upfronthosting.co.za> Message-ID: <1410651606.11.0.972045558826.issue22377@psf.upfronthosting.co.za> Akira Li added the comment: Without %z (utc offset) strptime returns a naive datetime object that is interpreted as utc or local time usually. It might explain why %Z tries to match only utc and the local timezone names. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 14 01:59:01 2014 From: report at bugs.python.org (Martin Panter) Date: Sat, 13 Sep 2014 23:59:01 +0000 Subject: [issue12916] Add inspect.splitdoc In-Reply-To: <1315326747.38.0.43030903994.issue12916@psf.upfronthosting.co.za> Message-ID: <1410652741.37.0.648213198664.issue12916@psf.upfronthosting.co.za> Martin Panter added the comment: Although it is not documented, inspect.getdoc() may return None instead of a documentation string. In patch 2, inspect.splitdoc() only accepts a string; perhaps it should also accept None? Otherwise you might have to use it like this: [summary, body] = splitdoc(getdoc(api) or "") ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 14 02:44:51 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 14 Sep 2014 00:44:51 +0000 Subject: [issue20631] python readline module crashing on NULL access In-Reply-To: <1392423131.28.0.0178138253347.issue20631@psf.upfronthosting.co.za> Message-ID: <1410655491.05.0.484560750871.issue20631@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Why does _py_get_history_length return a positive value if there's no line available? ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 14 02:58:40 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 14 Sep 2014 00:58:40 +0000 Subject: [issue20631] python readline module crashing on NULL access In-Reply-To: <1392423131.28.0.0178138253347.issue20631@psf.upfronthosting.co.za> Message-ID: <1410656320.87.0.387006421241.issue20631@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 14 06:31:40 2014 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 14 Sep 2014 04:31:40 +0000 Subject: [issue21998] asyncio: a new self-pipe should be created in the child process after fork In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za> Message-ID: <1410669100.1.0.928660915943.issue21998@psf.upfronthosting.co.za> Yury Selivanov added the comment: It's not that it doesn't work after fork, right? Should we add a recipe with pid monitoring a self-pipe re-initialization? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 14 07:46:39 2014 From: report at bugs.python.org (paul j3) Date: Sun, 14 Sep 2014 05:46:39 +0000 Subject: [issue22401] argparse: 'resolve' conflict handler damages the actions of the parent parser Message-ID: <1410673598.78.0.274465754789.issue22401@psf.upfronthosting.co.za> New submission from paul j3: When there's a conflict involving an argument that was added via 'parents', and the conflict handler is 'resolve', the action in the parent parser may be damaged, rendering that parent unsuitable for further use. In this example, 2 parents have the same '--config' argument: parent1 = argparse.ArgumentParser(add_help=False) parent1.add_argument('--config') parent2 = argparse.ArgumentParser(add_help=False) parent2.add_argument('--config') parser = argparse.ArgumentParser(parents=[parent1,parent2], conflict_handler='resolve') The actions of the 3 parsers are (from the ._actions list): (id, dest, option_strings) parent1: [(3077384012L, 'config', [])] # empty option_strings parent2: [(3076863628L, 'config', ['--config'])] parser: [(3076864428L, 'help', ['-h', '--help']), (3076863628L, 'config', ['--config'])] # same id The 'config' Action from 'parent1' is first copied to 'parser' by reference (this is important). When 'config' from 'parent2' is copied, there's a conflict. '_handle_conflict_resolve()' attempts to remove the first Action, so it can add the second. But in the process it ends up deleting the 'option_strings' values from the original action. So now 'parent1' has an action in its 'optionals' argument group with an empty option_strings list. It would display as an 'optionals' but parse as a 'positionals'. 'parent1' can no longer be safely used as a parent for another (sub)parser, nor used as a parser itself. The same sort of thing would happen, if, as suggested in the documentation: "Sometimes (e.g. when using parents_) it may be useful to simply override any older arguments with the same option string." In test_argparse.py, 'resolve' is only tested once, with a simple case of two 'add_argument' statements. The 'parents' class tests a couple of cases of conflicting actions (for positionals and optionals), but does nothing with the 'resolve' handler. ------------------------------ Possible fixes: - change the documentation to warn against reusing such a parent parser - test the 'resolve' conflict handler more thoroughly - rewrite this conflict handler so it does not modify the action in the parent - possibly change the 'parents' mechanism so it does a deep copy of actions. References: http://stackoverflow.com/questions/25818651/argparse-conflict-resolver-for-options-in-subcommands-turns-keyword-argument-int http://bugs.python.org/issue15271 argparse: repeatedly specifying the same argument ignores the previous ones http://bugs.python.org/issue19462 Add remove_argument() method to argparse.ArgumentParser http://bugs.python.org/issue15428 add "Name Collision" section to argparse docs ---------- assignee: docs at python components: Documentation, Library (Lib), Tests messages: 226862 nosy: docs at python, paul.j3 priority: normal severity: normal status: open title: argparse: 'resolve' conflict handler damages the actions of the parent parser type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 14 09:05:33 2014 From: report at bugs.python.org (Ned Deily) Date: Sun, 14 Sep 2014 07:05:33 +0000 Subject: [issue22168] Turtle Graphics RawTurtle problem In-Reply-To: <1407461263.41.0.42681300045.issue22168@psf.upfronthosting.co.za> Message-ID: <1410678333.37.0.926857213037.issue22168@psf.upfronthosting.co.za> Ned Deily added the comment: The changesets below should prevent the problem in 3.4.2 and 3.5.0. Since there are no standard tests for turtle at the moment, there is no testcase for using a non-default Canvas but one should be added when turtle tests are (Issue21914 and Issue21916). New changset fac17d06e01d by Ned Deily in branch '3.4': Issue #22168: Prevent turtle AttributeError with non-default Canvas on OS X. https://hg.python.org/cpython/rev/fac17d06e01d New changeset 775453a7b85d by Ned Deily in branch 'default': Issue #22168: Prevent turtle AttributeError with non-default Canvas on OS X. https://hg.python.org/cpython/rev/775453a7b85d ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 14 12:34:04 2014 From: report at bugs.python.org (Georg Brandl) Date: Sun, 14 Sep 2014 10:34:04 +0000 Subject: [issue2771] Test issue In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za> Message-ID: <1410690844.82.0.154818876579.issue2771@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 14 12:34:14 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 14 Sep 2014 10:34:14 +0000 Subject: [issue2771] Test issue In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za> Message-ID: <20140914103410.86742.38811@mail.hg.python.org> Roundup Robot added the comment: New changeset 8510224e05dc by Georg Brandl in branch 'default': Closes #2771: test. http://hg.python.org/test/rev/8510224e05dc ---------- resolution: -> fixed stage: test needed -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 14 12:38:26 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 14 Sep 2014 10:38:26 +0000 Subject: [issue2771] Test issue In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za> Message-ID: <20140914103824.117583.2935@mail.hg.python.org> Roundup Robot added the comment: New changeset e79d1244d887 by Georg Brandl in branch 'default': #2771: test baseurl change. https://hg.python.org/test/rev/e79d1244d887 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 14 15:46:54 2014 From: report at bugs.python.org (Martin Panter) Date: Sun, 14 Sep 2014 13:46:54 +0000 Subject: [issue22406] uu-codec trailing garbage workaround is Python 2 code Message-ID: <1410702414.35.0.316849103636.issue22406@psf.upfronthosting.co.za> New submission from Martin Panter: The handler for the ?Trailing garbage? error for ?uu-codec? uses Python 2 code, while the copy in the "uu? module has the correct Python 3 code. Please change the line at https://hg.python.org/cpython/file/775453a7b85d/Lib/encodings/uu_codec.py#l57 to look like https://hg.python.org/cpython/file/775453a7b85d/Lib/uu.py#l148 In particular, drop ord() and use floor division. Better yet, maybe the code could be reused so that there is less duplication! Demonstration: >>> codecs.decode(b"begin 666 \n!,___\n \nend\n", "uu-codec") Traceback (most recent call last): File "/usr/lib/python3.4/encodings/uu_codec.py", line 54, in uu_decode data = binascii.a2b_uu(s) binascii.Error: Trailing garbage During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.4/encodings/uu_codec.py", line 57, in uu_decode nbytes = (((ord(s[0])-32) & 63) * 4 + 5) / 3 TypeError: ord() expected string of length 1, but int found The above exception was the direct cause of the following exception: Traceback (most recent call last): File "", line 1, in TypeError: decoding with 'uu-codec' codec failed (TypeError: ord() expected string of length 1, but int found) >>> codecs.decode(b"begin 666 \n!,P \n \nend\n", "uu-codec") b'3' # Expected output for both cases ---------- components: Library (Lib) messages: 226870 nosy: vadmium priority: normal severity: normal status: open title: uu-codec trailing garbage workaround is Python 2 code type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 14 17:43:19 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 14 Sep 2014 15:43:19 +0000 Subject: [issue22407] re.LOCALE is nonsensical for Unicode Message-ID: <1410709398.9.0.134852560063.issue22407@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Current implementation of re.LOCALE support for Unicode strings is nonsensical. It correctly works only on Latin1 locales (because Unicode string interpreted as Latin1 decoded bytes string. all characters outside UCS1 range considered as non-words), on other locales it got strange and useless results. >>> import re, locale >>> locale.setlocale(locale.LC_CTYPE, 'ru_RU.cp1251') 'ru_RU.cp1251' >>> re.match(br'\w', '?'.encode('cp1251'), re.L) <_sre.SRE_Match object; span=(0, 1), match=b'\xb5'> >>> re.match(r'\w', '?', re.L) <_sre.SRE_Match object; span=(0, 1), match='?'> >>> re.match(br'\w', '?'.encode('cp1251'), re.L) <_sre.SRE_Match object; span=(0, 1), match=b'\xb8'> >>> re.match(r'\w', '?', re.L) Proposed patch fixes re.LOCALE support for Unicode strings. It uses the wide-character equivalents of C characters functions (towlower(), iswalpha(), etc). The problem is that these functions are not exists in C89, they are introduced only in C99. Gcc understand them, we should check other compilers. However these functions are already used on FreeBSD and MacOS. ---------- components: Extension Modules, Library (Lib), Regular Expressions files: re_unicode_locale.patch keywords: patch messages: 226871 nosy: ezio.melotti, mrabarnett, pitrou, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: re.LOCALE is nonsensical for Unicode type: behavior versions: Python 2.7, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file36615/re_unicode_locale.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 14 17:44:55 2014 From: report at bugs.python.org (Drekin) Date: Sun, 14 Sep 2014 15:44:55 +0000 Subject: [issue22408] Tkinter doesn't handle Unicode key events on Windows Message-ID: <1410709495.77.0.324762298735.issue22408@psf.upfronthosting.co.za> New submission from Drekin: Key events produced on Windows handles Unicode incorrectly when Unicode character is produced by dead-key combination. On my keyboard, (AltGr + M, a) produces several key events, last of which contains char=="a", however, it should contain "?". Also dead-key sequence (\, a) should produce event.char=="?", however contains "?". ---------- components: Tkinter, Unicode, Windows messages: 226872 nosy: Drekin, ezio.melotti, haypo priority: normal severity: normal status: open title: Tkinter doesn't handle Unicode key events on Windows versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 14 17:55:46 2014 From: report at bugs.python.org (=?utf-8?q?Brynjar_Sm=C3=A1ri_Bjarnason?=) Date: Sun, 14 Sep 2014 15:55:46 +0000 Subject: [issue22409] namedtuples bug between 3.3.2 and 3.4.1 Message-ID: <1410710146.94.0.736559829031.issue22409@psf.upfronthosting.co.za> New submission from Brynjar Sm?ri Bjarnason: In Python 3.4.1 installed with Anaconda. I tried the following (expecting an OrderedDict as result): >>>from collections import namedtuple >>>NT = namedtuple("NT",["a","b"]) >>>nt = NT(1,2) >>>print(vars(nt)) {} so the result is an empty dict. In Python 3.3.2 (downgraded in the same Anaconda environment) results in: >>>print(vars(nt)) OrderedDict([('a', 1), ('b', 2)]) ---------- components: Distutils messages: 226873 nosy: binnisb, dstufft, eric.araujo priority: normal severity: normal status: open title: namedtuples bug between 3.3.2 and 3.4.1 type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 14 18:22:15 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 14 Sep 2014 16:22:15 +0000 Subject: [issue22409] namedtuples bug between 3.3.2 and 3.4.1 In-Reply-To: <1410710146.94.0.736559829031.issue22409@psf.upfronthosting.co.za> Message-ID: <1410711735.73.0.136859070241.issue22409@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 14 18:23:23 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 14 Sep 2014 16:23:23 +0000 Subject: [issue22410] Locale dependent regexps on different locales Message-ID: <1410711803.67.0.827066928752.issue22410@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Locale-specific case-insensitive regular expression matching works only when the pattern was compiled on the same locale as used for matching. Due to caching this can cause unexpected result. Attached script demonstrates this (it requires two locales: ru_RU.koi8-r and ru_RU.cp1251). The output is: locale ru_RU.koi8-r b'1\xa3' ('1?') matches b'1\xb3' ('1?') b'1\xa3' ('1?') doesn't match b'1\xbc' ('1?') locale ru_RU.cp1251 b'1\xa3' ('1?') doesn't match b'1\xb3' ('1?') b'1\xa3' ('1?') matches b'1\xbc' ('1?') locale ru_RU.cp1251 b'2\xa3' ('2?') doesn't match b'2\xb3' ('2?') b'2\xa3' ('2?') matches b'2\xbc' ('2?') locale ru_RU.koi8-r b'2\xa3' ('2?') doesn't match b'2\xb3' ('2?') b'2\xa3' ('2?') matches b'2\xbc' ('2?') b'\xa3' matches b'\xb3' on KOI8-R locale if the pattern was compiled on KOI8-R locale and matches b'\xb3' if the pattern was compiled on CP1251 locale. I see three possible ways to solve this issue: 1. Avoid caching of locale-depending case-insensitive patterns. This definitely will decrease performance of the use of locale-depending case-insensitive regexps (if user don't use own caching) and may be slightly decrease performance of the use of other regexps. 2. Clear precompiled regexps cache on every locale change. This can look simpler, but is vulnerable to locale changes from extensions. 3. Do not lowercase characters at compile time (in locale-depending case-insensitive patterns). This needs to introduce new opcode for case-insensitivity matching or at least rewriting implementation of current opcodes (less efficient). On other way, this is more correct implementation than current one. The problem is that this is incompatible with those distributions which updates only Python library but not statically linked binary (e.g. Vim with Python support). May be there are some workarounds. ---------- components: Extension Modules, Library (Lib), Regular Expressions files: re_locale_caching.py messages: 226874 nosy: ezio.melotti, mrabarnett, pitrou, serhiy.storchaka priority: normal severity: normal status: open title: Locale dependent regexps on different locales type: behavior versions: Python 2.7, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file36616/re_locale_caching.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 14 18:33:55 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 14 Sep 2014 16:33:55 +0000 Subject: [issue22409] namedtuples bug between 3.3.2 and 3.4.1 In-Reply-To: <1410710146.94.0.736559829031.issue22409@psf.upfronthosting.co.za> Message-ID: <1410712435.91.0.0638396595316.issue22409@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > so the result is an empty dict. It works fine for me in the standard distribution: Python 3.4.1 (v3.4.1:c0e311e010fc, May 18 2014, 00:54:21) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "copyright", "credits" or "license()" for more information. >>> from collections import namedtuple >>> NT = namedtuple("NT",["a","b"]) >>> nt = NT(1,2) >>> print(vars(nt)) OrderedDict([('a', 1), ('b', 2)]) There may be something amiss with the Anaconda distribution. I suggest reporting this to Continuum IO (the producers of that distribution). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 14 18:43:38 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 14 Sep 2014 16:43:38 +0000 Subject: [issue22384] Tk.report_callback_exception kills process when run with pythonw.exe In-Reply-To: <1410380074.61.0.464879354999.issue22384@psf.upfronthosting.co.za> Message-ID: <1410713018.43.0.441321964688.issue22384@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Error messages are already silenced if sys.stderr is None or closed. >>> sys.stderr.close() >>> 1/0 >>> >>> sys.stderr = None >>> 1/0 >>> I think that such things as _Errbox are application level solutions. report_callback_exception() is designed to be overwritten for this purpose. Application can decide to pop up message box always, not only when sys.stderr is None, or tracebacks to a log, or add application icon and scrollbar on message box, or output error on special area on main windows. Definitely it would be good to add something like _Errbox to IDLE. But this will be other issue. This issue is only about "crashing" of default implementation, and if my patch fixes it, I want to commit it and close the issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 14 18:49:03 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 14 Sep 2014 16:49:03 +0000 Subject: [issue22406] uu-codec trailing garbage workaround is Python 2 code In-Reply-To: <1410702414.35.0.316849103636.issue22406@psf.upfronthosting.co.za> Message-ID: <1410713343.47.0.154716174582.issue22406@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka keywords: +easy nosy: +doerwalter, lemburg, serhiy.storchaka priority: normal -> low stage: -> needs patch versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 14 18:51:20 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 14 Sep 2014 16:51:20 +0000 Subject: [issue22406] uu-codec trailing garbage workaround is Python 2 code In-Reply-To: <1410702414.35.0.316849103636.issue22406@psf.upfronthosting.co.za> Message-ID: <1410713480.91.0.487240922287.issue22406@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Do you want to provide a patch Martin? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 14 18:59:32 2014 From: report at bugs.python.org (Matthew Barnett) Date: Sun, 14 Sep 2014 16:59:32 +0000 Subject: [issue22410] Locale dependent regexps on different locales In-Reply-To: <1410711803.67.0.827066928752.issue22410@psf.upfronthosting.co.za> Message-ID: <1410713972.85.0.480887475953.issue22410@psf.upfronthosting.co.za> Matthew Barnett added the comment: The support for locales in the re module is limited to those with 1 byte per character, and only for a few properties (those provided by the underlying C library), so maybe it could do the following: If the LOCALE flag is set, then read the current locale and build a table of its properties. Let the compiled pattern refer to the property table. When matching, use the property table referred to by the pattern. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 14 19:36:56 2014 From: report at bugs.python.org (=?utf-8?q?Brynjar_Sm=C3=A1ri_Bjarnason?=) Date: Sun, 14 Sep 2014 17:36:56 +0000 Subject: [issue22409] namedtuples bug between 3.3.2 and 3.4.1 In-Reply-To: <1410710146.94.0.736559829031.issue22409@psf.upfronthosting.co.za> Message-ID: <1410716216.89.0.777801513381.issue22409@psf.upfronthosting.co.za> Brynjar Sm?ri Bjarnason added the comment: Thanks, I'll report it to Continuum IO. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 14 19:37:21 2014 From: report at bugs.python.org (=?utf-8?q?Brynjar_Sm=C3=A1ri_Bjarnason?=) Date: Sun, 14 Sep 2014 17:37:21 +0000 Subject: [issue22409] namedtuples bug between 3.3.2 and 3.4.1 In-Reply-To: <1410710146.94.0.736559829031.issue22409@psf.upfronthosting.co.za> Message-ID: <1410716241.53.0.287877000026.issue22409@psf.upfronthosting.co.za> Changes by Brynjar Sm?ri Bjarnason : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 14 19:38:12 2014 From: report at bugs.python.org (Berker Peksag) Date: Sun, 14 Sep 2014 17:38:12 +0000 Subject: [issue22409] namedtuples bug between 3.3.2 and 3.4.1 In-Reply-To: <1410710146.94.0.736559829031.issue22409@psf.upfronthosting.co.za> Message-ID: <1410716292.01.0.726497984353.issue22409@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> third party stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 14 19:44:33 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 14 Sep 2014 17:44:33 +0000 Subject: [issue22384] Tk.report_callback_exception kills process when run with pythonw.exe In-Reply-To: <1410380074.61.0.464879354999.issue22384@psf.upfronthosting.co.za> Message-ID: <1410716673.59.0.360185197482.issue22384@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Since traceback.print_exception already uses print statememts, your patch *is* sufficient to trap the remaining stderr exception. Go ahead. The doctring for report_callback_exception calls it an 'internal function'. To me, that implies 'ignore this' rather than 'override this'. I suggest changing the docstring to """Report callback exception on sys.stderr. Applications may want to override this internal function, and should when sys.stderr is None. """ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 14 19:45:56 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 14 Sep 2014 17:45:56 +0000 Subject: [issue22384] Tk.report_callback_exception kills process when run with pythonw.exe In-Reply-To: <1410380074.61.0.464879354999.issue22384@psf.upfronthosting.co.za> Message-ID: <1410716756.39.0.203424818094.issue22384@psf.upfronthosting.co.za> Terry J. Reedy added the comment: And yes, I am thinking about a broader fix for Idle -- replacing stderr None with something writable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 14 19:57:04 2014 From: report at bugs.python.org (Joakim Karlsson) Date: Sun, 14 Sep 2014 17:57:04 +0000 Subject: [issue22411] Embedding Python on Windows Message-ID: <1410717424.69.0.586099783725.issue22411@psf.upfronthosting.co.za> New submission from Joakim Karlsson: When I embed Python 3.4 in an existing app, I run in to a few issues when our app is built in debug mode. I build against the headers, libs and dlls that I get when installing python, I don't build python myself. 1. When I include python.h it will, via pyconfig.h, automatically attempt to link to python34_d.lib. This lib, along with its accompanying dll is not included in the python installation. I'd rather explicitly link to the release lib than having header files implicitly selecting libs based on the _DEBUG flag. I ended up killing the #pragma comment(lib...) statements in pyconfig.h, and I can now link with the lib included. 2. Now when I build, I get a linker error telling me that '__imp__Py_RefTotal' and '__imp_Py_NegativeRefCount' cannot be found. This seems to be caused by Py_DEBUG being defined automatically in pyconfig.h as a result of _DEBUG being defined for my application. This causes the reference counting macros to use functionality that is only present in the debug version of python34.dll. I ended up including pyconfig.h first, undefed Py_DEBUG, and then including python.h. This seems rather clunky. Keeping with "explicit is better than implicit", wouldn't it be better to having to explicitly link to the desired lib from the embedding app, and explicitly set Py_DEBUG without having it inferred from _DEBUG? That way the provided headers and libs would work right out of the box while still leaving me the option to get the debug behaviour if I need to. ---------- components: Windows messages: 226882 nosy: Joakim.Karlsson priority: normal severity: normal status: open title: Embedding Python on Windows type: compile error versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 14 20:20:49 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 14 Sep 2014 18:20:49 +0000 Subject: [issue22384] Tk.report_callback_exception kills process when run with pythonw.exe In-Reply-To: <1410380074.61.0.464879354999.issue22384@psf.upfronthosting.co.za> Message-ID: <20140914182046.117593.10440@mail.hg.python.org> Roundup Robot added the comment: New changeset 994a16b51544 by Serhiy Storchaka in branch '2.7': Issue #22384: An exception in Tkinter callback no longer crashes the program https://hg.python.org/cpython/rev/994a16b51544 New changeset c62fad86fac3 by Serhiy Storchaka in branch '3.4': Issue #22384: An exception in Tkinter callback no longer crashes the program https://hg.python.org/cpython/rev/c62fad86fac3 New changeset 7191b14ca312 by Serhiy Storchaka in branch 'default': Issue #22384: An exception in Tkinter callback no longer crashes the program https://hg.python.org/cpython/rev/7191b14ca312 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 14 20:26:24 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 14 Sep 2014 18:26:24 +0000 Subject: [issue22384] Tk.report_callback_exception kills process when run with pythonw.exe In-Reply-To: <1410380074.61.0.464879354999.issue22384@psf.upfronthosting.co.za> Message-ID: <1410719183.98.0.0430825479008.issue22384@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for suggested docstring Terry. There is related question on StackOverflow: http://stackoverflow.com/questions/4770993/silent-exceptions-in-python-tkinter-should-i-make-them-louder-how ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 14 20:39:51 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 14 Sep 2014 18:39:51 +0000 Subject: [issue22384] Tk.report_callback_exception kills process when run with pythonw.exe In-Reply-To: <1410380074.61.0.464879354999.issue22384@psf.upfronthosting.co.za> Message-ID: <1410719991.19.0.0773074436176.issue22384@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Aivar for helpful report. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 14 21:40:02 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 14 Sep 2014 19:40:02 +0000 Subject: [issue17668] re.split loses characters matching ungrouped parts of a pattern In-Reply-To: <1365445138.49.0.018016443065.issue17668@psf.upfronthosting.co.za> Message-ID: <1410723602.13.0.707274212615.issue17668@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> not a bug stage: needs patch -> resolved status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 14 21:40:45 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 14 Sep 2014 19:40:45 +0000 Subject: [issue11204] re module: strange behaviour of space inside {m, n} In-Reply-To: <1297552798.48.0.889043344562.issue11204@psf.upfronthosting.co.za> Message-ID: <1410723645.74.0.676782226549.issue11204@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> rejected stage: -> resolved status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 14 22:29:31 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 14 Sep 2014 20:29:31 +0000 Subject: [issue20537] logging exc_info parameter should accept exception instances In-Reply-To: <1391730788.17.0.188838717397.issue20537@psf.upfronthosting.co.za> Message-ID: <20140914202927.77017.61607@mail.hg.python.org> Roundup Robot added the comment: New changeset 9d54903a84b5 by Vinay Sajip in branch 'default': Closes #20537: logging methods now accept an exception instance as well as a Boolean value or exception tuple. Thanks to Yury Selivanov for the patch. https://hg.python.org/cpython/rev/9d54903a84b5 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 14 23:15:35 2014 From: report at bugs.python.org (Martin Teichmann) Date: Sun, 14 Sep 2014 21:15:35 +0000 Subject: [issue22412] Towards an asyncio-enabled command line Message-ID: <1410729335.06.0.363715018256.issue22412@psf.upfronthosting.co.za> New submission from Martin Teichmann: This patch is supposed to facilitate using the asyncio package on the command line. It contains two things: First, a coroutine version of builtin.input, so that it can be called while a asyncio event loop is running. Secondly, it adds a new flag to builtin.compile which allows to use the yield and yield from statements on the module level, making compile always return a generator. The latter part will enable us to run commands like the following on the command line: >>> from asyncio import sleep >>> yield from sleep(3) (This has been discussed on python-ideas, https://mail.python.org/pipermail/python-ideas/2014-September/029293.html) ---------- components: Interpreter Core, asyncio files: patch messages: 226887 nosy: Martin.Teichmann, gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: Towards an asyncio-enabled command line type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file36617/patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 01:16:55 2014 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 14 Sep 2014 23:16:55 +0000 Subject: [issue22412] Towards an asyncio-enabled command line In-Reply-To: <1410729335.06.0.363715018256.issue22412@psf.upfronthosting.co.za> Message-ID: <1410736615.12.0.0400737628793.issue22412@psf.upfronthosting.co.za> Guido van Rossum added the comment: 1. Great that you're trying to implement this! 2. But I really recommend that you try to structure this as a 3rd party module first rather than patching the Python distribution -- it's much harder to get accepted. Or as a pure-Python patch to asyncio, rather than patching the interpreter's C code. 3. Which Python version did you use as a starting point? The patch doesn't apply cleanly to the repo head for either Python 3.4 or 3.5. If you used a source distribution, please switch to the Mercurial repo. I recommend 3.5, as this is a new feature. 4. If you really want to patch Python, you need to add docs. In fact, I recommend writing the docs first. 5. What on earth is going on in your input() coroutine? You create a Future and then immediately yield from it. How is it becoming done? 6. Surely all that C code you are adding to readline.c was copied from some other place. From where? Perhaps it can be refactored rather than copied? 7. See #2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 01:45:33 2014 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 14 Sep 2014 23:45:33 +0000 Subject: [issue21998] asyncio: a new self-pipe should be created in the child process after fork In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za> Message-ID: <1410738333.05.0.00523038403284.issue21998@psf.upfronthosting.co.za> Guido van Rossum added the comment: Actually I expect that if you share an event loop across different processes via form, everything's a mess -- whenever a FD becomes ready, won't both the parent and the child be woken up? Then both would attempt to read from it. One would probably get EWOULDBLOCK (assuming all FDs are actually in non-blocking mode) but it would still be a mess. The specific mess for the self-pipe would be that the race condition it's intended to solve might come back. It's possible that some polling syscall might have some kind of protection against forking, but the Python data structures that map FDs to handlers don't know that, so it would still be a mess. Pretty much the only thing you should expect to be able to do safely after forking is closing the event loop -- and I'm not even 100% sure that that's safe (I don't know what happens to a forked executor). Is there a use case for sharing an event loop across forking? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 01:47:28 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 14 Sep 2014 23:47:28 +0000 Subject: [issue11437] IDLE crash on startup with typo in config-keys.cfg In-Reply-To: <1299543243.52.0.970222997696.issue11437@psf.upfronthosting.co.za> Message-ID: <1410738448.27.0.565152311871.issue11437@psf.upfronthosting.co.za> Terry J. Reedy added the comment: https://stackoverflow.com/questions/25750477/python-2-7-8-idle-will-not-open-on-mavericks -- because one of the two files has 'shift' instead of Shift. When I make a change in either file (with custom keys being used), the traceback ends slightly differently until the final message. File "C:\Programs\Python34\lib\idlelib\EditorWindow.py", line 1100, in apply_bindings text.event_add(event, *keylist) File "C:\Programs\Python34\lib\idlelib\MultiCall.py", line 379, in event_add widget.event_add(self, virtual, seq) File "C:\Programs\Python34\lib\tkinter\__init__.py", line 1441, in event_add self.tk.call(args) #21519 is about checking bindings entered in the dialog with either the basic or advanced methods. Bindings also need to be checked when read so we know which file is bad. Exception tracebacks should be replaced by more helpful messages that include fix-up instructions and which do not disappear into the void when running on pythonw. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 02:39:05 2014 From: report at bugs.python.org (Christian Kleineidam) Date: Mon, 15 Sep 2014 00:39:05 +0000 Subject: [issue18844] allow weights in random.choice In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za> Message-ID: <1410741545.53.0.592121367622.issue18844@psf.upfronthosting.co.za> Christian Kleineidam added the comment: I like the idea of adding a weights keyword to choice and creating an additional choice_generator() that also takes weights. A choice_generator() could take a further argument to allow unique choices and be a generator version of sample(). In some cases you want to draw randomly from a sequence till you draw an item that fulfills certain criteria. At the moment neither the sample nor the shuffle method seems to be optimal for that use case. Given that items are commonly drawn from an urn in math, urn seems a good alternative for choice_generator(). random.urn(data, *, weights=None, unique=False) ---------- nosy: +Christian.Kleineidam _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 03:28:23 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 15 Sep 2014 01:28:23 +0000 Subject: [issue21998] asyncio: a new self-pipe should be created in the child process after fork In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za> Message-ID: <1410744503.92.0.190224565519.issue21998@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Is there a use case for sharing an event loop across forking? I don't think so. I use forking mainly for the following two use-cases: - Socket sharing for web servers. Solution: if you want to have a shared sockets between multiple child processes, just open them in master process, fork as many times as you want, and start event loops in child processes only. - If sometimes you want to spawn some child process "on demand". Solution: fork before having a loop running, and use the child process as a "template", i.e. when you need a new child process - just ask the first child to fork it. It would certainly be handy to have an ability to fork while the loop is running and safely close (and reopen) it in the forked child process. But now I can see that it's a non-trivial thing to do properly. Probably it's ~somewhat~ safe to re-initialize epoll (or whatever selector we use), re-open self-pipe etc, drop all queued callbacks and clear Task.all_tasks collection, but even then it's easy to miss something. I think we just need to make sure that we have documented that asyncio loops are not fork safe, and forks in running loops should be avoided by all means. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 03:36:06 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 15 Sep 2014 01:36:06 +0000 Subject: [issue22408] Tkinter doesn't handle Unicode key events on Windows In-Reply-To: <1410709495.77.0.324762298735.issue22408@psf.upfronthosting.co.za> Message-ID: <1410744966.69.0.796713744258.issue22408@psf.upfronthosting.co.za> Ned Deily added the comment: I don't have a real Windows setup to test but I would guess this may be Tk behavior. Perhaps the Tk wiki page on platform-specific keyboard modifier behaviors will help: http://wiki.tcl.tk/28331 ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 03:38:10 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 15 Sep 2014 01:38:10 +0000 Subject: [issue22411] Embedding Python on Windows In-Reply-To: <1410717424.69.0.586099783725.issue22411@psf.upfronthosting.co.za> Message-ID: <1410745090.31.0.551403616827.issue22411@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 04:21:32 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 15 Sep 2014 02:21:32 +0000 Subject: [issue17095] Modules/Setup *shared* support broken In-Reply-To: <1359669296.59.0.227426586133.issue17095@psf.upfronthosting.co.za> Message-ID: <20140915022129.111152.49775@mail.hg.python.org> Roundup Robot added the comment: New changeset 781454f792c4 by Ned Deily in branch '3.4': Issue #17095: Temporarily revert getpath.c change that added the Modules https://hg.python.org/cpython/rev/781454f792c4 New changeset d3939f602e1f by Ned Deily in branch 'default': Issue #17095: merge from 3.4 https://hg.python.org/cpython/rev/d3939f602e1f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 04:25:34 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 15 Sep 2014 02:25:34 +0000 Subject: [issue17095] Modules/Setup *shared* support broken In-Reply-To: <1359669296.59.0.227426586133.issue17095@psf.upfronthosting.co.za> Message-ID: <1410747934.55.0.815478170359.issue17095@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- priority: release blocker -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 05:04:03 2014 From: report at bugs.python.org (Martin Panter) Date: Mon, 15 Sep 2014 03:04:03 +0000 Subject: [issue22413] Bizarre StringIO(newline="\r\n") translation Message-ID: <1410750243.44.0.979805676788.issue22413@psf.upfronthosting.co.za> New submission from Martin Panter: I noticed that the newline translation in the io.StringIO class does not behave as I would expect: >>> text = "NL\n" "CRLF\r\n" "CR\r" "EOF" >>> s = StringIO(text, newline="\r\n") >>> s.getvalue() 'NL\r\nCRLF\r\r\nCR\rEOF' # Why is this not just equal to ?text?? >>> tuple(s) ('NL\r\n', 'CRLF\r\r\n', 'CR\rEOF') # Too many lines, butchered EOL sequence >>> tuple(TextIOWrapper(BytesIO(text.encode("ascii")), "ascii", newline="\r\n")) ('NL\nCRLF\r\n', 'CR\rEOF') # This seems more reasonable Although I have never had a use for newline="\r", it also seems broken: >>> tuple(StringIO(text, newline="\r")) ('NL\r', 'CRLF\r', '\r', 'CR\r', 'EOF') # Way too many lines >>> tuple(TextIOWrapper(BytesIO(text.encode("ascii")), "ascii", newline="\r")) ('NL\nCRLF\r', '\nCR\r', 'EOF') The other newline options ("\n", "", and None) seem to behave correctly though. There seem to be quite a few bug reports to do with newline translation in StringIO, but I couldn?t see anything specifically about this one. However the issue was mentioned at . I noticed there are test cases which appear to bless the current behaviour, as seen in the patch for Issue 20498. IMO these tests are wrong. ---------- components: IO messages: 226895 nosy: vadmium priority: normal severity: normal status: open title: Bizarre StringIO(newline="\r\n") translation type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 06:36:49 2014 From: report at bugs.python.org (Martin Panter) Date: Mon, 15 Sep 2014 04:36:49 +0000 Subject: [issue15216] Support setting the encoding on a text stream after creation In-Reply-To: <1340880558.16.0.0136840668667.issue15216@psf.upfronthosting.co.za> Message-ID: <1410755809.04.0.13730713043.issue15216@psf.upfronthosting.co.za> Martin Panter added the comment: Some more use cases for temporarily switching error handler in the middle of writing to a stream: * Possibly simplify the implementation of sys.displayhook() * I have done a similar hack at , to output a comment field with a permissive error handler, while other data is output with strict error handling. A use case for changing a reader?s newline translation mode is to use standard input with the built-in ?csv? module. My current idea is to do something like this: encoding = sys.stdin.encoding errors = sys.stdin.errors line_buffering = sys.stdin.line_buffering # No way to retain write_through mode, but shouldn?t matter for reading sys.stdin = TextIOWrapper(sys.stdin.detach(), encoding, errors, newline="", line_buffering=line_buffering) for row in csv.reader(sys.stdin): ... On the other hand, I wonder about rewinding an input file after already having read and buffered text in the wrong encoding. From a distance, the Python native version of the code seems rather complex and full of dark magic. Is there a use case, or maybe it would be simpler to have it only work when nothing has been read or buffered? ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 08:11:27 2014 From: report at bugs.python.org (VUIUI) Date: Mon, 15 Sep 2014 06:11:27 +0000 Subject: [issue22414] I'd like to add you to my professional network on LinkedIn Message-ID: <1295080853.6845761.1410761481019.JavaMail.app@ela4-app2681.prod> New submission from VUIUI: Hi, I'd like to add you to my professional network on LinkedIn. - S?i Accept: http://www.linkedin.com/blink?simpleRedirect=38RdP0VczsRe3gQd38ScjsNejkZh4BKrSBQonhFtCVF9z5KjmdKiiQJfnBBiShBsC5EsOpQsSlRpRZBt6BSrCAZqSkConhzbmlQqnpKqiRQsSlRpORIrmkZpSVFqSdxsDgCpnhFtCV9pSlipn9Mfm4CsPgJc3ByumkPc6AJcSlKoT4PbjRBfP9SbSkLrmZzbCVFp6lHrCBIbDtTtOYLeDdMt7hE&msgID=I7888360485_1&markAsRead= You received an invitation to connect. LinkedIn will use your email address to make suggestions to our members in features like People You May Know. Unsubscribe here: http://www.linkedin.com/blink?simpleRedirect=pT9Lhj8BrCZEt7BMhj8BsStRoz0Q9nhOrT1BszRIqm5JpipQs64MczxGcTdSpP9IcDoZp6Bx9z4Sc30OfmhF9z4JfmhFripPd2QMem9VpjcMqiQPpmVzsjcJfmhFpipQsSlRpRZBt6BSrCAZqSkCkjoPp4l7q5p6sCR6kk4ZrClHrRhAqmQCsSVRfngCsPgJc3ByumkPc6AJcSlKoT4PbjRBfP9SbSkLrmZzbCVFp6lHrCBIbDtTtOYLeDdMt7hE&msgID=I7888360485_1&markAsRead= Learn why we included this at the following link: http://www.linkedin.com/blink?simpleRedirect=e3wTd3RAimlIoSBQsC4Ct7dBtmtvpnhFtCVFfmJB9CNOlmlzqnpOpldOpmRLt7dRoPRx9DcQbj0VoDBBcP1FbjdBrCdNcOQZpjYOtyZBbSRLoOVKqmhBqSVFr2VTtTsLbPFMt7hE&msgID=I7888360485_1&markAsRead= © 2014, LinkedIn Corporation. 2029 Stierlin Ct. Mountain View, CA 94043, USA ---------- messages: 226897 nosy: VUIUI priority: normal severity: normal status: open title: I'd like to add you to my professional network on LinkedIn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 08:17:30 2014 From: report at bugs.python.org (Georg Brandl) Date: Mon, 15 Sep 2014 06:17:30 +0000 Subject: [issue22414] I'd like to add you to my professional network on LinkedIn In-Reply-To: <1295080853.6845761.1410761481019.JavaMail.app@ela4-app2681.prod> Message-ID: <1410761850.64.0.844800206917.issue22414@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 08:52:02 2014 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Mon, 15 Sep 2014 06:52:02 +0000 Subject: [issue18159] ConfigParser getters not available on SectionProxy In-Reply-To: <1370627030.12.0.961792763365.issue18159@psf.upfronthosting.co.za> Message-ID: <1410763922.85.0.0218372783771.issue18159@psf.upfronthosting.co.za> Changes by ?ukasz Langa : ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 08:56:10 2014 From: report at bugs.python.org (Martin Panter) Date: Mon, 15 Sep 2014 06:56:10 +0000 Subject: [issue22406] uu-codec trailing garbage workaround is Python 2 code In-Reply-To: <1410702414.35.0.316849103636.issue22406@psf.upfronthosting.co.za> Message-ID: <1410764170.3.0.848231397237.issue22406@psf.upfronthosting.co.za> Martin Panter added the comment: Here are two patches: a test and a fix. I?m not sure if it is okay to add a test for the ?codecs? module with the tests for the ?uu? module; it was easier that way because I am basically running the same test over the two different APIs. ---------- Added file: http://bugs.python.org/file36618/test _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 08:56:33 2014 From: report at bugs.python.org (Martin Panter) Date: Mon, 15 Sep 2014 06:56:33 +0000 Subject: [issue22406] uu-codec trailing garbage workaround is Python 2 code In-Reply-To: <1410702414.35.0.316849103636.issue22406@psf.upfronthosting.co.za> Message-ID: <1410764193.04.0.738058837688.issue22406@psf.upfronthosting.co.za> Changes by Martin Panter : Added file: http://bugs.python.org/file36619/uu_codec _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 09:15:50 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 15 Sep 2014 07:15:50 +0000 Subject: [issue21998] asyncio: a new self-pipe should be created in the child process after fork In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za> Message-ID: <1410765350.38.0.815482861443.issue21998@psf.upfronthosting.co.za> STINNER Victor added the comment: > Is there a use case for sharing an event loop across forking? I don't know if asyncio must have a builtin support for this use case. The minimum is to document the behaviour, or maybe even suggest a recipe to support it. For example, an event loop of asyncio is not thread-safe and we don't want to support this use case. But I wrote a short documentation with code snippets to show how to workaround this issue: https://docs.python.org/dev/library/asyncio-dev.html#concurrency-and-multithreading We need a similar section to explain how to use asyncio with the os.fork() function and the multiprocesing module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 09:17:42 2014 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Mon, 15 Sep 2014 07:17:42 +0000 Subject: [issue18159] ConfigParser getters not available on SectionProxy In-Reply-To: <1370627030.12.0.961792763365.issue18159@psf.upfronthosting.co.za> Message-ID: <1410765462.07.0.318325960842.issue18159@psf.upfronthosting.co.za> ?ukasz Langa added the comment: The reason I didn't commit that patch before was that I wasn't sure whether making this change wouldn't create any unexpected backwards incompatibility. In fact, if I committed the patch as is, it would. I solved this by leaving getint, getfloat and getboolean on the parser class and keeping _get in use. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 09:28:02 2014 From: report at bugs.python.org (Martin Teichmann) Date: Mon, 15 Sep 2014 07:28:02 +0000 Subject: [issue22412] Towards an asyncio-enabled command line In-Reply-To: <1410729335.06.0.363715018256.issue22412@psf.upfronthosting.co.za> Message-ID: <1410766082.15.0.397337286052.issue22412@psf.upfronthosting.co.za> Martin Teichmann added the comment: Hi Guido, thanks for the quick response, so my response to your post: to 1: thanks! to 2: I am trying to put most of the stuff into a 3rd party module, unfortunately I need changes in the python compiler, and given that monkey patching is not so simple in C, changing the compiler would mean to re-write it, I know that has been done, but I figured that starting a project like PyPy or jython is a bit too much for me right now. to 3: I started with the repo head of friday night... apparently I was not fast enough to submit this patch before someone changes the python code to the point that my patch doesn't apply anymore. I'll try to fix that soon. to 4: I'll write some docs. to 5: well, there is a callback function just some lines up which will call future.set_result(None). Maybe that was a bit too slick, I'm open for comments on how to do that better. to 6: the C code I put into readline.c is mostly a merge of readline_until_enter_or_signal (in readline.c) and builtin_input (in bltinmodule.c). You're definitely right that those functions could do with some refactoring, but I didn't dare to since they are full of complicated special code for special platforms, and I have no chance to test the code on a machine which has a completely outdated version of the readline library, so I picked the code I needed. to 6: I thought about writing the input part of my patch as a 3rd party library, but then I saw the state of builtin.input and thought that it would actually be a good idea to shine some light onto the state of that function, it is actually a horrible mess. Just look at all the awful dirty tricks that the people over at IPython have to do to use it (im)properly (I'm talking about IPython.lib.inputhook*). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 09:52:30 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 15 Sep 2014 07:52:30 +0000 Subject: [issue22413] Bizarre StringIO(newline="\r\n") translation In-Reply-To: <1410750243.44.0.979805676788.issue22413@psf.upfronthosting.co.za> Message-ID: <1410767550.47.0.380907201053.issue22413@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See issue20435. ---------- nosy: +pitrou, serhiy.storchaka versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 10:07:14 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 15 Sep 2014 08:07:14 +0000 Subject: [issue22415] Fix re debugging output Message-ID: <1410768434.94.0.831625656606.issue22415@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch fixes some issues in debugging output of the compiling of regular expression with the re.DEBUG flag. 1. Fixed the handling of the GROUPREF_EXISTS opcode. Example: >>> re.compile(r'(ab)(?(1)cd|ef)', re.DEBUG) Before patch ("yes" and "no" branches are not separated): subpattern 1 literal 97 literal 98 subpattern None groupref_exists 1 literal 99 literal 100 literal 101 literal 102 After patch: subpattern 1 literal 97 literal 98 subpattern None groupref_exists 1 literal 99 literal 100 or literal 101 literal 102 2. Got rid of trailing spaces in Python 3. 3. Used named opcode constants instead of inlined strings. 4. Simplified and modernized the code. 5. Updated test to cover more code. ---------- components: Library (Lib), Regular Expressions files: re_debug.patch keywords: patch messages: 226903 nosy: ezio.melotti, mrabarnett, pitrou, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Fix re debugging output type: behavior versions: Python 2.7, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file36620/re_debug.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 10:33:49 2014 From: report at bugs.python.org (Yongzhi Pan) Date: Mon, 15 Sep 2014 08:33:49 +0000 Subject: [issue22379] Empty exception message of str.join In-Reply-To: <1410317691.24.0.990266868285.issue22379@psf.upfronthosting.co.za> Message-ID: <1410770029.5.0.628011077538.issue22379@psf.upfronthosting.co.za> Yongzhi Pan added the comment: I have updated the test for 3.5. The related tests pass after the patching. Are they OK now? There are two caveats: I did not update test_bytes in 2.7, and I did not add checkraises in test_bytes in 3.5. ---------- Added file: http://bugs.python.org/file36621/test_for_35-1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 10:42:37 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 15 Sep 2014 08:42:37 +0000 Subject: [issue22416] Pickling compiled re patterns Message-ID: <1410770557.9.0.129599945661.issue22416@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Compiled re._compile() is used to reconstruct compiled regular expression pattern. re._compile() is private function and can be removed in (long-term) future. I propose to use re.compile() instead. ---------- components: Library (Lib), Regular Expressions keywords: easy messages: 226905 nosy: ezio.melotti, mrabarnett, pitrou, serhiy.storchaka priority: normal severity: normal status: open title: Pickling compiled re patterns type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 10:43:29 2014 From: report at bugs.python.org (Drekin) Date: Mon, 15 Sep 2014 08:43:29 +0000 Subject: [issue22408] Tkinter doesn't handle Unicode key events on Windows In-Reply-To: <1410709495.77.0.324762298735.issue22408@psf.upfronthosting.co.za> Message-ID: <1410770609.25.0.330666827924.issue22408@psf.upfronthosting.co.za> Drekin added the comment: It seems that it's a problem of dead key combinations rather than modifiers. Unicode characters produced directly (with or without modifiers) work correctly. Only one deadkey on my keyboard doesn't work at all. AltGr + M is a deadkey, but any following key is interpreted as if no deadkey was pressed. On the other hand, other deadkeys including those with modifiers produces the combined characters, however usually returns just "?" as if someone applied char = char.encode("mbcs", errors="replace").decode(). E.g. whole Greek alphabet is transformed to question marks but beta is transformed to sharp s and mu to micro sign. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 11:08:25 2014 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Mon, 15 Sep 2014 09:08:25 +0000 Subject: [issue18159] ConfigParser getters not available on SectionProxy In-Reply-To: <1370627030.12.0.961792763365.issue18159@psf.upfronthosting.co.za> Message-ID: <1410772105.26.0.835084291847.issue18159@psf.upfronthosting.co.za> ?ukasz Langa added the comment: The new implementation also automatically covers get*() methods added on subclasses, no need to use converters= in that case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 11:10:57 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 15 Sep 2014 09:10:57 +0000 Subject: [issue18159] ConfigParser getters not available on SectionProxy In-Reply-To: <1370627030.12.0.961792763365.issue18159@psf.upfronthosting.co.za> Message-ID: <20140915091053.116481.4972@mail.hg.python.org> Roundup Robot added the comment: New changeset 2c46a4ded259 by ?ukasz Langa in branch 'default': Closes #18159: ConfigParser getters not available on SectionProxy https://hg.python.org/cpython/rev/2c46a4ded259 New changeset 5eb95d41ee43 by ?ukasz Langa in branch 'default': Closes #18159: ConfigParser getters not available on SectionProxy https://hg.python.org/cpython/rev/5eb95d41ee43 ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 11:22:48 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 15 Sep 2014 09:22:48 +0000 Subject: [issue22416] Pickling compiled re patterns In-Reply-To: <1410770557.9.0.129599945661.issue22416@psf.upfronthosting.co.za> Message-ID: <1410772968.42.0.223777383212.issue22416@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file36622/re_pickle.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 11:38:53 2014 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Mon, 15 Sep 2014 09:38:53 +0000 Subject: [issue22253] ConfigParser does not handle files without sections In-Reply-To: <1408731768.17.0.221948826268.issue22253@psf.upfronthosting.co.za> Message-ID: <1410773933.8.0.782885416141.issue22253@psf.upfronthosting.co.za> ?ukasz Langa added the comment: I don't like the idea to magically introduce a '' section since this behaviour would be confusing for interpolation and not particularly discoverable by programmers. Let alone bikeshedding if this should rather be a None section. Using DEFAULTSECT for this purpose is equally wrong since it would silently inject default values to every section, which may or may not be desirable. All in all, it comes down to the question whether the programmer expects section-less configuration. If not, the '' section will not be helpful anyway. If yes, then it's desirable to be able to specify a section name for global options at *read time*. Symmetrically, the user could specify which section name to omit during configuration writing. I like that since it's explicit and more composable than a blanket global section. It would also be 100% backwards compatible. I'll prepare a patch for this idea so we can see how good this API looks like in practice. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 12:39:31 2014 From: report at bugs.python.org (Martin Teichmann) Date: Mon, 15 Sep 2014 10:39:31 +0000 Subject: [issue22412] Towards an asyncio-enabled command line In-Reply-To: <1410729335.06.0.363715018256.issue22412@psf.upfronthosting.co.za> Message-ID: <1410777571.19.0.753423517807.issue22412@psf.upfronthosting.co.za> Martin Teichmann added the comment: As promised, a new patch now for the current head. Last time I apparently got confused with how hg works, sorry. ---------- Added file: http://bugs.python.org/file36623/patch2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 13:55:36 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 15 Sep 2014 11:55:36 +0000 Subject: [issue22166] test_codecs leaks references In-Reply-To: <1407444567.64.0.0425446064781.issue22166@psf.upfronthosting.co.za> Message-ID: <20140915115533.2932.87108@mail.hg.python.org> Roundup Robot added the comment: New changeset fcf45ec7863e by Nick Coghlan in branch '3.4': Issue #22166: clear codec caches in test_codecs https://hg.python.org/cpython/rev/fcf45ec7863e New changeset 322ee2f2e922 by Nick Coghlan in branch 'default': Merge fix for issue #22166 from 3.4 https://hg.python.org/cpython/rev/322ee2f2e922 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 13:56:22 2014 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 15 Sep 2014 11:56:22 +0000 Subject: [issue22166] test_codecs leaks references In-Reply-To: <1407444567.64.0.0425446064781.issue22166@psf.upfronthosting.co.za> Message-ID: <1410782182.52.0.781441638908.issue22166@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 14:34:30 2014 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 15 Sep 2014 12:34:30 +0000 Subject: [issue22417] PEP 476: verify HTTPS certificates by default Message-ID: <1410784469.95.0.475937020841.issue22417@psf.upfronthosting.co.za> New submission from Nick Coghlan: Attached minimal patch updates http.client.HTTPSConnection to validate certs by default and adjusts test.test_httplib accordingly. It doesn't currently include any docs changes, or changes to urllib. The process wide "revert to the old behaviour" hook is to monkeypatch the ssl module: ssl._create_default_https_context = ssl._create_unverified_context To monkeypatch the stdlib to validate *everything* (this one isn't new, just noting it for the record): ssl._create_stdlib_context = ssl.create_default_context ---------- files: pep476_minimal_implementation.diff keywords: patch messages: 226912 nosy: alex, larry, ncoghlan priority: high severity: normal status: open title: PEP 476: verify HTTPS certificates by default type: enhancement Added file: http://bugs.python.org/file36624/pep476_minimal_implementation.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 15:00:33 2014 From: report at bugs.python.org (Alexander Weidinger) Date: Mon, 15 Sep 2014 13:00:33 +0000 Subject: [issue16095] urllib2 failing with squid proxy and digest authentication In-Reply-To: <1349023291.71.0.297566179231.issue16095@psf.upfronthosting.co.za> Message-ID: <1410786033.15.0.646630624862.issue16095@psf.upfronthosting.co.za> Alexander Weidinger added the comment: So, I analyzed the error and I think I found the problem. (urllib.request - Python 3.5.0) It all starts with l. 1079, as the 407 error gets handled, everything ok here, in l. 1081 http_error_auth_reqed(...) gets executed. So next, we are in l. 939, also everything correct here, retry_http_digest_auth gets executed in l. 953. (woops, "http_digest_auth"?!, nah, let's see what comes next) So we are in l. 953 and follow the code to come to the get_authorization(...) call. Now we are in l. 981, and in that part of the code lies the problem. To get the username and password for the proxy, the function find_user_password(realm, req.full_url) gets executed. An example, if my proxy has the address abc.com:8080 and my request is for xyz.com, the function tries to find a password for the xyz.com url, instead of the abc.com:8080 url. So it can't find a password and the whole auth process stops with the 407 error. But if you just change the line, to use the host, normal http digest auth doesn't work anymore, I would suggest? So it's also obvious why the workaround of toobaz works. -------------------------------------------------------- To solve the Problem, two auth handler would be needed, one for the proxy and one for normal http auth. Two different handlers were used in the basic auth, so I think it would be an consistent solution? ---------- nosy: +alexwe _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 15:19:10 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 15 Sep 2014 13:19:10 +0000 Subject: [issue22166] test_codecs leaks references In-Reply-To: <1407444567.64.0.0425446064781.issue22166@psf.upfronthosting.co.za> Message-ID: <1410787150.57.0.644026653048.issue22166@psf.upfronthosting.co.za> STINNER Victor added the comment: IMO test_codecs_fix1.patch is still needed. Review of Nick's change: + interp = PyThreadState_GET()->interp; + if (interp->codec_search_path == NULL) { + return -1; + } I don't think that this line raises an exception. You should use an assertion here (or raises an exception, but it would be overkill). + encodings._cache.pop(self.codec_name, None) + try: + _forget_codec(self.codec_name) + except KeyError: + pass You may move these lines to a private encoding._forget() function. By the way, codecs._forget() should maybe catch and ignore KeyError? > _TEST_CODECS.pop(self.codec_name, None) This line may be moved to set_codec() using self.addCleanup(). (Well, it's not directly related to your change.) ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 15:29:44 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 15 Sep 2014 13:29:44 +0000 Subject: [issue22166] test_codecs leaks references In-Reply-To: <1410787150.57.0.644026653048.issue22166@psf.upfronthosting.co.za> Message-ID: <5416E9C4.9080201@egenix.com> Marc-Andre Lemburg added the comment: On 15.09.2014 15:19, STINNER Victor wrote: > > STINNER Victor added the comment: > > IMO test_codecs_fix1.patch is still needed. > > Review of Nick's change: > > + interp = PyThreadState_GET()->interp; > + if (interp->codec_search_path == NULL) { > + return -1; > + } > > I don't think that this line raises an exception. Agreed. Please also add some documentation to the codecs.h file and perhaps a test for the function itself ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 15:36:07 2014 From: report at bugs.python.org (Jason Nadeau) Date: Mon, 15 Sep 2014 13:36:07 +0000 Subject: [issue22418] ipaddress.py new IPv6 Method for Solicited Multicast Address Message-ID: <1410788167.34.0.688511704657.issue22418@psf.upfronthosting.co.za> New submission from Jason Nadeau: I found it was useful to me to calculate and return an IPv6Address instance of the solicited multicast address for a particular IPv6Address. So I have created patch to do so. I am pretty new to programming in general so critiques are totally welcome. ---------- components: Library (Lib) files: solicitedMulticastAddress.patch keywords: patch messages: 226916 nosy: Jason.Nadeau priority: normal severity: normal status: open title: ipaddress.py new IPv6 Method for Solicited Multicast Address type: enhancement versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file36625/solicitedMulticastAddress.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 16:34:39 2014 From: report at bugs.python.org (Henning von Bargen) Date: Mon, 15 Sep 2014 14:34:39 +0000 Subject: [issue22139] python windows 2.7.8 64-bit did not install In-Reply-To: <1407238374.16.0.107772681213.issue22139@psf.upfronthosting.co.za> Message-ID: <1410791679.36.0.572463367884.issue22139@psf.upfronthosting.co.za> Henning von Bargen added the comment: Perhaps this issue should be re-opened. I stumbled across a similar issue today, and made some potentially useful observations. On a machine with an existing c:\python27 directory (Python 2.7.5), I installed Python 2.7.8 with the "install just for me" option into a new directory c:\python278. That's because there are several Python-based applications running; and I want to restrict the new Python version to one of them. The application uses a different executable, LisaReportingAgent.exe. Within the same environment (PATH first entry is c:\python278), calling python.exe, listing sys.path gives the expected output: C:\Lisa\Kronos\reporting\test\bin>c:\python278\python Python 2.7.8 (default, Jun 30 2014, 16:03:49) [MSC v.1500 32 bit (Intel)] on win 32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> for f in sys.path: print f ... C:\Lisa\Kronos\reporting\test c:\python278\python27.zip c:\python278\DLLs c:\python278\lib c:\python278\lib\plat-win c:\python278\lib\lib-tk c:\python278 c:\python278\lib\site-packages c:\python278\lib\site-packages\win32 c:\python278\lib\site-packages\win32\lib c:\python278\lib\site-packages\Pythonwin >>> ^Z Whereas the special executable's output is much different: C:\Lisa\Kronos\reporting\test\bin>..\..\bin\win32-x86\LisaReportingAgent.exe Python 2.7.5 (default, May 15 2013, 22:43:36) [MSC v.1500 32 bit (Intel)] on win 32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> for f in sys.path: print f ... C:\Lisa\Kronos\reporting\test C:\WINDOWS\system32\python27.zip C:\Python278\Lib C:\Python278\DLLs C:\Python278\Lib\lib-tk C:\Python27\Lib C:\Python27\DLLs C:\Python27\Lib\lib-tk C:\Lisa\Kronos\reporting\test\bin C:\Lisa\Kronos\reporting\bin\win32-x86 C:\Python27 C:\Python27\lib\site-packages C:\Python27\lib\site-packages\win32 C:\Python27\lib\site-packages\win32\lib C:\Python27\lib\site-packages\Pythonwin >>> Note the entries with c:\windows and with the different Python installation C:\python27. They are pointing to the old Python installation. The executable is built from the following C code (except for initializing a SWIG-generated Python wrapper for a PDF library): int main( int argc, char* argv[] ) { int rc = 0; /* ... setup a license key ... */ Py_SetProgramName(argv[0]); Py_Initialize(); /* ... init PDF library ... */ rc = Py_Main(argc, argv); Py_Finalize(); /* ... shut down PDF library ... */ return rc; } I've read something that Python 2.7 behaves differently on Windows regarding installation and setup in comparison to 2.6. It seems that the new python.exe performs registry magic? ---------- nosy: +Henning.von.Bargen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 16:46:12 2014 From: report at bugs.python.org (Henning von Bargen) Date: Mon, 15 Sep 2014 14:46:12 +0000 Subject: [issue22139] python windows 2.7.8 64-bit did not install In-Reply-To: <1407238374.16.0.107772681213.issue22139@psf.upfronthosting.co.za> Message-ID: <1410792372.51.0.5095407708.issue22139@psf.upfronthosting.co.za> Henning von Bargen added the comment: The online help says: """ When Python is hosted in another .exe (different directory, embedded via COM, etc), the ?Python Home? will not be deduced, so the core path from the registry is used. Other ?application paths? in the registry are always read. """ and """ If the environment variable PYTHONHOME is set, it is assumed as ?Python Home?. Otherwise, the path of the main Python executable is used to locate a ?landmark file? (Lib\os.py) to deduce the ?Python Home?. If a Python home is found, the relevant sub-directories added to sys.path (Lib, plat-win, etc) are based on that folder. Otherwise, the core Python path is constructed from the PythonPath stored in the registry. """ So I set PYTHONHOME=c:\python278, then call LisaReportingServer.exe again. Now the output for sys.path looks OK to me, but "import hmac" still fails: C:\Lisa\Kronos\reporting\test\bin>..\..\bin\win32-x86\LisaReportingAgent.exe Python 2.7.5 (default, May 15 2013, 22:43:36) [MSC v.1500 32 bit (Intel)] on win 32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> for f in sys.path: print f ... C:\Lisa\Kronos\reporting\test C:\WINDOWS\system32\python27.zip c:\python278\DLLs c:\python278\lib c:\python278\lib\plat-win c:\python278\lib\lib-tk C:\Lisa\Kronos\reporting\bin\win32-x86 c:\python278 c:\python278\lib\site-packages c:\python278\lib\site-packages\win32 c:\python278\lib\site-packages\win32\lib c:\python278\lib\site-packages\Pythonwin >>> import hmac Traceback (most recent call last): File "", line 1, in File "c:\python278\lib\hmac.py", line 8, in from operator import _compare_digest as compare_digest ImportError: cannot import name _compare_digest >>> ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 16:50:13 2014 From: report at bugs.python.org (Henning von Bargen) Date: Mon, 15 Sep 2014 14:50:13 +0000 Subject: [issue22139] python windows 2.7.8 64-bit did not install In-Reply-To: <1407238374.16.0.107772681213.issue22139@psf.upfronthosting.co.za> Message-ID: <1410792613.04.0.0831007477743.issue22139@psf.upfronthosting.co.za> Henning von Bargen added the comment: Sorry, of course it's NOT OK, because there's still C:\WINDOWS\system32\python27.zip as the second entry. BTW the relevant environment variables: Path=c:\python278;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;c:\lisa\Kronos\reporting\lib\win32-x86\pdfprint PYTHONHOME=c:\python278 PYTHONPATH=C:\Lisa\Kronos\reporting\test\bin\.. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 17:08:52 2014 From: report at bugs.python.org (Henning von Bargen) Date: Mon, 15 Sep 2014 15:08:52 +0000 Subject: [issue22139] python windows 2.7.8 64-bit did not install In-Reply-To: <1407238374.16.0.107772681213.issue22139@psf.upfronthosting.co.za> Message-ID: <1410793732.7.0.0829980844479.issue22139@psf.upfronthosting.co.za> Henning von Bargen added the comment: I don't see how this sys.path is related to the online help section "3.3.3. Finding modules". Where does c:\windows\python27.zip come from? And why does Python have to install anything in the Windows directory at all? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 17:34:48 2014 From: report at bugs.python.org (Henning von Bargen) Date: Mon, 15 Sep 2014 15:34:48 +0000 Subject: [issue22139] python windows 2.7.8 64-bit did not install In-Reply-To: <1407238374.16.0.107772681213.issue22139@psf.upfronthosting.co.za> Message-ID: <1410795288.54.0.301217212816.issue22139@psf.upfronthosting.co.za> Henning von Bargen added the comment: The only "solution" I could find was to give up running 2.7.8 next to 2.7.5, then uninstall 2.7.8, then install 2.7.8 with the "install for all users" option selected. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 17:36:49 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 15 Sep 2014 15:36:49 +0000 Subject: [issue22377] %Z in strptime doesn't match EST and others In-Reply-To: <1410301455.57.0.912701656833.issue22377@psf.upfronthosting.co.za> Message-ID: <1410795409.62.0.847245412328.issue22377@psf.upfronthosting.co.za> R. David Murray added the comment: I think its existing behavior is because it doesn't have access to a list of recognized timezones. As you say, this could be fixed by PEP 431. It could also be fixed by adopting the "email standard" timezones (see email/_parseaddr.py), which is a def-facto standard. Regardless of whether something is done to expand the number of timezone it knows about, though, there's a current doc bug that should be fixed. If someone wants to advocate for expanding the timezone list, that should be a separate issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 17:41:08 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 15 Sep 2014 15:41:08 +0000 Subject: [issue22379] Empty exception message of str.join In-Reply-To: <1410317691.24.0.990266868285.issue22379@psf.upfronthosting.co.za> Message-ID: <1410795668.82.0.00154364448966.issue22379@psf.upfronthosting.co.za> R. David Murray added the comment: The str of the exception will always be nonblank (it will contain the string 'TypeError' at a minimum). So you need to peel off the 'TypeError:' prefix before testing if you want to use str(e). That's why I suggested using args[0], but I suppose that might be a little more fragile. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 17:57:30 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 15 Sep 2014 15:57:30 +0000 Subject: [issue22139] python windows 2.7.8 64-bit did not install In-Reply-To: <1407238374.16.0.107772681213.issue22139@psf.upfronthosting.co.za> Message-ID: <1410796650.37.0.92019099823.issue22139@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Henning: if you have installed Python 2.7.5 "for all users", then this behavior is expected. Python finds python27.dll in system32, so even if you install 2.7.8 "just for me", it will still pick up 2.7.5 from system32. Installing different 2.7 versions on the same machine isn't really supported, although it should work if they are all installed "just for me". The operator module comes from python27.dll. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 18:36:35 2014 From: report at bugs.python.org (Henning von Bargen) Date: Mon, 15 Sep 2014 16:36:35 +0000 Subject: [issue22139] python windows 2.7.8 64-bit did not install In-Reply-To: <1407238374.16.0.107772681213.issue22139@psf.upfronthosting.co.za> Message-ID: <1410798995.65.0.715776339037.issue22139@psf.upfronthosting.co.za> Henning von Bargen added the comment: > Installing different 2.7 versions on the same machine isn't really supported, although it should work if they are all installed "just for me". Sigh... I've come to the same conclusion. Nevertheless it seems to me that the actual behavior is different from the online documentation "3.3.3 Finding modules" at https://docs.python.org/2/using/windows.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 18:39:08 2014 From: report at bugs.python.org (Alex Gaynor) Date: Mon, 15 Sep 2014 16:39:08 +0000 Subject: [issue22417] PEP 476: verify HTTPS certificates by default In-Reply-To: <1410784469.95.0.475937020841.issue22417@psf.upfronthosting.co.za> Message-ID: <1410799148.32.0.285444559205.issue22417@psf.upfronthosting.co.za> Changes by Alex Gaynor : ---------- nosy: +dstufft _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 19:08:15 2014 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 15 Sep 2014 17:08:15 +0000 Subject: [issue21472] Fix wsgiref handling of absolute HTTP Request-URI In-Reply-To: <1399807913.92.0.0240575633204.issue21472@psf.upfronthosting.co.za> Message-ID: <1410800895.52.0.547440899287.issue21472@psf.upfronthosting.co.za> Guido van Rossum added the comment: Wow. This is interesting. I thought that absolute URL support was only for proxies, but the spec you quote says clearly it should be supported as a transition towards always specifying the full URL. I guess they want to get rid of the Host: header? In any case I would worry (a bit) that this might cause security issues if implemented as naively as shown in your patch -- the other components of the URL should probably be validated against the configuration of the server. Also I am wondering whether specifying a different port or protocol (e.g. HTTPS) should be allowed or not, and what to do with extraneous parts of the path (in particular the "#fragment" identifier). You should probably also be careful with path-less domain names -- IIRC some URL parsers produce "" as the path for e.g. "http://python.org". Finally, AFAIK the HTTP 1.1 standard is full of ideas that few server implementations support, for various reasons, and it's possible that a future standard actually rescinds (or discourages) some features. Have you asked for the status of this particular feature? ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 19:13:54 2014 From: report at bugs.python.org (Devin Cook) Date: Mon, 15 Sep 2014 17:13:54 +0000 Subject: [issue672656] securing pydoc server Message-ID: <1410801234.67.0.325615993496.issue672656@psf.upfronthosting.co.za> Devin Cook added the comment: It looks like this bug was reintroduced in a5a3ae9be1fb. ---------- nosy: +devin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 19:25:14 2014 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 15 Sep 2014 17:25:14 +0000 Subject: [issue22416] Pickling compiled re patterns In-Reply-To: <1410770557.9.0.129599945661.issue22416@psf.upfronthosting.co.za> Message-ID: <1410801914.49.0.341035227867.issue22416@psf.upfronthosting.co.za> Guido van Rossum added the comment: But who says this isn't intended? I don't know why it was done this way, but the following reasoning might apply: we want to have a stable API for unpickling compiled regexps, but we want to be able to evolve the re.compile() API. Just the fact that '_compile' starts with an underscore doesn't mean that it may involve -- in fact, the fact that it is used by pickles says the opposite. Therefore I think the patch makes things worse (tying the pickle format to the public re.compile() method). At best we should add a comment to _compile explaining that its API is constrained by pickle backward compatibility. ---------- nosy: +gvanrossum resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 19:46:13 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 15 Sep 2014 17:46:13 +0000 Subject: [issue22418] ipaddress.py new IPv6 Method for Solicited Multicast Address In-Reply-To: <1410788167.34.0.688511704657.issue22418@psf.upfronthosting.co.za> Message-ID: <1410803173.51.0.0188134446435.issue22418@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +ncoghlan, pmoody _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 19:51:21 2014 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 15 Sep 2014 17:51:21 +0000 Subject: [issue22412] Towards an asyncio-enabled command line In-Reply-To: <1410729335.06.0.363715018256.issue22412@psf.upfronthosting.co.za> Message-ID: <1410803481.24.0.515331166833.issue22412@psf.upfronthosting.co.za> Guido van Rossum added the comment: OK. Trying to understand the patch, there seem to be three parts to it: (a) Changes to CPython to add a new flag to the exec/eval flags argument that sets the GENERATOR flag in the resulting code object. This seems the most fundamental, but it also feels the trickiest. It is a change to a built-in function so it must be supported by other Python implementations (esp. PyPy, Jython, IronPython, Cython). It also feels "wrong" -- it may be the case that you or your colleagues *want* to be able to write "yield from XXX" at the >>> prompt, but that doesn't make it a good idea. Especially since it will never be supported by the *regular* REPL -- it will only work in your customized REPL, but it isn't particularly obvious why it works there and not elsewhere. Also, I think supporting "yield from" in the repl() will teach the wrong thing -- people used to this working will attempt to use "yield from" at the top level in a script or module and be confused why it doesn't work there. I really think that it's must better to give them a helper function such as was shown early in the python-ideas thread. (Once imported, it's less typing too!) (b) Changes to the readline module to support some kind of async behavior, so that you can use the readline module's editing behavior from within an asyncio event loop. I can see the advantage of this, and I am not philosophically opposed (as I am for (a)). Without this, your users would either not have the benefit of convenient input editing, or you would have to reimplement the entire set of features of GNU readline afresh, which does sound excessive. However, once you give up on (a), you don't need (b) either. On the pragmatics of the patch, I don't have time to review it in detail, and I don't know if you can easily find anyone who does -- I just want to note that as it stands, there is a bug in the code, at least on OS X, since I get this: >>> import time, readline >>> time.sleep(1); readline._input() asd asd >>> python.exe(67432,0x7fff7d790310) malloc: *** error for object 0x7fc8506046f0: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug Abort trap: 6 (Immediately after the second input line, I quickly typed 'asd' and pressed Return. The 'asd' got echoed, I got a new >>> prompt, and then something crashed.) (c) A new function input() in the asyncio module. If (a) and (b) were accepted in Python, this might as well be part of your third-party module that implements your interactive shell, so there's not strictly a need for this. It also doesn't work on all platforms (e.g. I don't think it will work on Windows). My recommendation to you is to give up on (a) and instead add the suggested helper function to the globals in your own REPL, and tell your users to use that at the top-level. Python doesn't support yield-from at the top level in scripts and modules, and they may as well get used to that idea. You can still, separately, work on (b), but you will have to find someone in the core dev team who is motivated enough to help you make it work properly or fail safely (on platforms where it can't be made to work). For (c), I don't think that's ready for inclusion in the stdlib either (though perhaps we could add some descendant of it to Python 3.5 if you got (b) accepted). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 19:51:21 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 15 Sep 2014 17:51:21 +0000 Subject: [issue672656] securing pydoc server Message-ID: <1410803481.96.0.429521599549.issue672656@psf.upfronthosting.co.za> Ned Deily added the comment: Devin, please open a new issue describing the current problem you see. Comments to long-closed issues will likely be overlooked. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 20:06:26 2014 From: report at bugs.python.org (Devin Cook) Date: Mon, 15 Sep 2014 18:06:26 +0000 Subject: [issue22419] wsgiref request length Message-ID: <1410804386.26.0.756558523053.issue22419@psf.upfronthosting.co.za> New submission from Devin Cook: BaseHTTPRequestHandler limits request length to prevent DoS. WSGIRequestHandler should probably do the same. See: http://bugs.python.org/issue10714 ---------- components: Library (Lib) files: wsgiref_request_length.patch keywords: patch messages: 226931 nosy: devin priority: normal severity: normal status: open title: wsgiref request length type: security Added file: http://bugs.python.org/file36626/wsgiref_request_length.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 20:09:35 2014 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 15 Sep 2014 18:09:35 +0000 Subject: [issue21998] asyncio: a new self-pipe should be created in the child process after fork In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za> Message-ID: <1410804575.82.0.800825922333.issue21998@psf.upfronthosting.co.za> Guido van Rossum added the comment: That sounds about right -- it's a doc issue. Let me propose a paragraph: """ NOTE: It is not safe to share an asyncio event loop between processes that are related by os.fork(). If an event loop exists in a process, and that process is forked, the only safe operation on the loop in the child process is to call its close() method. """ (I don't want to have to research what the various polling primitives do on fork(), so I don't want to suggest that it's okay to close the loop in the parent and use it in the child.) A similar note should probably be added to the docs for the selectors module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 21:04:16 2014 From: report at bugs.python.org (Drekin) Date: Mon, 15 Sep 2014 19:04:16 +0000 Subject: [issue17620] Python interactive console doesn't use sys.stdin for input In-Reply-To: <1364921954.86.0.527255608282.issue17620@psf.upfronthosting.co.za> Message-ID: <1410807856.0.0.951089450221.issue17620@psf.upfronthosting.co.za> Drekin added the comment: I have found another problem. PyOS_Readline can be called from two different places ? from Parser/tokenizer.c:tok_nextc (by REPL), which uses sys.stdin.encoding to encode prompt argument, and from Python/bltinmodule.c:builtin_input_impl (by input() function), which uses sys.stdout.encoding. So readline hook cannot be implemented correctly if sys.stdin and sys.stdout don't have the same encoding. Either the tokenizer should have two encodings ? one for input and one for output - or better no encoding at all and should use Python string based alternative to PyOS_Readline, which could be added. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 21:07:22 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 15 Sep 2014 19:07:22 +0000 Subject: [issue22418] ipaddress.py new IPv6 Method for Solicited Multicast Address In-Reply-To: <1410788167.34.0.688511704657.issue22418@psf.upfronthosting.co.za> Message-ID: <1410808042.17.0.333147302271.issue22418@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 21:15:20 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 15 Sep 2014 19:15:20 +0000 Subject: [issue22420] Use print(file=sys.stderr) instead of sys.stderr.write() in IDLE Message-ID: <1410808520.06.0.74767353905.issue22420@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch replaces print(file=sys.stderr) by sys.stderr.write() in IDLE for same reason as in issue22384. May be this will eliminate some "crashes" when IDLE run with pythonw.exe. ---------- components: IDLE files: idle_print_stderr.patch keywords: patch messages: 226934 nosy: serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Use print(file=sys.stderr) instead of sys.stderr.write() in IDLE versions: Python 2.7, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file36627/idle_print_stderr.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 21:15:48 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 15 Sep 2014 19:15:48 +0000 Subject: [issue22420] Use print(file=sys.stderr) instead of sys.stderr.write() in IDLE In-Reply-To: <1410808520.06.0.74767353905.issue22420@psf.upfronthosting.co.za> Message-ID: <1410808548.12.0.0539559094819.issue22420@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +kbk, roger.serwy, terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 21:16:58 2014 From: report at bugs.python.org (Devin Cook) Date: Mon, 15 Sep 2014 19:16:58 +0000 Subject: [issue22421] securing pydoc server Message-ID: <1410808618.63.0.0937681366512.issue22421@psf.upfronthosting.co.za> New submission from Devin Cook: Several years ago a patch was applied to set the default binding of the pydoc server to "localhost" instead of "0.0.0.0". It appears that the issue was reintroduced in a5a3ae9be1fb. See previous issue: http://bugs.python.org/issue672656 $ ./python -m pydoc -b Server ready at http://localhost:35593/ Server commands: [b]rowser, [q]uit server> --- $ netstat -lnp | grep python tcp 0 0 0.0.0.0:35593 0.0.0.0:* LISTEN 2780/python As a sidenote, I'm not sure why the localhost lookup breaks the test case on my linux machine, but it does. ---------- components: Library (Lib) files: pydoc_server_addr.patch keywords: patch messages: 226935 nosy: devin priority: normal severity: normal status: open title: securing pydoc server type: security Added file: http://bugs.python.org/file36628/pydoc_server_addr.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 21:41:18 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 15 Sep 2014 19:41:18 +0000 Subject: [issue22253] ConfigParser does not handle files without sections In-Reply-To: <1408731768.17.0.221948826268.issue22253@psf.upfronthosting.co.za> Message-ID: <1410810078.41.0.0909271723289.issue22253@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I read the rsyncd.conf doc at http://linux.die.net/man/5/rsyncd.conf (linked from the StackOverflow question). These files are not .ini files. However, I believe the parsing rules are mostly compatible with RawConfigParser, or could be made so by using existing customization options, including subclassing. The sectionless options are called 'global options' for one of two different reasons. Some, selected from a predefined list of startup options, act as if they were in a [STARTUP] section. Others, selected from a predefined list of module options, act as if they were in a [DEFAULT] section. The latter provide alternate default value for options in the various [] sections. We clearly should not directly support the specialized rules of rsyncd.conf. But if, as kernc requests, RawConfigParser gathered sectionless options into a '' section, users could probably work with these files. The details would be up to them, or a config_unix module writer. The same comment applies to other files, including .ini files with sectionless options. ?ukasz, the only one bikeshedding '' is you. I do not see any need for a new API and I think it just confuses this issue. Reading and writing sectionless options via a '' section should be sufficient to work with .ini files. To me, the remaining question is whether to retain configparser.MissingSectionHeaderError. The problem with piggy-backing its optional use on the 'strict' parameter is that someone might want to reject duplicates while reading sectionless options. But it ia a plausible idea. As an aside, the documentation for MissingSectionHeaderError is currently a bit confused. The docstring correctly says "Raised when a key-value pair is found before any section header." The doc incorrectly says "Exception raised when attempting to parse a file which has no section headers." I tested and it is indeed raised even when there is a section header after an initial option line. The exception message is also wrong: "File contains no section headers." The latter two should really say that the files does not *start* with a section header (ignoring comment lines), or use the wording of the docstring. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 22:05:04 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 15 Sep 2014 20:05:04 +0000 Subject: [issue22420] Use print(file=sys.stderr) instead of sys.stderr.write() in IDLE In-Reply-To: <1410808520.06.0.74767353905.issue22420@psf.upfronthosting.co.za> Message-ID: <1410811504.45.0.821899415667.issue22420@psf.upfronthosting.co.za> Terry J. Reedy added the comment: You meant it the other way around 'replace sys.stderr.write() by print(file=sys.stderr)'. In the two cases where Idle exits anyway, this will not make any difference (except possible in the return code). In the other cases where Idle tries to continue, this will. The real fix needed is to replace stderr, at least when None, so that the messages are displayed in a gui widget. However, if I cannot do that this week, before 3.4.2, I will apply this. Thanks for the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 22:38:12 2014 From: report at bugs.python.org (Devin Cook) Date: Mon, 15 Sep 2014 20:38:12 +0000 Subject: [issue672656] securing pydoc server Message-ID: <1410813492.34.0.413061609177.issue672656@psf.upfronthosting.co.za> Devin Cook added the comment: Sure, thanks. New issue: http://bugs.python.org/issue22421 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 15 22:52:55 2014 From: report at bugs.python.org (Geert Jansen) Date: Mon, 15 Sep 2014 20:52:55 +0000 Subject: [issue21965] Add support for Memory BIO to _ssl In-Reply-To: <1405156134.57.0.513965198344.issue21965@psf.upfronthosting.co.za> Message-ID: <1410814375.93.0.117199002348.issue21965@psf.upfronthosting.co.za> Geert Jansen added the comment: Antoine, sorry for the delay, we just had a new kid and I changed jobs :) Let me try if I can create an updated patch that where SSLObject is a mixin for SSLSocket. I think the argument about writing tests once is important. Be back in a few days.. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 16 00:10:20 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 15 Sep 2014 22:10:20 +0000 Subject: [issue22139] python windows 2.7.8 64-bit did not install In-Reply-To: <1407238374.16.0.107772681213.issue22139@psf.upfronthosting.co.za> Message-ID: <1410819020.98.0.305515443155.issue22139@psf.upfronthosting.co.za> Martin v. L?wis added the comment: How so? Every single sentence in this section is absolutely correct. It just doesn't talk about finding builtin modules at all, only about modules found on the Python path (.py and .pyd files). Builtin modules don't have to be found, because they are, well, built in. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 16 08:57:02 2014 From: report at bugs.python.org (Martin Teichmann) Date: Tue, 16 Sep 2014 06:57:02 +0000 Subject: [issue22412] Towards an asyncio-enabled command line In-Reply-To: <1410729335.06.0.363715018256.issue22412@psf.upfronthosting.co.za> Message-ID: <1410850622.72.0.723172780013.issue22412@psf.upfronthosting.co.za> Martin Teichmann added the comment: well, I beg to differ. Again, to your points: to a) You claim that my flag would have to be supported by every python platform. Well, the very same built-in function has another flag, PyCF_ONLY_AST, whose precise meaning, according to the docs, "might change with each Python release". And I am not sure if all your mentioned distributions (PyPy, Jython, IronPython, Cython) will ever have an actually compatible support for PyCF_ONLY_AST. While I think that it would be not too hard to support my GENERATOR flag on those platforms (maybe except Cython). to b) This is by far the most important part of my patch, something like this certainly should go into CPython. I am actually of the opinion that something like it is very important even without a) getting accepted. I just looked at the event loop of IPython, what they are doing there is just sheer horror: First they have to cripple each event loop they support (be it Qt, GTK or WX) to accept only some events at a time. Then they use ctypes (yes, ctypes: they cannot do it in Python!) to install this as a hook to PyOS_InputHook, a function so undocumented even google couldn't find docs (but many discussions where people had major problems properly using it). All of this would be solved with an input function which does not block I/O. All the event loops (including the asyncio event loop) would just install a callback on stdin and call my input once they need to. I am certainly open to all kinds of proposals on how it precisely should work, and sure bugs need to be fixed. c) sure, with b) accepted c) is just trivial. It was a mere example of the usage of b). b) was written under the principle "write as much as you can in python, only the bare minimum in C" which I think is a good idea given that it is so much nicer to program in Python than in C. The fact that it would not work under Windows to me is actually not a point, we would just have to make it run under Windows with different means (unfortunately, I'm not such a Windows expert that I would now which those means would be). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 16 09:51:50 2014 From: report at bugs.python.org (Brunel) Date: Tue, 16 Sep 2014 07:51:50 +0000 Subject: [issue22422] IDLE closes all when in dropdown menu Message-ID: <1410853910.37.0.784487772035.issue22422@psf.upfronthosting.co.za> New submission from Brunel: While python shell is running if the user puts a period after a statement and waits for the dropdown list to pop up, then closes python shell the following will happen: IDLE will close all active windows immediately, regardless of any unsaved progress (which is lost.) ---------- components: IDLE messages: 226942 nosy: mandolout priority: normal severity: normal status: open title: IDLE closes all when in dropdown menu type: crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 16 10:34:46 2014 From: report at bugs.python.org (Yongzhi Pan) Date: Tue, 16 Sep 2014 08:34:46 +0000 Subject: [issue22379] Empty exception message of str.join In-Reply-To: <1410317691.24.0.990266868285.issue22379@psf.upfronthosting.co.za> Message-ID: <1410856486.29.0.890522723513.issue22379@psf.upfronthosting.co.za> Yongzhi Pan added the comment: I tested it and find str of an exception does not contain the exception type: >>> a = TypeError() >>> str(a) '' >>> a = TypeError('b', 3) >>> a.args ('b', 3) >>> str(a) "('b', 3)" Am I missing some other circumstances? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 16 10:37:10 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 16 Sep 2014 08:37:10 +0000 Subject: [issue22423] Errors in printing exceptions raised in a thread Message-ID: <1410856630.14.0.274476260629.issue22423@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch fixes some bugs in printing exceptions in the threading module. 1. Fixed names of private variables in initialization. This caused unhandled AttributeError. The regression was introduced in changeset e71c3223810f. This part of the patch shouldn't be applied to 2.7. 2. Handled the case when sys.stderr is None. Perhaps this caused a crash when Python program run with pythonw.exe. 3. Added missed test. ---------- components: Library (Lib) files: threading_print_exception.patch keywords: patch messages: 226944 nosy: pitrou, serhiy.storchaka, terry.reedy priority: normal severity: normal stage: patch review status: open title: Errors in printing exceptions raised in a thread type: behavior versions: Python 2.7, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file36629/threading_print_exception.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 16 10:40:08 2014 From: report at bugs.python.org (Rob Agar) Date: Tue, 16 Sep 2014 08:40:08 +0000 Subject: [issue14285] Traceback wrong on ImportError while executing a package In-Reply-To: <1331621436.28.0.000669565075438.issue14285@psf.upfronthosting.co.za> Message-ID: <1410856808.49.0.937835605515.issue14285@psf.upfronthosting.co.za> Changes by Rob Agar : ---------- nosy: +robagar _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 16 10:43:37 2014 From: report at bugs.python.org (Rob Agar) Date: Tue, 16 Sep 2014 08:43:37 +0000 Subject: [issue14285] Traceback wrong on ImportError while executing a package In-Reply-To: <1331621436.28.0.000669565075438.issue14285@psf.upfronthosting.co.za> Message-ID: <1410857017.64.0.890879263166.issue14285@psf.upfronthosting.co.za> Rob Agar added the comment: The message also needs to include the file and line number of the ImportError. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 16 11:52:25 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 16 Sep 2014 09:52:25 +0000 Subject: [issue17120] Mishandled _POSIX_C_SOURCE and _XOPEN_SOURCE in pyconfig.h In-Reply-To: <1359956347.87.0.611737971795.issue17120@psf.upfronthosting.co.za> Message-ID: <1410861145.94.0.986474264018.issue17120@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 16 12:10:45 2014 From: report at bugs.python.org (Bob Chen) Date: Tue, 16 Sep 2014 10:10:45 +0000 Subject: [issue22231] httplib: unicode url will cause an ascii codec error when combined with a utf-8 string header In-Reply-To: <1408502977.94.0.555848371144.issue22231@psf.upfronthosting.co.za> Message-ID: <1410862245.92.0.139047268548.issue22231@psf.upfronthosting.co.za> Bob Chen added the comment: up... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 16 13:34:05 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 16 Sep 2014 11:34:05 +0000 Subject: [issue22421] securing pydoc server In-Reply-To: <1410808618.63.0.0937681366512.issue22421@psf.upfronthosting.co.za> Message-ID: <1410867245.61.0.527267090305.issue22421@psf.upfronthosting.co.za> Senthil Kumaran added the comment: The localhost breaking on your linux system might be due to improper /etc/hosts or is localhost pointing to an ipv6 address? That said, I think it is okay to rely on 127.0.0.1 as host for running pydoc server. I am unsure why the initial check was done only for mac (and windows and linux are left to use localhost). ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 16 14:11:10 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 16 Sep 2014 12:11:10 +0000 Subject: [issue22407] re.LOCALE is nonsensical for Unicode In-Reply-To: <1410709398.9.0.134852560063.issue22407@psf.upfronthosting.co.za> Message-ID: <1410869470.86.0.902818128796.issue22407@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 16 14:11:17 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 16 Sep 2014 12:11:17 +0000 Subject: [issue22407] re.LOCALE is nonsensical for Unicode In-Reply-To: <1410709398.9.0.134852560063.issue22407@psf.upfronthosting.co.za> Message-ID: <1410869477.04.0.0108038558979.issue22407@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- components: +Unicode _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 16 14:12:39 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 16 Sep 2014 12:12:39 +0000 Subject: [issue22400] Stable API broken on Windows for PyUnicode_* In-Reply-To: <1410651104.92.0.853615369335.issue22400@psf.upfronthosting.co.za> Message-ID: <1410869559.81.0.276364941572.issue22400@psf.upfronthosting.co.za> STINNER Victor added the comment: I think this issue was already fixed by this change: changeset: 88287:ea0aa3e32ab5 branch: 3.3 parent: 88263:203ca77ea819 user: Martin v. L?wis date: Sat Jan 04 10:01:42 2014 +0100 files: Misc/NEWS PC/python3.def description: Issue #17432: Drop UCS2 from names of Unicode functions in python3.def. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 16 14:36:32 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 16 Sep 2014 12:36:32 +0000 Subject: [issue22407] re.LOCALE is nonsensical for Unicode In-Reply-To: <1410709398.9.0.134852560063.issue22407@psf.upfronthosting.co.za> Message-ID: <1410870992.9.0.200595296146.issue22407@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I don't think we should fix this in 2.x: some people may rely on the old behaviour, and it will be difficult for them to debug. In 3.x, I simply propose we deprecate re.LOCALE for unicode strings and make it a no-op. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 16 14:41:52 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 16 Sep 2014 12:41:52 +0000 Subject: [issue22421] securing pydoc server In-Reply-To: <1410808618.63.0.0937681366512.issue22421@psf.upfronthosting.co.za> Message-ID: <1410871312.75.0.00440354610683.issue22421@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- stage: -> patch review versions: +Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 16 15:00:18 2014 From: report at bugs.python.org (Kushal Das) Date: Tue, 16 Sep 2014 13:00:18 +0000 Subject: [issue21270] unittest.mock.call object has inherited count method In-Reply-To: <1397681359.44.0.204245756188.issue21270@psf.upfronthosting.co.za> Message-ID: <1410872418.08.0.653917607582.issue21270@psf.upfronthosting.co.za> Kushal Das added the comment: Uploading the second version of the patch. ---------- Added file: http://bugs.python.org/file36630/issue21270_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 16 15:04:18 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 16 Sep 2014 13:04:18 +0000 Subject: [issue21270] unittest.mock.call object has inherited count method In-Reply-To: <1397681359.44.0.204245756188.issue21270@psf.upfronthosting.co.za> Message-ID: <20140916130348.26497.91007@mail.hg.python.org> Roundup Robot added the comment: New changeset 5660c1bdc2b6 by Kushal Das in branch 'default': Closes #21270 : We now override tuple methods in mock.call objects. https://hg.python.org/cpython/rev/5660c1bdc2b6 ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 16 16:05:42 2014 From: report at bugs.python.org (bono wang) Date: Tue, 16 Sep 2014 14:05:42 +0000 Subject: [issue22424] make: *** [Objects/unicodeobject.o] Error 1 Message-ID: <1410876342.53.0.936022553795.issue22424@psf.upfronthosting.co.za> New submission from bono wang: when i was upgrade from py 2.6 to py 3.3 the error is show up # make && make install gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Parser/acceler.o Parser/acceler.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Parser/grammar1.o Parser/grammar1.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Parser/listnode.o Parser/listnode.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Parser/node.o Parser/node.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Parser/parser.o Parser/parser.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Parser/bitset.o Parser/bitset.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Parser/metagrammar.o Parser/metagrammar.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Parser/firstsets.o Parser/firstsets.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Parser/grammar.o Parser/grammar.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Parser/pgen.o Parser/pgen.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Parser/myreadline.o Parser/myreadline.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Parser/parsetok.o Parser/parsetok.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Parser/tokenizer.o Parser/tokenizer.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/abstract.o Objects/abstract.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/accu.o Objects/accu.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/boolobject.o Objects/boolobject.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/bytes_methods.o Objects/bytes_methods.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/bytearrayobject.o Objects/bytearrayobject.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/bytesobject.o Objects/bytesobject.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/cellobject.o Objects/cellobject.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/classobject.o Objects/classobject.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/codeobject.o Objects/codeobject.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/complexobject.o Objects/complexobject.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/descrobject.o Objects/descrobject.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/enumobject.o Objects/enumobject.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/exceptions.o Objects/exceptions.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/genobject.o Objects/genobject.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/fileobject.o Objects/fileobject.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/floatobject.o Objects/floatobject.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/frameobject.o Objects/frameobject.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/funcobject.o Objects/funcobject.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/iterobject.o Objects/iterobject.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/listobject.o Objects/listobject.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/longobject.o Objects/longobject.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/dictobject.o Objects/dictobject.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/memoryobject.o Objects/memoryobject.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/methodobject.o Objects/methodobject.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/moduleobject.o Objects/moduleobject.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/namespaceobject.o Objects/namespaceobject.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/object.o Objects/object.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/obmalloc.o Objects/obmalloc.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/capsule.o Objects/capsule.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/rangeobject.o Objects/rangeobject.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/setobject.o Objects/setobject.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/sliceobject.o Objects/sliceobject.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/structseq.o Objects/structseq.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/tupleobject.o Objects/tupleobject.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/typeobject.o Objects/typeobject.c gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/unicodeobject.o Objects/unicodeobject.c gcc: Internal error: Killed (program cc1) Please submit a full bug report. See for instructions. make: *** [Objects/unicodeobject.o] Error 1 i really dont know how to fix it ---------- messages: 226952 nosy: 165559672 priority: normal severity: normal status: open title: make: *** [Objects/unicodeobject.o] Error 1 versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 16 16:44:31 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 16 Sep 2014 14:44:31 +0000 Subject: [issue22424] make: *** [Objects/unicodeobject.o] Error 1 In-Reply-To: <1410876342.53.0.936022553795.issue22424@psf.upfronthosting.co.za> Message-ID: <1410878671.2.0.251456958698.issue22424@psf.upfronthosting.co.za> STINNER Victor added the comment: > i really dont know how to fix it It's a GCC bug, not a Python bug: "gcc: Internal error: ...". What is your OS? What is your GCC version? How much memory do you have? Do you get the same error if you run "make" again? Try to run "gcc -pthread -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/unicodeobject.o" again. Do you modify MAKEFLAGS to set -j to run GCC in parallel? Usually, you can workaround GCC bugs by disabling optimizations. You can try to modify Makefile to replace "-O3" with "-O2" or even "-O0" (disable all optimizations), and then try to run "make" again. Again, it's not a Python bug, but a GCC bug, probably already fixed in a more recent GCC version (the latest is 4.9.1): https://gcc.gnu.org/ ---------- nosy: +haypo -165559672 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 16 17:01:13 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 16 Sep 2014 15:01:13 +0000 Subject: [issue22421] securing pydoc server In-Reply-To: <1410808618.63.0.0937681366512.issue22421@psf.upfronthosting.co.za> Message-ID: <1410879673.94.0.18663487525.issue22421@psf.upfronthosting.co.za> Senthil Kumaran added the comment: sys.platform is darwin since OS X 10.5. I am not sure when it's value was 'mac', So effectively the host was localhost on mac systems. Directly setting the host value to localhost on all platforms may be right thing to do. Here is a patch with tests. ---------- assignee: -> orsenthil Added file: http://bugs.python.org/file36631/issue22421.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 16 17:02:28 2014 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 16 Sep 2014 15:02:28 +0000 Subject: [issue22418] ipaddress.py new IPv6 Method for Solicited Multicast Address In-Reply-To: <1410788167.34.0.688511704657.issue22418@psf.upfronthosting.co.za> Message-ID: <1410879748.41.0.97722105792.issue22418@psf.upfronthosting.co.za> Eric V. Smith added the comment: Changing to 3.5 only, as this is an API addition so it can only be added there. I think that raising an exception instead of retuning None for a multicast address would be a better API. Any chance you can write some tests? Thanks! ---------- nosy: +eric.smith stage: -> test needed versions: -Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 16 17:04:14 2014 From: report at bugs.python.org (Jeremy Kloth) Date: Tue, 16 Sep 2014 15:04:14 +0000 Subject: [issue22400] Stable API broken on Windows for PyUnicode_* In-Reply-To: <1410651104.92.0.853615369335.issue22400@psf.upfronthosting.co.za> Message-ID: <1410879854.05.0.953891778943.issue22400@psf.upfronthosting.co.za> Jeremy Kloth added the comment: Ah, yes indeeed. Sorry for the noise as it was that my local repos were having some syncing issues so I had out of date sources. Marking as closed (fixed) and duplicate of issue17432. ---------- resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 16 17:09:57 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 16 Sep 2014 15:09:57 +0000 Subject: [issue22400] Stable API broken on Windows for PyUnicode_* In-Reply-To: <1410651104.92.0.853615369335.issue22400@psf.upfronthosting.co.za> Message-ID: <1410880197.44.0.241794210581.issue22400@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 16 17:40:50 2014 From: report at bugs.python.org (bono wang) Date: Tue, 16 Sep 2014 15:40:50 +0000 Subject: [issue22424] make: *** [Objects/unicodeobject.o] Error 1 In-Reply-To: <1410876342.53.0.936022553795.issue22424@psf.upfronthosting.co.za> Message-ID: <1410882050.74.0.0812703861447.issue22424@psf.upfronthosting.co.za> bono wang added the comment: Usually, you can workaround GCC bugs by disabling optimizations. You can try to modify Makefile to replace "-O3" with "-O2" or even "-O0" (disable all optimizations), and then try to run "make" again. done thanks a lot ---------- nosy: +165559672 resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 16 17:49:55 2014 From: report at bugs.python.org (mouad) Date: Tue, 16 Sep 2014 15:49:55 +0000 Subject: [issue21472] Fix wsgiref handling of absolute HTTP Request-URI In-Reply-To: <1399807913.92.0.0240575633204.issue21472@psf.upfronthosting.co.za> Message-ID: <1410882595.58.0.685962258939.issue21472@psf.upfronthosting.co.za> mouad added the comment: Hi Guido, If I understand this correctly, the HOST header was added only in HTTP1.1 and setting the absolute URI was the right behavior client should follow if they are behind a proxy for HTTP1.0, but the same behavior was kept in HTTP1.1 for backward compatibility. > In any case I would worry (a bit) that this might cause security issues if > implemented as naively as shown in your patch, > the other components of the URL should probably be validated against the > configuration of the server. > Also I am wondering whether specifying a different port or protocol (e.g. > HTTPS) should be allowed or not. If there should be a validation, I think it should be done in BaseHTTPRequestHandler, FWIW this later doesn't validate HOST header neither, just tested sending a request to "python -mhttp.server" which succeeded. $ telnet 127.0.0.1 8000 GET /dummy HTTP/1.1 HOST google.com One thing to note here for future work for the validation part, is that according to http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.2, first point: If Request-URI is an absoluteURI, the host is part of the Request-URI. Any Host header field value in the request MUST be ignored. > and what to do with extraneous parts of the path (in particular the > "#fragment" identifier) AFAIK clients are not supposed to send fragments to servers, and I didn't find in the HTTP spec what should happen if they do, CherryPy for example (link of the code is in the footer) will raise 400 if request URI include the #fragment part. An other thing that CherryPy guys also did, is that ``HTTPRequest(...).path`` will always return a relativ path, which is IMHO the right behavior but for backward compatibility I hesitate fixing this problem directly in BaseHTTPRequestHandler or should we ? > You should probably also be careful with path-less domain names -- IIRC some > URL parsers produce "" as the path for e.g. "http://python.org". According to the PEP-0333 the PATH_INFO can be empty: PATH_INFO The remainder of the request URL's "path", designating the virtual "location" of the request's target within the application. This may be an empty string, if the request URL targets the application root and does not have a trailing slash. > Have you asked for the status of this particular feature? I sent an email to python WEB-SIG mailing list trying to gather information about this behavior, but not luck yet :( At this point I would like to link to both CherryPy and Werkzeug that already handle this behavior. Werkzeug: https://github.com/mitsuhiko/werkzeug/blob/0.9.6/werkzeug/serving.py#L75-81 CherryPy: https://github.com/cherrypy/cherrypy/blob/cherrypy-3.2.2rc1/cherrypy/wsgiserver/wsgiserver3.py#L633-638. As a side note, I have already said in my email to the WEB-sig kudos to cherrypy guys, the funny part is that I am starting to think that they succeeded in both my tests because they didn't rely on core python implementation of BaseHTTPRequestHandler (I guess reinventing the wheel sometime works :)), at the opposite to other frameworks that showed this problems :). Cheers, ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 16 18:07:48 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 16 Sep 2014 16:07:48 +0000 Subject: [issue22424] make: *** [Objects/unicodeobject.o] Error 1 In-Reply-To: <1410876342.53.0.936022553795.issue22424@psf.upfronthosting.co.za> Message-ID: <1410883668.05.0.0635019243769.issue22424@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: -165559672 resolution: fixed -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 16 18:11:02 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 16 Sep 2014 16:11:02 +0000 Subject: [issue22407] re.LOCALE is nonsensical for Unicode In-Reply-To: <1410870992.9.0.200595296146.issue22407@psf.upfronthosting.co.za> Message-ID: <1517987.ehv9QctU5f@raxxla> Serhiy Storchaka added the comment: Yes, one of solution is to deprecate re.LOCALE for unicode strings and then make it incompatible with unicode strings. But I think it would be good to implement locale-aware matching. Example. >>> for a in 'Ii\u0130\u0131': ... for b in 'Ii\u0130\u0131': ... if a != b and re.match(a, b, re.I): print(a, '~', b) ... I ~ i I ~ ? i ~ I i ~ ? ? ~ I ? ~ i This is incorrect result in Turkish. Capital dotless "I" matches capital "?" with dot above, and small dotless "?" doesn't match anything. Regex produces more relevant output, which includes matches for Turkish and English: I ~ i I ~ ? i ~ I i ~ ? ? ~ i ? ~ I With locale tr_TR.utf8 (with the patch): >>> for a in 'Ii\u0130\u0131': ... for b in 'Ii\u0130\u0131': ... if a != b and re.match(a, b, re.I|re.L): print(a, '~', b) ... I ~ ? i ~ ? ? ~ i ? ~ I This is correct result in Turkish. Therefore there is a use case for this feature. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 16 18:12:50 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 16 Sep 2014 16:12:50 +0000 Subject: [issue22407] re.LOCALE is nonsensical for Unicode In-Reply-To: <1410709398.9.0.134852560063.issue22407@psf.upfronthosting.co.za> Message-ID: <1410883970.43.0.478977858781.issue22407@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ha, I always forget about the Turkish locale case... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 16 18:52:52 2014 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 16 Sep 2014 16:52:52 +0000 Subject: [issue22412] Towards an asyncio-enabled command line In-Reply-To: <1410729335.06.0.363715018256.issue22412@psf.upfronthosting.co.za> Message-ID: <1410886372.59.0.193266733795.issue22412@psf.upfronthosting.co.za> Guido van Rossum added the comment: There's a sage piece of advice somewhere in the developer docs. "Know when to give up." I think you need to write a PEP trying to argue that supporting "yield from" in the REPL is essential to a large category of users, so you can lobby for support. In the mean time, you have not even responded to the repeated option of providing a simple helper function. If you are concerned about integrating with a platform-provide UI, perhaps you can use a second thread? Asyncio and threads actually have a well-defined interface. I am actually more sympathetic to getting the readline thing fixed -- perhaps you can work with the IPython folks on a proposal. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 16 19:47:47 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 16 Sep 2014 17:47:47 +0000 Subject: [issue22379] Empty exception message of str.join In-Reply-To: <1410317691.24.0.990266868285.issue22379@psf.upfronthosting.co.za> Message-ID: <1410889667.76.0.500632084091.issue22379@psf.upfronthosting.co.za> R. David Murray added the comment: No, you are right and I am wrong. I should have checked myself :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 16 21:42:07 2014 From: report at bugs.python.org (Martin Teichmann) Date: Tue, 16 Sep 2014 19:42:07 +0000 Subject: [issue22412] Towards an asyncio-enabled command line In-Reply-To: <1410729335.06.0.363715018256.issue22412@psf.upfronthosting.co.za> Message-ID: <1410896527.18.0.533259988242.issue22412@psf.upfronthosting.co.za> Martin Teichmann added the comment: Well, so I am giving up, apparenty my work is not wanted here. But not before submitting at least the last version of my patch. I seperated out my _input function into two, start_input and continue_input, which are supposed to work in a loop as in start_input(prompt) while True: r = continue_input() if r is not None: return r This would help at least people like IPython. ---------- Added file: http://bugs.python.org/file36632/patch3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 16 21:51:05 2014 From: report at bugs.python.org (Martin Teichmann) Date: Tue, 16 Sep 2014 19:51:05 +0000 Subject: [issue22412] Towards an asyncio-enabled command line In-Reply-To: <1410729335.06.0.363715018256.issue22412@psf.upfronthosting.co.za> Message-ID: <1410897065.14.0.531836344651.issue22412@psf.upfronthosting.co.za> Martin Teichmann added the comment: And as a last comment, just for completeness, a complete async console. With it you can do cool things like >>> from asyncio import sleep, async >>> def f(): ... yield from sleep(3) ... print("done") >>> yield from f() [after 3 seconds] done >>> async(f()) >>> [wait another 3 seconds] done Just see how async puts something in the background, while yield from keeps it up, and how the event loop runs even while we're doing nothing! Let's hope other projects out there are more open to making their event loops asyncio-compatible than CPython is - otherwise asyncio will soon cease to exist. ---------- Added file: http://bugs.python.org/file36633/cl.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 16 23:00:27 2014 From: report at bugs.python.org (Simon Weber) Date: Tue, 16 Sep 2014 21:00:27 +0000 Subject: [issue22425] 2to3 import fixer writes dotted_as_names into import_as_names Message-ID: <1410901227.13.0.545813784004.issue22425@psf.upfronthosting.co.za> New submission from Simon Weber: When dealing with implicit relative imports of the form "import as...", the 2to3 import fixer will rewrite them as "from . import as...". This is invalid syntax. Here's an example: $ tree package/ package/ ??? __init__.py ??? rootmod.py ??? subpackage ??? __init__.py ??? mod.py 1 directory, 4 files $ cat package/rootmod.py # this is the only nonempty file import subpackage.mod as my_name $ python package/rootmod.py $ 2to3 -w -f import package/ RefactoringTool: Refactored package/rootmod.py --- package/rootmod.py (original) +++ package/rootmod.py (refactored) @@ -1 +1 @@ -import subpackage.mod as my_name +from . import subpackage.mod as my_name RefactoringTool: Files that were modified: RefactoringTool: package/rootmod.py $ python package/rootmod.py File "package/rootmod.py", line 1 from . import subpackage.mod as my_name ^ SyntaxError: invalid syntax Probably the easiest way to rewrite this is "from .subpackage import mod as my_name". ---------- components: 2to3 (2.x to 3.x conversion tool) messages: 226965 nosy: simonmweber priority: normal severity: normal status: open title: 2to3 import fixer writes dotted_as_names into import_as_names type: behavior versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 16 23:59:07 2014 From: report at bugs.python.org (Akira Li) Date: Tue, 16 Sep 2014 21:59:07 +0000 Subject: [issue22426] strptime accepts the wrong '2010-06-01 MSK' string but rejects the right '2010-06-01 MSD' Message-ID: <1410904746.97.0.914535199618.issue22426@psf.upfronthosting.co.za> New submission from Akira Li: >>> import os >>> import time >>> os.environ['TZ'] = 'Europe/Moscow' >>> time.tzset() >>> time.strptime('2010-06-01 MSK', '%Y-%m-%d %Z') time.struct_time(tm_year=2010, tm_mon=6, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=1, tm_yday=152, tm_isdst=0) >>> time.strptime('2010-06-01 MSD', '%Y-%m-%d %Z') Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/_strptime.py", line 467, in _strptime_time return _strptime(data_string, format)[0] File "/usr/lib/python2.7/_strptime.py", line 325, in _strptime (data_string, format)) ValueError: time data '2010-06-01 MSD' does not match format '%Y-%m-%d %Z' datetime.strptime() and Python 3 behavior is exactly the same. The correct name is MSD: >>> from datetime import datetime, timezone >>> dt = datetime(2010, 5, 31, 21, tzinfo=timezone.utc).astimezone() >>> dt.strftime('%Y-%m-%d %Z') '2010-06-01 MSD' strptime() uses the current (wrong for the past date) time.tzname names despite the correct name being known to the system (as the example above demonstrates). In general, it is impossible to validate a time zone abbreviation even if the time zone database is available: - tzname may be ambiguous -- multiple zoneinfo matches (around one third of tznames the tz database correspond to multiple UTC offsets (at the same or different times) -- it is not unusual) i.e., any scheme that assumes that tzname is enough to get UTC offset such as Lib/email/_parsedate.py is wrong. - and even if zoneinfo is known, it may be misleading e.g., e.g., HAST (Hawaii-Aleutian Standard Time) might be rejected because Pacific/Honolulu zoneinfo uses HST. HAST corresponds to America/Adak (US/Aleutian) in tzdata (UTC offset may be the same). It might be too rare to care. Related: issue22377 ---------- components: Library (Lib) messages: 226966 nosy: akira priority: normal severity: normal status: open title: strptime accepts the wrong '2010-06-01 MSK' string but rejects the right '2010-06-01 MSD' type: behavior versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 00:05:03 2014 From: report at bugs.python.org (Akira Li) Date: Tue, 16 Sep 2014 22:05:03 +0000 Subject: [issue22426] strptime accepts the wrong '2010-06-01 MSK' string but rejects the right '2010-06-01 MSD' In-Reply-To: <1410904746.97.0.914535199618.issue22426@psf.upfronthosting.co.za> Message-ID: <1410905103.64.0.486008550628.issue22426@psf.upfronthosting.co.za> Akira Li added the comment: Correction: The correct offset is +0400: >>> dt = datetime(2010, 5, 31, 20, tzinfo=timezone.utc).astimezone() And _timezones dict is defined in Lib/email/_parseaddr.py ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 02:00:41 2014 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 17 Sep 2014 00:00:41 +0000 Subject: [issue22412] Towards an asyncio-enabled command line In-Reply-To: <1410729335.06.0.363715018256.issue22412@psf.upfronthosting.co.za> Message-ID: <1410912041.49.0.373752207003.issue22412@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'm sorry you feel that way. I hope one day you will understand the other side of this kind of issue. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 02:37:58 2014 From: report at bugs.python.org (Ned Deily) Date: Wed, 17 Sep 2014 00:37:58 +0000 Subject: [issue22425] 2to3 import fixer writes dotted_as_names into import_as_names In-Reply-To: <1410901227.13.0.545813784004.issue22425@psf.upfronthosting.co.za> Message-ID: <1410914278.83.0.319914679758.issue22425@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 02:39:13 2014 From: report at bugs.python.org (Ned Deily) Date: Wed, 17 Sep 2014 00:39:13 +0000 Subject: [issue22426] strptime accepts the wrong '2010-06-01 MSK' string but rejects the right '2010-06-01 MSD' In-Reply-To: <1410904746.97.0.914535199618.issue22426@psf.upfronthosting.co.za> Message-ID: <1410914353.42.0.421227087654.issue22426@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +belopolsky, lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 02:53:58 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 17 Sep 2014 00:53:58 +0000 Subject: [issue22426] strptime accepts the wrong '2010-06-01 MSK' string but rejects the right '2010-06-01 MSD' In-Reply-To: <1410904746.97.0.914535199618.issue22426@psf.upfronthosting.co.za> Message-ID: <1410915238.07.0.106795178411.issue22426@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: There is no daylight savings time in Moscow and python detects this correctly: $ TZ=Europe/Moscow python3 >>> import time >>> time.daylight 0 Note that historically, there was DST, but time module cannot handle historical TZ changes. (Russian government compensates the relative sanity of not moving the clocks twice a year by changing the UTC offset and TZ boundaries every 5 years or so.:-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 03:12:31 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 17 Sep 2014 01:12:31 +0000 Subject: [issue22426] strptime accepts the wrong '2010-06-01 MSK' string but rejects the right '2010-06-01 MSD' In-Reply-To: <1410904746.97.0.914535199618.issue22426@psf.upfronthosting.co.za> Message-ID: <1410916351.38.0.0447958118309.issue22426@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I don't think there is anything we can do here. Without a TZ database, Python has to rely on time.tzname which in case of TZ=Europe/Moscow returns >>> time.tzname ('MSK', 'MSK') Hardcoding a timezones dictionary as done in email module may work for a handful of American timezones, but will not work for TZ's like Europe/Moscow. $ zdump -v Europe/Moscow| tail Europe/Moscow Sat Oct 24 22:59:59 2009 UTC = Sun Oct 25 02:59:59 2009 MSD isdst=1 Europe/Moscow Sat Oct 24 23:00:00 2009 UTC = Sun Oct 25 02:00:00 2009 MSK isdst=0 Europe/Moscow Sat Mar 27 22:59:59 2010 UTC = Sun Mar 28 01:59:59 2010 MSK isdst=0 Europe/Moscow Sat Mar 27 23:00:00 2010 UTC = Sun Mar 28 03:00:00 2010 MSD isdst=1 Europe/Moscow Sat Oct 30 22:59:59 2010 UTC = Sun Oct 31 02:59:59 2010 MSD isdst=1 Europe/Moscow Sat Oct 30 23:00:00 2010 UTC = Sun Oct 31 02:00:00 2010 MSK isdst=0 Europe/Moscow Sat Mar 26 22:59:59 2011 UTC = Sun Mar 27 01:59:59 2011 MSK isdst=0 Europe/Moscow Sat Mar 26 23:00:00 2011 UTC = Sun Mar 27 03:00:00 2011 MSK isdst=0 Europe/Moscow Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 07:14:07 2038 MSK isdst=0 Europe/Moscow Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 07:14:07 2038 MSK isdst=0 (And it looks like the planned for 2014-10-26 switch back to winter time is not in my laptop's database yet.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 03:21:57 2014 From: report at bugs.python.org (Berker Peksag) Date: Wed, 17 Sep 2014 01:21:57 +0000 Subject: [issue22377] %Z in strptime doesn't match EST and others In-Reply-To: <1410301455.57.0.912701656833.issue22377@psf.upfronthosting.co.za> Message-ID: <1410916917.38.0.781442617072.issue22377@psf.upfronthosting.co.za> Berker Peksag added the comment: > if PEP 431 is implemented (or anything that gives access to zoneinfo) > then strptime could extend the list of timezones it accepts (utc + > local timezone names) to include names from the tz database: FTR, I have a WIP(and probably a bit outdated) branch to implement PEP 431 on GitHub: https://github.com/berkerpeksag/cpython/tree/pep431 ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 03:22:36 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 17 Sep 2014 01:22:36 +0000 Subject: [issue22426] strptime accepts the wrong '2010-06-01 MSK' string but rejects the right '2010-06-01 MSD' In-Reply-To: <1410904746.97.0.914535199618.issue22426@psf.upfronthosting.co.za> Message-ID: <1410916956.61.0.823237440798.issue22426@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: On the second thought, we can probably make the same guesswork as in PyInit_timezone (see Modules/timemodule.c) in time.strptime, but not for the current time, but for the time parsed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 03:33:14 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 17 Sep 2014 01:33:14 +0000 Subject: [issue22426] strptime accepts the wrong '2010-06-01 MSK' string but rejects the right '2010-06-01 MSD' In-Reply-To: <1410904746.97.0.914535199618.issue22426@psf.upfronthosting.co.za> Message-ID: <1410917594.79.0.368244455434.issue22426@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- assignee: -> belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 03:34:06 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 17 Sep 2014 01:34:06 +0000 Subject: [issue22426] strptime accepts the wrong '2010-06-01 MSK' string but rejects the right '2010-06-01 MSD' In-Reply-To: <1410904746.97.0.914535199618.issue22426@psf.upfronthosting.co.za> Message-ID: <1410917646.57.0.955387930649.issue22426@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- stage: -> needs patch type: behavior -> enhancement versions: -Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 04:07:13 2014 From: report at bugs.python.org (Ethan Furman) Date: Wed, 17 Sep 2014 02:07:13 +0000 Subject: [issue22339] Incorrect behavior when subclassing enum.Enum In-Reply-To: <1409878211.89.0.422808973529.issue22339@psf.upfronthosting.co.za> Message-ID: <1410919633.95.0.52646205159.issue22339@psf.upfronthosting.co.za> Ethan Furman added the comment: http://hg.python.org/cpython/rev/4135f3929b35 http://hg.python.org/cpython/rev/cdd412347827 ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 04:14:33 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 17 Sep 2014 02:14:33 +0000 Subject: [issue21738] Enum docs claim replacing __new__ is not possible In-Reply-To: <1402598145.45.0.559693441236.issue21738@psf.upfronthosting.co.za> Message-ID: <20140917021429.88226.67959@mail.hg.python.org> Roundup Robot added the comment: New changeset 28c21f09719e by Ethan Furman in branch '3.4': Issue21738: clarify usage of __new__ in Enum subclasses https://hg.python.org/cpython/rev/28c21f09719e New changeset 91ec34801232 by Ethan Furman in branch 'default': Issue21738: clarify usage of __new__ in Enum subclasses https://hg.python.org/cpython/rev/91ec34801232 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 04:15:54 2014 From: report at bugs.python.org (Ethan Furman) Date: Wed, 17 Sep 2014 02:15:54 +0000 Subject: [issue21738] Enum docs claim replacing __new__ is not possible In-Reply-To: <1402598145.45.0.559693441236.issue21738@psf.upfronthosting.co.za> Message-ID: <1410920154.5.0.274360197683.issue21738@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- assignee: ethan.furman -> docs at python nosy: +docs at python resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 05:36:23 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 17 Sep 2014 03:36:23 +0000 Subject: [issue21706] Add base for enumerations (Functional API) In-Reply-To: <1402410828.65.0.285347945192.issue21706@psf.upfronthosting.co.za> Message-ID: <20140917033619.84318.97017@mail.hg.python.org> Roundup Robot added the comment: New changeset ec016ba862ba by Ethan Furman in branch 'default': Close issue21706: add 'start' parameter to functional API https://hg.python.org/cpython/rev/ec016ba862ba ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 05:54:51 2014 From: report at bugs.python.org (Akira Li) Date: Wed, 17 Sep 2014 03:54:51 +0000 Subject: [issue22377] %Z in strptime doesn't match EST and others In-Reply-To: <1410301455.57.0.912701656833.issue22377@psf.upfronthosting.co.za> Message-ID: <1410926091.27.0.508875437003.issue22377@psf.upfronthosting.co.za> Akira Li added the comment: If the current implementation is considered correct (%Z not recognizing EST) then indeed extending the list of recognized timezones is another issue. And the docs should be changed to match the implementation. The current behavior is broken, see also issue22426 If we assume that the docs are correct (%Z should match EST) even if it is not implemented yet then it is this issue's responsibility to extend the list of recognized timezones (even an incomplete hard-coded list generated by the code from msg226857 would be fine). Lib/email/_parseaddr.py approach (tzname corresponds to a fixed utc offset) is wrong: tzname may correspond to multiple utc offsets at the same time (different timezones) and at different times (even within the same timezone). Having the tz database won't fix it: *tzname along is not enough to determine UTC offset in _many_ cases.* CST is ambiguous if %z is not given therefore even if strptime() had the access to a larger list of recognized timezones; it is not clear what the return value would be: - aware datetime: which timezone to use? - naive datetime: it might be misleading if the input timezone name doesn't correspond to utc or the local timezone email._parseaddr._timezones is misleading if used globally: CST is also used in Australia, China with different utc offsets. One of possible solutions is to return aware datetime objects if a new truthy *timezones* keyword-only argument is provided. It may contain a mapping to disambiguate timezone abbreviations: {'EST': timedelta|tzinfo}. If *timezones* is False then strptime() returns a naive datetime object. The only difference from the current behavior is that a larger list of timezones is supported to match the docs. With bool(timezones) == True, strptime() could return an aware datetime object in utc, local timezones, or any timezone in *timezones* if it is a mapping. Default *timezones* is None that means timezone=False for backward compatibility. DeprecationWarning is added that timezone=True will be default in the next release 3.6 if no objections are received until then e.g., if tzname and timezones is None: # %Z matches non-empty string warn("Default *timezones* parameter for " "%s.strptime() will be True in Python 3.6. " "Pass timezones=False to preserve the old behaviour" % ( cls.__qualname__,), category=DeprecationWarning, stacklevel=2) I've uploaded the patch draft-strptime-%Z-timezones.diff that implements this solution. It also contains tests and docs updates. ---------- keywords: +patch Added file: http://bugs.python.org/file36634/draft-strptime-%Z-timezones.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 06:20:55 2014 From: report at bugs.python.org (Akira Li) Date: Wed, 17 Sep 2014 04:20:55 +0000 Subject: [issue22426] strptime accepts the wrong '2010-06-01 MSK' string but rejects the right '2010-06-01 MSD' In-Reply-To: <1410904746.97.0.914535199618.issue22426@psf.upfronthosting.co.za> Message-ID: <1410927655.58.0.565878378381.issue22426@psf.upfronthosting.co.za> Akira Li added the comment: My patch for issue22377 also fixes this bug. With the patch applied. Both MSK and MSD are accepted if the new timezones parameter is false (default for Python 3.5, will be changed to True in Python 3.6 If timezones is True then MSD return a correct aware datetime object, MSK is rejected. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 06:24:33 2014 From: report at bugs.python.org (Akira Li) Date: Wed, 17 Sep 2014 04:24:33 +0000 Subject: [issue22426] strptime accepts the wrong '2010-06-01 MSK' string but rejects the right '2010-06-01 MSD' In-Reply-To: <1410904746.97.0.914535199618.issue22426@psf.upfronthosting.co.za> Message-ID: <1410927872.99.0.381225433486.issue22426@psf.upfronthosting.co.za> Akira Li added the comment: MSD variant works on my machine because C library uses the historical timezone database there. I'm not sure whether it works on old Windows versions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 07:18:39 2014 From: report at bugs.python.org (Jack O'Connor) Date: Wed, 17 Sep 2014 05:18:39 +0000 Subject: [issue22427] TemporaryDirectory attempts to clean up twice Message-ID: <1410931119.87.0.05617613507.issue22427@psf.upfronthosting.co.za> New submission from Jack O'Connor: The following little script prints (but ignores) a FileNotFoundError. import tempfile def generator(): with tempfile.TemporaryDirectory(): yield g = generator() next(g) Exception ignored in: Traceback (most recent call last): File "gen.py", line 6, in generator File "/usr/lib/python3.4/tempfile.py", line 691, in __exit__ File "/usr/lib/python3.4/tempfile.py", line 697, in cleanup File "/usr/lib/python3.4/shutil.py", line 454, in rmtree File "/usr/lib/python3.4/shutil.py", line 452, in rmtree FileNotFoundError: [Errno 2] No such file or directory: '/tmp/tmp7wek4xhy' Putting print statements in the TemporaryDirectory class shows what's happening (confirming Guido's theory from https://groups.google.com/forum/#!topic/python-tulip/QXgWH32P2uM): As the program exits, the TemporaryDirectory object is finalized. This actually rmtree's the directory. After that, the generator is finalized, which raises a GeneratorExit inside of it. That exception causes the with statement to call __exit__ on the already-finalized TemporaryDirectory, which tries to rmtree again and throws the FileNotFoundError. The main downside of this bug is just garbage on stderr. I suppose in exceptionally unlikely circumstances, a new temp dir by the same name could be created between the two calls, and we might actually delete something we shouldn't. The simple fix would be to store a _was_cleaned flag or something on the object. Is there any black magic in finalizers or multithreading that demands something more complicated? ---------- components: Library (Lib) messages: 226979 nosy: oconnor663 priority: normal severity: normal status: open title: TemporaryDirectory attempts to clean up twice type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 07:19:52 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 17 Sep 2014 05:19:52 +0000 Subject: [issue22421] securing pydoc server In-Reply-To: <1410808618.63.0.0937681366512.issue22421@psf.upfronthosting.co.za> Message-ID: <20140917051947.100034.17533@mail.hg.python.org> Roundup Robot added the comment: New changeset c438f6aaafa9 by Senthil Kumaran in branch '3.3': Issue #22421 - Secure pydoc server run. Bind it to localhost instead of all interfaces. https://hg.python.org/cpython/rev/c438f6aaafa9 New changeset d36c0f2ab821 by Senthil Kumaran in branch '3.4': Merge from 3.3 https://hg.python.org/cpython/rev/d36c0f2ab821 New changeset 9f7b97fac919 by Senthil Kumaran in branch 'default': Merge from 3.4 https://hg.python.org/cpython/rev/9f7b97fac919 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 07:22:06 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 17 Sep 2014 05:22:06 +0000 Subject: [issue22421] securing pydoc server In-Reply-To: <1410808618.63.0.0937681366512.issue22421@psf.upfronthosting.co.za> Message-ID: <1410931326.85.0.733199068461.issue22421@psf.upfronthosting.co.za> Senthil Kumaran added the comment: 2.7 was not affected and it was binding to localhost properly. Since it is security related issue, I have fixed it in 3.3 as well. Fix is now present in 3.4 and 3.5 ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.3 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 09:03:16 2014 From: report at bugs.python.org (paul j3) Date: Wed, 17 Sep 2014 07:03:16 +0000 Subject: [issue22401] argparse: 'resolve' conflict handler damages the actions of the parent parser In-Reply-To: <1410673598.78.0.274465754789.issue22401@psf.upfronthosting.co.za> Message-ID: <1410937396.98.0.462407509287.issue22401@psf.upfronthosting.co.za> paul j3 added the comment: 'sample3.py' contains a '_handle_conflict_parent' function. With the help of a change in '_add_container_actions' it determines whether a conflicting action occurs in multiple parsers (and argument_groups). If it does, it deletes it from the correct group, without altering either the action, or other parsers. If the action occurs in only 1 group, then the 'resolve' method is used. The testing script mixes parents, subparsers, and various conflicts. ---------- Added file: http://bugs.python.org/file36635/sample3.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 09:12:48 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 17 Sep 2014 07:12:48 +0000 Subject: [issue22377] %Z in strptime doesn't match EST and others In-Reply-To: <1410301455.57.0.912701656833.issue22377@psf.upfronthosting.co.za> Message-ID: <1410937968.1.0.0264570206228.issue22377@psf.upfronthosting.co.za> R. David Murray added the comment: I don't think we are going to support a timezone list like that without PEP 431. You should attach your patch to a new issue. When I said this should the doc issue, that is because only a doc fix is acceptable for 3.4. Adding more timezones to recognize would be an enhancement, given the complexity of the proposed solution. On the other hand, if timezone names are ambiguous, I'm not sure there *is* a fix other than using the "defacto standard" names and offsets used by the email library. Actually, isn't there a written standard that addresses this issue? I seem to remember reading a discussion of the problem somewhere... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 09:19:48 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 17 Sep 2014 07:19:48 +0000 Subject: [issue22420] Use print(file=sys.stderr) instead of sys.stderr.write() in IDLE In-Reply-To: <1410808520.06.0.74767353905.issue22420@psf.upfronthosting.co.za> Message-ID: <1410938388.34.0.434177327779.issue22420@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Reviewed the patch. Looks good to go. ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 09:36:10 2014 From: report at bugs.python.org (Jack O'Connor) Date: Wed, 17 Sep 2014 07:36:10 +0000 Subject: [issue22428] KeyboardInterrupt inside a coroutine causes AttributeError Message-ID: <1410939370.36.0.183370883396.issue22428@psf.upfronthosting.co.za> New submission from Jack O'Connor: The following test script prints a KeyboardInterrupt traceback (expected), but also an AttributeError traceback (unexpected): import asyncio @asyncio.coroutine def main(): raise KeyboardInterrupt asyncio.get_event_loop().run_until_complete(main()) Traceback (most recent call last): File "test.py", line 9, in asyncio.get_event_loop().run_until_complete(main()) File "/usr/lib/python3.4/asyncio/base_events.py", line 203, in run_until_complete self.run_forever() File "/usr/lib/python3.4/asyncio/base_events.py", line 184, in run_forever self._run_once() File "/usr/lib/python3.4/asyncio/base_events.py", line 817, in _run_once handle._run() File "/usr/lib/python3.4/asyncio/events.py", line 39, in _run self._callback(*self._args) File "/usr/lib/python3.4/asyncio/tasks.py", line 321, in _step result = next(coro) File "/usr/lib/python3.4/asyncio/tasks.py", line 103, in coro res = func(*args, **kw) File "test.py", line 6, in main raise KeyboardInterrupt KeyboardInterrupt --- Logging error --- Traceback (most recent call last): --- Logging error --- Traceback (most recent call last): Exception ignored in: )> Traceback (most recent call last): File "/usr/lib/python3.4/asyncio/futures.py", line 184, in __del__ File "/usr/lib/python3.4/asyncio/base_events.py", line 725, in call_exception_handler File "/usr/lib/python3.4/logging/__init__.py", line 1296, in error File "/usr/lib/python3.4/logging/__init__.py", line 1402, in _log File "/usr/lib/python3.4/logging/__init__.py", line 1412, in handle File "/usr/lib/python3.4/logging/__init__.py", line 1482, in callHandlers File "/usr/lib/python3.4/logging/__init__.py", line 846, in handle File "/usr/lib/python3.4/logging/__init__.py", line 977, in emit File "/usr/lib/python3.4/logging/__init__.py", line 899, in handleError File "/usr/lib/python3.4/traceback.py", line 169, in print_exception File "/usr/lib/python3.4/traceback.py", line 153, in _format_exception_iter File "/usr/lib/python3.4/traceback.py", line 18, in _format_list_iter File "/usr/lib/python3.4/traceback.py", line 65, in _extract_tb_or_stack_iter File "/usr/lib/python3.4/linecache.py", line 15, in getline File "/usr/lib/python3.4/linecache.py", line 41, in getlines File "/usr/lib/python3.4/linecache.py", line 126, in updatecache File "/usr/lib/python3.4/tokenize.py", line 437, in open AttributeError: 'module' object has no attribute 'open' The issue is that Task._step() calls self.set_exception() for both Exceptions and BaseExceptions, but it reraises BaseExceptions. That means that the BaseEventLoop never gets to call future.result() to clear the exception when it's a BaseException. Future.__del__ eventually tries to log this uncleared exception, but something about the circumstances of program exit (caused by the same exception) has already cleaned up the builtins needed for logging. Is that __del__ violating some best practices for finalizers by calling such a complicated function? Either way, I'm not sure this case should be considered an "unretrieved exception" at all. It's propagating outside the event loop after all. Should Task._step() be setting it in the first place, if it's going to reraise it? Should it be set without _log_traceback=True somehow? ---------- components: asyncio messages: 226985 nosy: gvanrossum, haypo, oconnor663, yselivanov priority: normal severity: normal status: open title: KeyboardInterrupt inside a coroutine causes AttributeError type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 10:03:21 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 17 Sep 2014 08:03:21 +0000 Subject: [issue22419] wsgiref request length In-Reply-To: <1410804386.26.0.756558523053.issue22419@psf.upfronthosting.co.za> Message-ID: <1410941001.37.0.226075399533.issue22419@psf.upfronthosting.co.za> Senthil Kumaran added the comment: The patch looks good. Yeah, wsgiref server will see the benefiting of rejecting long url with 414. ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 10:33:02 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 17 Sep 2014 08:33:02 +0000 Subject: [issue22419] wsgiref request length In-Reply-To: <1410804386.26.0.756558523053.issue22419@psf.upfronthosting.co.za> Message-ID: <20140917083259.1841.99430@mail.hg.python.org> Roundup Robot added the comment: New changeset 7a4d960fc801 by Senthil Kumaran in branch '2.7': Issue #22419: Limit the length of incoming HTTP request in wsgiref server to 65536 bytes. https://hg.python.org/cpython/rev/7a4d960fc801 New changeset a4e0aee1a9b5 by Senthil Kumaran in branch '3.3': Issue #22419: Limit the length of incoming HTTP request in wsgiref server to 65536 bytes. https://hg.python.org/cpython/rev/a4e0aee1a9b5 New changeset ba86978c8ab5 by Senthil Kumaran in branch '3.4': Merge from 3.3 https://hg.python.org/cpython/rev/ba86978c8ab5 New changeset 07b928530cdf by Senthil Kumaran in branch 'default': Merge from 3.4 https://hg.python.org/cpython/rev/07b928530cdf ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 10:35:04 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 17 Sep 2014 08:35:04 +0000 Subject: [issue22419] wsgiref request length In-Reply-To: <1410804386.26.0.756558523053.issue22419@psf.upfronthosting.co.za> Message-ID: <1410942904.8.0.469678873762.issue22419@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Thanks, fixed in all versions applicable for security release. ---------- assignee: -> orsenthil resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 10:35:19 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 17 Sep 2014 08:35:19 +0000 Subject: [issue22419] wsgiref request length In-Reply-To: <1410804386.26.0.756558523053.issue22419@psf.upfronthosting.co.za> Message-ID: <1410942919.5.0.823087567952.issue22419@psf.upfronthosting.co.za> Changes by Senthil Kumaran : ---------- versions: +Python 2.7, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 10:57:13 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 17 Sep 2014 08:57:13 +0000 Subject: [issue17381] IGNORECASE breaks unicode literal range matching In-Reply-To: <1362689552.47.0.00880933015098.issue17381@psf.upfronthosting.co.za> Message-ID: <1410944233.33.0.989207946096.issue17381@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This patch has a disadvantage - it slows down case-insensitive compiling of some very wide ranges, e.g. compile(r"[\x00-\U0010ffff]+", re.I) (this is worst case). In most cases this is not important, because such wide ranges are rare enough and compiled patterns are cached. To get rid of this regression, we need new opcode. Due to preserving binary compatibility, this approach can't be applied to old releases. Here is a patch for 3.5. Please make a review. This patches are needed to continue fixing of other re bugs. ---------- keywords: +needs review Added file: http://bugs.python.org/file36636/re_ignore_case_range-3.5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 10:57:25 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 17 Sep 2014 08:57:25 +0000 Subject: [issue22417] PEP 476: verify HTTPS certificates by default In-Reply-To: <1410784469.95.0.475937020841.issue22417@psf.upfronthosting.co.za> Message-ID: <1410944245.87.0.483263533902.issue22417@psf.upfronthosting.co.za> Changes by Senthil Kumaran : ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 10:57:46 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Wed, 17 Sep 2014 08:57:46 +0000 Subject: [issue22427] TemporaryDirectory attempts to clean up twice In-Reply-To: <1410931119.87.0.05617613507.issue22427@psf.upfronthosting.co.za> Message-ID: <1410944266.51.0.427275972329.issue22427@psf.upfronthosting.co.za> Changes by Josh Rosenberg : ---------- nosy: +josh.rosenberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 11:35:49 2014 From: report at bugs.python.org (Frank Thommen) Date: Wed, 17 Sep 2014 09:35:49 +0000 Subject: [issue22326] tempfile.TemporaryFile fails on NFS v4 filesystems In-Reply-To: <1409659206.56.0.836891924559.issue22326@psf.upfronthosting.co.za> Message-ID: <1410946549.76.0.670338295612.issue22326@psf.upfronthosting.co.za> Frank Thommen added the comment: strace gives me the error: unlink("/mnt/tmpu817xz") = -1 EIO (Input/output error) But after escalating the issue to our server vendor it turned out that the problem lies in the filesystem option "nbmand". If this option is set to "on" - which it seems to be by default on our zfs filesystems - and the filesystem is exported and mounted with NFS v4, then tempfile.TemporaryFile fails: [...] V4 Call (Reply In 167) RENAME From: tmpr0OaMb To: .nfs00000000000000270000af65 V4 Reply (Call In 166) RENAME Status: NFS4ERR_FILE_OPEN [...] I assume that this is nothing Python can check for and therefore not a Python problem. Not sure what the policy is: Can I set the ticket to "solved" myself? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 11:44:08 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 17 Sep 2014 09:44:08 +0000 Subject: [issue22427] TemporaryDirectory attempts to clean up twice In-Reply-To: <1410931119.87.0.05617613507.issue22427@psf.upfronthosting.co.za> Message-ID: <1410947048.42.0.538262770561.issue22427@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 12:15:21 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 17 Sep 2014 10:15:21 +0000 Subject: [issue22326] tempfile.TemporaryFile fails on NFS v4 filesystems In-Reply-To: <1409659206.56.0.836891924559.issue22326@psf.upfronthosting.co.za> Message-ID: <1410948921.13.0.466977044175.issue22326@psf.upfronthosting.co.za> STINNER Victor added the comment: > unlink("/mnt/tmpu817xz") = -1 EIO (Input/output error) If a system call can fail with EIO, I guess that not only Python is affected, by *any* program. So I don't see why Python should have a special case for broken filesystems. I close the issue as "not a bug". ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 12:21:50 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 17 Sep 2014 10:21:50 +0000 Subject: [issue22428] asyncio: KeyboardInterrupt inside a coroutine causes AttributeError In-Reply-To: <1410939370.36.0.183370883396.issue22428@psf.upfronthosting.co.za> Message-ID: <1410949310.27.0.793428327725.issue22428@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: KeyboardInterrupt inside a coroutine causes AttributeError -> asyncio: KeyboardInterrupt inside a coroutine causes AttributeError _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 12:56:55 2014 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 17 Sep 2014 10:56:55 +0000 Subject: [issue22385] Define a binary output formatting mini-language for *.hex() In-Reply-To: <1410393301.25.0.193851592698.issue22385@psf.upfronthosting.co.za> Message-ID: <1410951415.08.0.368438473996.issue22385@psf.upfronthosting.co.za> Nick Coghlan added the comment: Retitled the issue and made it depend on issue 9951. I now think it's better to tackle this more like strftime and have a method that accepts of particular custom formatting mini-language (in this case, the new hex() methods proposed in issue 9951), and then also support that mini-language in the __format__() method. It would likely need a PEP to decide on the exact details of the formatting. ---------- dependencies: +introduce bytes.hex method title: Allow 'x' and 'X' to accept bytes-like objects in string formatting -> Define a binary output formatting mini-language for *.hex() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 13:01:06 2014 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 17 Sep 2014 11:01:06 +0000 Subject: [issue22385] Define a binary output formatting mini-language for *.hex() In-Reply-To: <1410393301.25.0.193851592698.issue22385@psf.upfronthosting.co.za> Message-ID: <1410951666.05.0.148394869482.issue22385@psf.upfronthosting.co.za> Nick Coghlan added the comment: python-ideas post with a sketch of a possible mini-language: https://mail.python.org/pipermail/python-ideas/2014-September/029352.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 13:51:54 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 17 Sep 2014 11:51:54 +0000 Subject: [issue22429] asyncio: pending call to loop.stop() if a coroutine raises a BaseException Message-ID: <1410954714.23.0.464914894828.issue22429@psf.upfronthosting.co.za> New submission from STINNER Victor: Attached script stops immediatly whereas I would expect that the second call to run_forever() keeps running. If you execute the script, you will see: deque([]) The first call to run_forever() keeps a pending call to loop.stop() (to _rase_stop_error() in fact). I don't know if it should be called a bug or if this surprising behaviour should be documented. See also the issue #22428. ---------- components: asyncio files: pending_stop.py messages: 226994 nosy: gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: asyncio: pending call to loop.stop() if a coroutine raises a BaseException versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file36637/pending_stop.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 13:59:25 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 17 Sep 2014 11:59:25 +0000 Subject: [issue22428] asyncio: KeyboardInterrupt inside a coroutine causes AttributeError In-Reply-To: <1410939370.36.0.183370883396.issue22428@psf.upfronthosting.co.za> Message-ID: <1410955165.4.0.0859695632084.issue22428@psf.upfronthosting.co.za> STINNER Victor added the comment: I see different issues in your example: * If the coroutine raises an exception which doesn't inherit from Exception (but inherits from BaseException), run_until_complete() doesn't consume the exception from the temporary task object => run_until_complete(coroutine) sets the _log_destroy_pending attribute of the temporary Task to False, but this attribute controls the "Task was destroyed but it is pending!" warning. The "%s exception was never retrieved" warning is controlled by the Future._log_traceback attribute (in Python 3.4+). This attribute is set to True in Future.set_exception().* * If a Task is deleted late during Python shutdown, the logging module fails to log the traceback because the builtin function has been deleted. => IMO it's an issue in the traceback module. It may catch the AttributeError on the call to linecache.getline(). It's not convinient to get a new exception (traceback) when trying to display a traceback... Maybe the traceback can check if Python is exiting before calling the linecache module? * If you call again loop.run_forever(): it exits immediatly because a call to loop.stop() was scheduled by future.set_exception() => I created the issue #22429 I don't think that it's a bug that Task._step() calls set_exception() for BaseException. Otherwise, how do you know that a task failed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 14:12:25 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 17 Sep 2014 12:12:25 +0000 Subject: [issue22427] TemporaryDirectory attempts to clean up twice In-Reply-To: <1410931119.87.0.05617613507.issue22427@psf.upfronthosting.co.za> Message-ID: <1410955945.32.0.160126210638.issue22427@psf.upfronthosting.co.za> STINNER Victor added the comment: On Python 3.5 compiled in debug mode (or probably with python -Wd when compiled in release mode), I got this warning: /home/haypo/prog/python/default/Lib/tempfile.py:708: ResourceWarning: Implicitly cleaning up _warnings.warn(warn_message, ResourceWarning) The script is really a corner case: the generator is garbage collected whereas it is not done. At the same time, the TemporaryDirectory object is also garbage collected. I guess that the exact order of object deletion is not reliable: the generator may be deleted before or after the TemporaryDirectory. TemporaryDirectory._cleanup() is called by the finalizer (_weakref.finalize) of the TemporaryDirectory, which means that the TemporaryDirectory object is garbage collected. TemporaryDirectory.cleanup() is called indirectly by TemporaryDirectory.__exit__(). I'm suprised that deleting a generator calls __exit__(). The following script has a more reliable behaviour: TemporaryDirectory.__exit__() is called when the generator is deleted, and TemporaryDirectory.cleanup() is not called. --- import tempfile import gc def generator(): with tempfile.TemporaryDirectory(): print("before yield") yield print("after yield") g = generator() next(g) g = None gc.collect() --- ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 15:33:37 2014 From: report at bugs.python.org (diff 812) Date: Wed, 17 Sep 2014 13:33:37 +0000 Subject: [issue22430] Build failure if configure flags --prefix or --exec-prefix is set Message-ID: <1410960816.78.0.977499217062.issue22430@psf.upfronthosting.co.za> New submission from diff 812: only ./configure --prefix=/usr is running ---------- components: Build files: configure.log messages: 226997 nosy: diff.812 priority: normal severity: normal status: open title: Build failure if configure flags --prefix or --exec-prefix is set versions: Python 2.7 Added file: http://bugs.python.org/file36638/configure.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 15:34:08 2014 From: report at bugs.python.org (diff 812) Date: Wed, 17 Sep 2014 13:34:08 +0000 Subject: [issue22430] Build failure if configure flags --prefix or --exec-prefix is set In-Reply-To: <1410960816.78.0.977499217062.issue22430@psf.upfronthosting.co.za> Message-ID: <1410960848.74.0.576380492605.issue22430@psf.upfronthosting.co.za> diff 812 added the comment: make command ---------- Added file: http://bugs.python.org/file36639/make.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 15:39:11 2014 From: report at bugs.python.org (diff 812) Date: Wed, 17 Sep 2014 13:39:11 +0000 Subject: [issue22430] Build failure if configure flags --prefix or --exec-prefix is set In-Reply-To: <1410960816.78.0.977499217062.issue22430@psf.upfronthosting.co.za> Message-ID: <1410961151.29.0.159183029946.issue22430@psf.upfronthosting.co.za> diff 812 added the comment: make without --prefix key ---------- Added file: http://bugs.python.org/file36640/make_ok.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 15:44:38 2014 From: report at bugs.python.org (Philipp Metzler) Date: Wed, 17 Sep 2014 13:44:38 +0000 Subject: [issue22431] Change format of test runner output Message-ID: <1410961478.22.0.708066565645.issue22431@psf.upfronthosting.co.za> New submission from Philipp Metzler: Can I change the test runner output format to main.tests.tests.TimeSlotTestCase.test_creation ... ERROR instead of test_creation (main.tests.tests.TimeSlotTestCase) ... ERROR so that I can easily just copy&paste that line and run the test again without having to remove the brackets () and having to copy the name of the test behind the class and add a .? ---------- components: Tests messages: 227000 nosy: googol priority: normal severity: normal status: open title: Change format of test runner output type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 15:58:04 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 17 Sep 2014 13:58:04 +0000 Subject: [issue22431] Change format of test runner output In-Reply-To: <1410961478.22.0.708066565645.issue22431@psf.upfronthosting.co.za> Message-ID: <1410962284.26.0.167841509583.issue22431@psf.upfronthosting.co.za> R. David Murray added the comment: I remember this feature being requested before (I vote +1 myself :), and I believe I recall a conversation involving Michael Foord where he approved it in principle, but I can't find an open issue for it. As a new feature it can only go into 3.5, and would presumably need to be controlled by an option somewhere to preserve backward compatibility with things that parse unittest output. If you want to work on a patch that would be welcome. ---------- components: +Library (Lib) -Tests nosy: +michael.foord, r.david.murray versions: +Python 3.5 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 16:11:23 2014 From: report at bugs.python.org (Mark Wieczorek) Date: Wed, 17 Sep 2014 14:11:23 +0000 Subject: [issue22432] function crypt not working on OSX Message-ID: <1410963083.91.0.127109997194.issue22432@psf.upfronthosting.co.za> New submission from Mark Wieczorek: Hi, I just wanted to let you know of a bug that is related to the function "crypt" in osx (10.9.4). I have tried the default osx version of python (2.75), the brew version (2.7.8), and the macports version (2.7.7). In short, the command python -c 'import crypt; print crypt.crypt("test12345", "$6$salt")' produces the output : $6n8sgZJBMh4U The correct output should be $6$salt$omHbK1V1Alwa0VKXqLaW38vdS1uUhfx8GTj7XXCJcNUJxABwmYe8Vhpyt2tnnaAFC6UTI7PNk9sTtSGWGnYop. I have no idea what the problem is. ---------- assignee: ronaldoussoren components: Macintosh messages: 227002 nosy: lunokhod, ronaldoussoren priority: normal severity: normal status: open title: function crypt not working on OSX type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 16:23:10 2014 From: report at bugs.python.org (Geoffrey Spear) Date: Wed, 17 Sep 2014 14:23:10 +0000 Subject: [issue22432] function crypt not working on OSX In-Reply-To: <1410963083.91.0.127109997194.issue22432@psf.upfronthosting.co.za> Message-ID: <1410963790.77.0.718503604058.issue22432@psf.upfronthosting.co.za> Geoffrey Spear added the comment: The same behavior exists in Python 3, however, I'm not sure it's a bug. The documentation says "The characters in salt must be in the set [./a-zA-Z0-9]." Presumably the behavior when there is a $ in the salt is undefined by Python, and different on different platforms. ---------- nosy: +geoffreyspear _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 16:25:56 2014 From: report at bugs.python.org (Mark Wieczorek) Date: Wed, 17 Sep 2014 14:25:56 +0000 Subject: [issue22432] function crypt not working on OSX In-Reply-To: <1410963083.91.0.127109997194.issue22432@psf.upfronthosting.co.za> Message-ID: <1410963956.94.0.940898156926.issue22432@psf.upfronthosting.co.za> Mark Wieczorek added the comment: It actually doesn't even matter what you use for salt. If you change "salt", you get the same hash. That is bug #2 ! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 16:41:01 2014 From: report at bugs.python.org (Geoffrey Spear) Date: Wed, 17 Sep 2014 14:41:01 +0000 Subject: [issue22432] function crypt not working on OSX In-Reply-To: <1410963083.91.0.127109997194.issue22432@psf.upfronthosting.co.za> Message-ID: <1410964861.4.0.341095416072.issue22432@psf.upfronthosting.co.za> Geoffrey Spear added the comment: This is actually the expected behavior of crypt(3) on OS X. It doesn't support the $id$ modular format, and if the salt does not begin with an underscore only the first 2 bytes are used (presumably in your "bug #2" you're changing parts of the salt beyond the first 2 bytes.) Python's behavior differing based on the underlying C library on the system is documented; this is neither a bug in Python or in OS X crypt (although it could be argued that OS X crypt is kind of useless and insecure...) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 17:01:07 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 17 Sep 2014 15:01:07 +0000 Subject: [issue22432] function crypt not working on OSX In-Reply-To: <1410963083.91.0.127109997194.issue22432@psf.upfronthosting.co.za> Message-ID: <1410966067.68.0.00691836520285.issue22432@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 17:10:19 2014 From: report at bugs.python.org (Jack O'Connor) Date: Wed, 17 Sep 2014 15:10:19 +0000 Subject: [issue22427] TemporaryDirectory attempts to clean up twice In-Reply-To: <1410931119.87.0.05617613507.issue22427@psf.upfronthosting.co.za> Message-ID: <1410966619.04.0.679613239168.issue22427@psf.upfronthosting.co.za> Jack O'Connor added the comment: My example script is definitely a corner case, but where this actually came up for me was in asyncio. Using a TemporaryDirectory inside a coroutine creates a similar situation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 17:57:56 2014 From: report at bugs.python.org (=?utf-8?b?0JTQtdC90LjRgSDQmtC+0YDQtdC90LXQstGB0LrQuNC5?=) Date: Wed, 17 Sep 2014 15:57:56 +0000 Subject: [issue22433] Argparse considers unknown optional arguments with spaces as a known positional argument Message-ID: <1410969476.15.0.703805216421.issue22433@psf.upfronthosting.co.za> New submission from ????? ???????????: Argparse version 1.1 consider ANY unknown argument string containig ' ' (space character) as positional argument. As a result it can use such unknown optional argument as a value of known positional argument. Demonstration code: import argparse parser = argparse.ArgumentParser() parser.add_argument("--known-optional-arg", "-k", action="store_true") parser.add_argument("known_positional", action="store", type=str) parser.parse_known_args(["--known-optional-arg", "--unknown-optional-arg=with spaces", "known positional arg"]) parser.parse_known_args(["--known-optional-arg", "--unknown-optional-arg=without_spaces", "known positional arg"]) Bugfix is attached to issue and affects ArgumentParser._parse_optional() method body. Sorry, if it is a better way to report (or, possibly, fix) a bug than this place. It is my first python bug report. Thanks. ---------- components: Extension Modules files: argparse.py.patch keywords: patch messages: 227007 nosy: DenKoren priority: normal severity: normal status: open title: Argparse considers unknown optional arguments with spaces as a known positional argument type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file36641/argparse.py.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 18:09:48 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 17 Sep 2014 16:09:48 +0000 Subject: [issue22434] Use named constants internally in the re module Message-ID: <1410970188.53.0.105353417029.issue22434@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Regular expression parser parses a pattern to a tree, marking nodes by string identifiers. Regular expression compiler converts this three into plain list of integers. Node's identifiers are transformed to sequential integers. Resulting list is not human readable. Proposed patch converts string constants in the sre_constants module to named integer constants. These constants doesn't need converting to integers, because they are already integers, and when printed they looks human-friendly. Now intermediate result of regular expression compiler looks much more readable. Example. >>> import re, sre_compile, sre_parse >>> sre_compile._code(sre_parse.parse('[a-z_][a-z_0-9]+', re.I), re.I) Before patch: [17, 4, 0, 2, 2147483647, 16, 7, 27, 97, 122, 19, 95, 0, 29, 16, 1, 2147483647, 16, 11, 10, 0, 67043328, 2147483648, 134217726, 0, 0, 0, 0, 0, 1, 1] After patch: [INFO, 4, 0, 2, MAXREPEAT, IN_IGNORE, 7, RANGE, 97, 122, LITERAL, 95, FAILURE, REPEAT_ONE, 16, 1, MAXREPEAT, IN_IGNORE, 11, CHARSET, 0, 67043328, 2147483648, 134217726, 0, 0, 0, 0, FAILURE, SUCCESS, SUCCESS] This patch also affects debugging output when regular expression is compiled with re.DEBUG (identifiers are uppercased and MAXREPEAT is displayed instead of 2147483647 in repeat statements). Besides debugging output these changes are invisible for ordinal user. They are needed only for developing and debugging the re module itself. The patch doesn't affect performance and almost not affects memory consumption. ---------- components: Regular Expressions files: re_named_consts.patch keywords: patch messages: 227008 nosy: ezio.melotti, mrabarnett, pitrou, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Use named constants internally in the re module type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file36642/re_named_consts.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 18:12:20 2014 From: report at bugs.python.org (=?utf-8?b?0JTQtdC90LjRgSDQmtC+0YDQtdC90LXQstGB0LrQuNC5?=) Date: Wed, 17 Sep 2014 16:12:20 +0000 Subject: [issue22433] Argparse considers unknown optional arguments with spaces as a known positional argument In-Reply-To: <1410969476.15.0.703805216421.issue22433@psf.upfronthosting.co.za> Message-ID: <1410970340.7.0.735227115519.issue22433@psf.upfronthosting.co.za> ????? ??????????? added the comment: I've signed 'Contributor's Agreement'. Bug demonstration code listed in issue description is in file attached to comment. It can be run with following command: python argparse_bug_example.py ---------- Added file: http://bugs.python.org/file36643/argparse_bug_example.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 18:16:55 2014 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 17 Sep 2014 16:16:55 +0000 Subject: [issue22434] Use named constants internally in the re module In-Reply-To: <1410970188.53.0.105353417029.issue22434@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Love it! ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 19:30:45 2014 From: report at bugs.python.org (Ned Deily) Date: Wed, 17 Sep 2014 17:30:45 +0000 Subject: [issue22430] Build failure if configure flags --prefix or --exec-prefix is set In-Reply-To: <1410960816.78.0.977499217062.issue22430@psf.upfronthosting.co.za> Message-ID: <1410975045.27.0.87193654841.issue22430@psf.upfronthosting.co.za> Ned Deily added the comment: It is difficult to tell what the problem you encountered here is without more information. Python is supported on many different platforms and regularly built with --prefix being set. To investigate further, you would need to indicate exactly which version of Python, which version of which operating system platform, and the exact configure and make commands you are using. Nevertheless, because you seem to be doing a shared (--enable-shared) build with a prefix of /usr, I speculate you *might* be running into the issue documented, and recently fixed, in Issue21166. You could try removing --enable-shared, or you could try applying the change from that issue, or you could try working around simulating the patch's effect by creating a dummy pybuilddir.txt before running make. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 19:34:27 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 17 Sep 2014 17:34:27 +0000 Subject: [issue22427] TemporaryDirectory attempts to clean up twice In-Reply-To: <1410931119.87.0.05617613507.issue22427@psf.upfronthosting.co.za> Message-ID: <1410975267.49.0.275021070322.issue22427@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch which may fix this issue. ---------- keywords: +patch nosy: +pitrou, serhiy.storchaka stage: -> patch review versions: +Python 3.5 Added file: http://bugs.python.org/file36644/tempfile_exit_on_shutdown.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 19:56:17 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 17 Sep 2014 17:56:17 +0000 Subject: [issue22427] TemporaryDirectory attempts to clean up twice In-Reply-To: <1410931119.87.0.05617613507.issue22427@psf.upfronthosting.co.za> Message-ID: <1410976577.79.0.389687468197.issue22427@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is alternative patch. It simplifies TemporaryDirectory instead of complicate it. ---------- Added file: http://bugs.python.org/file36645/tempfile_exit_on_shutdown2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 17 20:27:17 2014 From: report at bugs.python.org (ingrid) Date: Wed, 17 Sep 2014 18:27:17 +0000 Subject: [issue21077] Turtle Circle Speed 0 In-Reply-To: <1395936990.77.0.953738655575.issue21077@psf.upfronthosting.co.za> Message-ID: <1410978437.41.0.377289980068.issue21077@psf.upfronthosting.co.za> ingrid added the comment: This seems to be caused by a bug in TurtleScreen.update/turtle._drawturtle. When the speed is set to zero, the tracer method is used to regulate drawing circles, and when called with a positive integer, tracer calls update. Update iterates over the list of existing turtle objects and then updates them and calls _drawturtle on them, then redraws them, but doesn't draw lines or stamps so they'll get drawn over by shapes and images. I attached a snippet that shows the bug happening when you call update directly, if you switch the last line and use tracer instead the same thing happens. I think the way to fix it is to add stamps and lines to _drawturtle so I'm going to work on a patch that uses that approach. ---------- nosy: +ingrid Added file: http://bugs.python.org/file36646/update_example.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 00:13:02 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 17 Sep 2014 22:13:02 +0000 Subject: [issue22390] test.regrtest should complain if a test doesn't remove temporary files In-Reply-To: <1410445852.03.0.724241204359.issue22390@psf.upfronthosting.co.za> Message-ID: <1410991982.68.0.989224902343.issue22390@psf.upfronthosting.co.za> STINNER Victor added the comment: fix_tests.patch: Fix the 7 tests which create files without removing them. 4 tests (test_imp, test_pdb, test_source_encoding and test_support) create a __pycache__ directory. Maybe this directory should be ignored by regrtest? ---------- Added file: http://bugs.python.org/file36647/fix_tests.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 00:17:19 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 17 Sep 2014 22:17:19 +0000 Subject: [issue22043] Use a monotonic clock to compute timeouts In-Reply-To: <1406081401.66.0.461602325424.issue22043@psf.upfronthosting.co.za> Message-ID: <1410992239.61.0.146778014119.issue22043@psf.upfronthosting.co.za> STINNER Victor added the comment: Buildbots are happy, I close the issue. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 01:08:48 2014 From: report at bugs.python.org (Martin Panter) Date: Wed, 17 Sep 2014 23:08:48 +0000 Subject: [issue22431] Change format of test runner output In-Reply-To: <1410961478.22.0.708066565645.issue22431@psf.upfronthosting.co.za> Message-ID: <1410995328.2.0.613942028445.issue22431@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 02:25:22 2014 From: report at bugs.python.org (Martin Panter) Date: Thu, 18 Sep 2014 00:25:22 +0000 Subject: [issue22435] socketserver.TCPSocket leaks socket to garbage collector if server_bind() fails Message-ID: <1410999922.66.0.432841070426.issue22435@psf.upfronthosting.co.za> New submission from Martin Panter: Bind method may easily fail on Unix if there is no permission to bind to a privileged port: >>> try: TCPServer(("", 80), ...) ... except Exception as err: err ... PermissionError(13, 'Permission denied') >>> gc.collect() __main__:1: ResourceWarning: unclosed 0 This problem is inherited by HTTPServer and WSGIServer. My current workaround includes this code in a BaseServer fixup mixin, invoking server_close() if __init__() fails: class Server(BaseServer, Context): def __init__(self, ...): try: super().__init__((host, port), RequestHandlerClass) except: # Workaround for socketserver.TCPServer leaking socket self.close() raise def close(self): return self.server_close() ---------- components: Library (Lib) messages: 227017 nosy: vadmium priority: normal severity: normal status: open title: socketserver.TCPSocket leaks socket to garbage collector if server_bind() fails type: resource usage versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 02:44:45 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 18 Sep 2014 00:44:45 +0000 Subject: [issue4180] warnings.simplefilter("always") does not make warnings always show up In-Reply-To: <1224712172.47.0.998538899646.issue4180@psf.upfronthosting.co.za> Message-ID: <20140918004439.54497.83953@mail.hg.python.org> Roundup Robot added the comment: New changeset 8adb2c6e0803 by Antoine Pitrou in branch '3.4': Issue #4180: The warnings registries are now reset when the filters are modified. https://hg.python.org/cpython/rev/8adb2c6e0803 New changeset 4bc60eb68d3e by Antoine Pitrou in branch 'default': Issue #4180: The warnings registries are now reset when the filters are modified. https://hg.python.org/cpython/rev/4bc60eb68d3e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 02:45:19 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 18 Sep 2014 00:45:19 +0000 Subject: [issue4180] warnings.simplefilter("always") does not make warnings always show up In-Reply-To: <1224712172.47.0.998538899646.issue4180@psf.upfronthosting.co.za> Message-ID: <1411001119.28.0.794034436247.issue4180@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, this is pushed to 3.x. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 03:06:58 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 18 Sep 2014 01:06:58 +0000 Subject: [issue11471] If without else generates redundant jump In-Reply-To: <1299880156.4.0.0999870554397.issue11471@psf.upfronthosting.co.za> Message-ID: <20140918010655.60341.87929@mail.hg.python.org> Roundup Robot added the comment: New changeset c0ca9d32aed4 by Antoine Pitrou in branch 'default': Closes #11471: avoid generating a JUMP_FORWARD instruction at the end of an if-block if there is no else-clause. https://hg.python.org/cpython/rev/c0ca9d32aed4 ---------- nosy: +python-dev resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 03:07:40 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 18 Sep 2014 01:07:40 +0000 Subject: [issue11471] If without else generates redundant jump In-Reply-To: <1299880156.4.0.0999870554397.issue11471@psf.upfronthosting.co.za> Message-ID: <1411002460.94.0.171506194131.issue11471@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Pushed after applying Serhiy's suggestion. Thank you! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 04:10:42 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 18 Sep 2014 02:10:42 +0000 Subject: [issue21391] shutil uses both os.path.abspath and an 'import from' of abspath In-Reply-To: <1398851506.17.0.252002971676.issue21391@psf.upfronthosting.co.za> Message-ID: <20140918021034.18454.14084@mail.hg.python.org> Roundup Robot added the comment: New changeset ab369d809200 by Berker Peksag in branch 'default': Issue #21391: Use os.path.abspath in the shutil module. https://hg.python.org/cpython/rev/ab369d809200 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 04:11:52 2014 From: report at bugs.python.org (Berker Peksag) Date: Thu, 18 Sep 2014 02:11:52 +0000 Subject: [issue21391] shutil uses both os.path.abspath and an 'import from' of abspath In-Reply-To: <1398851506.17.0.252002971676.issue21391@psf.upfronthosting.co.za> Message-ID: <1411006312.07.0.0698424360911.issue21391@psf.upfronthosting.co.za> Berker Peksag added the comment: Done. Thanks for the reviews! ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 04:22:33 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 18 Sep 2014 02:22:33 +0000 Subject: [issue21706] Add base for enumerations (Functional API) In-Reply-To: <1402410828.65.0.285347945192.issue21706@psf.upfronthosting.co.za> Message-ID: <20140918022228.107510.89347@mail.hg.python.org> Roundup Robot added the comment: New changeset 713ee49ec3ba by Berker Peksag in branch 'default': Issue #21706: Add a versionchanged directive to the functional API docs. https://hg.python.org/cpython/rev/713ee49ec3ba ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 04:31:19 2014 From: report at bugs.python.org (Berker Peksag) Date: Thu, 18 Sep 2014 02:31:19 +0000 Subject: [issue14824] reprlib documentation references string module In-Reply-To: <1337147544.42.0.726566417701.issue14824@psf.upfronthosting.co.za> Message-ID: <1411007479.43.0.701930869363.issue14824@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: -> patch review versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 05:04:57 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 18 Sep 2014 03:04:57 +0000 Subject: [issue14824] reprlib documentation references string module In-Reply-To: <1337147544.42.0.726566417701.issue14824@psf.upfronthosting.co.za> Message-ID: <20140918030452.82459.36943@mail.hg.python.org> Roundup Robot added the comment: New changeset e9968782c9ba by Berker Peksag in branch '3.4': Issue #14824: Update Repr.repr_TYPE documentation to use correct name mangling implementation. https://hg.python.org/cpython/rev/e9968782c9ba New changeset a0372781eafb by Berker Peksag in branch 'default': Issue #14824: Update Repr.repr_TYPE documentation to use correct name mangling implementation. https://hg.python.org/cpython/rev/a0372781eafb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 05:08:22 2014 From: report at bugs.python.org (Berker Peksag) Date: Thu, 18 Sep 2014 03:08:22 +0000 Subject: [issue14824] reprlib documentation references string module In-Reply-To: <1337147544.42.0.726566417701.issue14824@psf.upfronthosting.co.za> Message-ID: <1411009702.43.0.785968523323.issue14824@psf.upfronthosting.co.za> Berker Peksag added the comment: > I don't know why we would ever have a space in a typename, ever (and if someone does awful hacks to get to that state, he should probably also do awful hacks to make reprlib work properly). That part of the code has been added 22 years ago: https://hg.python.org/cpython/rev/a0d4c5ef1d5d#l9.22 So probably the reason is that the code is just old. Thanks for the patch, Chris! ---------- assignee: docs at python -> berker.peksag nosy: +berker.peksag resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 05:09:47 2014 From: report at bugs.python.org (Berker Peksag) Date: Thu, 18 Sep 2014 03:09:47 +0000 Subject: [issue16827] Remove the relatively advanced content from section 2 in tutorial In-Reply-To: <1356964896.19.0.673901752517.issue16827@psf.upfronthosting.co.za> Message-ID: <1411009787.12.0.456960723183.issue16827@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 05:10:48 2014 From: report at bugs.python.org (Berker Peksag) Date: Thu, 18 Sep 2014 03:10:48 +0000 Subject: [issue16827] Remove the relatively advanced content from section 2 in tutorial In-Reply-To: <1356964896.19.0.673901752517.issue16827@psf.upfronthosting.co.za> Message-ID: <1411009848.26.0.58317187994.issue16827@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 05:17:50 2014 From: report at bugs.python.org (Berker Peksag) Date: Thu, 18 Sep 2014 03:17:50 +0000 Subject: [issue16827] Remove the relatively advanced content from section 2 in tutorial In-Reply-To: <1356964896.19.0.673901752517.issue16827@psf.upfronthosting.co.za> Message-ID: <1411010270.42.0.688728201436.issue16827@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch, James. Did you see my review comments on Rietveld? Please see at http://bugs.python.org/review/16827/#ps11699 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 05:21:06 2014 From: report at bugs.python.org (Berker Peksag) Date: Thu, 18 Sep 2014 03:21:06 +0000 Subject: [issue19690] test_logging test_race failed with PermissionError In-Reply-To: <1385105475.94.0.253645069216.issue19690@psf.upfronthosting.co.za> Message-ID: <1411010466.58.0.916825044468.issue19690@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: -> needs patch type: -> behavior versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 06:07:27 2014 From: report at bugs.python.org (Berker Peksag) Date: Thu, 18 Sep 2014 04:07:27 +0000 Subject: [issue22399] Doc: missing anchor for dict in library/functions.html In-Reply-To: <1410553668.99.0.783608222954.issue22399@psf.upfronthosting.co.za> Message-ID: <1411013247.65.0.259938815484.issue22399@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 06:10:45 2014 From: report at bugs.python.org (Berker Peksag) Date: Thu, 18 Sep 2014 04:10:45 +0000 Subject: [issue21397] tempfile.py: Fix grammar in docstring, comment typos In-Reply-To: <1398854871.81.0.354739462705.issue21397@psf.upfronthosting.co.za> Message-ID: <1411013445.92.0.663501506393.issue21397@psf.upfronthosting.co.za> Berker Peksag added the comment: The latest patch LGTM. ---------- nosy: +berker.peksag stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 06:59:47 2014 From: report at bugs.python.org (Martin Panter) Date: Thu, 18 Sep 2014 04:59:47 +0000 Subject: =?utf-8?q?=5Bissue21049=5D_Warning_at_interpreter_exit_triggers_flood_of_?= =?utf-8?b?4oCcSW1wb3J0V2FybmluZzogc3lzLm1ldGFfcGF0aCBpcyBlbXB0eeKAnQ==?= In-Reply-To: <1395642335.41.0.483787590936.issue21049@psf.upfronthosting.co.za> Message-ID: <1411016387.42.0.531094778863.issue21049@psf.upfronthosting.co.za> Martin Panter added the comment: My original demonstration was distilled from a real world case. I get this issue with other real world cases too, so I am expanding the title to reflect what I think is going on. This problem seems to be caused by a ResourceWarning triggered from a garbage cycle being freed just before Python exits. The flood of ImportWarning lines makes it annoying to scroll up to see what other ResourceWarning messages, exceptions, etc you are missing out on. Much simpler one-liner demonstration adapted from Message 222403 (because class definitions create garbage cycles in my experience): python3 -Wall -c 'class C: a = open("/dev/null")' The best workaround is probably to use ?python -Wdefault? rather than ?python -Wall?. Then you only get one ImportWarning line. I suspect the problem might be caused by a recursive loop between emitting a warning and importing something, as Antoine hinted. Calling sys.setrecursionlimit(30) reduces the flood to 5 lines. Unfortunately my modifications to ?importlib/_bootstrap.py? and ?warnings.py? on my OS are not having any effect, otherwise I might try to make a patch. Perhaps if it is not appropriate for the ImportWarning to be removed, could the code printing out the warning be changed to avoid triggering it in the first place? ---------- title: Flood of ?ImportWarning: sys.meta_path is empty? after exception with socket subclass -> Warning at interpreter exit triggers flood of ?ImportWarning: sys.meta_path is empty? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 07:55:33 2014 From: report at bugs.python.org (Georg Brandl) Date: Thu, 18 Sep 2014 05:55:33 +0000 Subject: [issue22399] Doc: missing anchor for dict in library/functions.html In-Reply-To: <1410553668.99.0.783608222954.issue22399@psf.upfronthosting.co.za> Message-ID: <1411019733.1.0.259403547577.issue22399@psf.upfronthosting.co.za> Georg Brandl added the comment: The anchor for dict is on the "standard types" page: https://docs.python.org/2/library/stdtypes.html#dict You'll have to use :class: not :func: to get it linked. ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 09:25:51 2014 From: report at bugs.python.org (paul j3) Date: Thu, 18 Sep 2014 07:25:51 +0000 Subject: [issue22401] argparse: 'resolve' conflict handler damages the actions of the parent parser In-Reply-To: <1410673598.78.0.274465754789.issue22401@psf.upfronthosting.co.za> Message-ID: <1411025151.32.0.770686329053.issue22401@psf.upfronthosting.co.za> Changes by paul j3 : Added file: http://bugs.python.org/file36648/sample3.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 09:26:14 2014 From: report at bugs.python.org (paul j3) Date: Thu, 18 Sep 2014 07:26:14 +0000 Subject: [issue22401] argparse: 'resolve' conflict handler damages the actions of the parent parser In-Reply-To: <1410673598.78.0.274465754789.issue22401@psf.upfronthosting.co.za> Message-ID: <1411025174.25.0.461015947043.issue22401@psf.upfronthosting.co.za> Changes by paul j3 : Removed file: http://bugs.python.org/file36635/sample3.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 11:06:32 2014 From: report at bugs.python.org (diff 812) Date: Thu, 18 Sep 2014 09:06:32 +0000 Subject: [issue22430] Build failure if configure flags --prefix or --exec-prefix is set In-Reply-To: <1410960816.78.0.977499217062.issue22430@psf.upfronthosting.co.za> Message-ID: <1411031192.5.0.210709583821.issue22430@psf.upfronthosting.co.za> diff 812 added the comment: Found problem. After generating Makefile if comment string, contain LD_CONFIG_PATH all build success. Operating system Gentooo, python version 2.7.8 from ebuild and downloaded from origin site. # gcc -v Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.3/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.3/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.8.3/work/gcc-4.8.3/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.3 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.3 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.3/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.3/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/include/g++-v4 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.3/python --enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.8.3 p1.1, pie-0.5.9' --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj --disable-libgomp --disable-libmudflap --disable-libssp --disable-libquadmath --enable-lto --without-cloog Thread model: posix gcc version 4.8.3 (Gentoo 4.8.3 p1.1, pie-0.5.9) # emerge --info Portage 2.2.8-r1 (default/linux/amd64/13.0, gcc-4.8.3, glibc-2.19-r1, 3.16.0 x86_64) ================================================================= System uname: Linux-3.16.0-x86_64-Intel-R-_Core-TM-_i5-4200M_CPU_ at _2.50GHz-with-gentoo-2.2 KiB Mem: 7851264 total, 5629620 free KiB Swap: 10000424 total, 9632404 free Timestamp of tree: Tue, 16 Sep 2014 07:15:01 +0000 ld GNU ld (Gentoo 2.23.2 p1.0) 2.23.2 ccache version 3.1.9 [disabled] app-shells/bash: 4.2_p45 dev-java/java-config: 2.2.0 dev-lang/python: 2.7.8, 3.3.5-r1 dev-util/ccache: 3.1.9-r3 dev-util/cmake: 2.8.12.2-r1 dev-util/pkgconfig: 0.28-r1 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.12.4 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.11.6, 1.13.4 sys-devel/binutils: 2.23.2 sys-devel/gcc: 4.6.4, 4.7.3-r1, 4.8.3 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4.2-r1 sys-devel/make: 4.0-r1 sys-kernel/linux-headers: 3.13 (virtual/os-headers) sys-libs/glibc: 2.19-r1 Repositories: gentoo qt local ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=core-avx-i -msse4.2 -msse4.1 -maes -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=core-avx-i -msse4.2 -msse4.1 -maes -O2 -pipe" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--jobs 4 --load-average 8" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs buildpkg config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync metadata-transfer news parallel-fetch parallel-install preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://gentoo.kiev.ua/ftp/ http://portage.org.ua/ ftp://ftp.free.fr/mirrors/ftp.gentoo.org/" LANG="en_US.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/qt /usr/local/portage/local" SYNC="rsync://rsync1.ua.gentoo.org/gentoo-portage" USE="X a52 aac acl acpi alsa amd64 berkdb bluetooth bzip2 cairo cdr chm cli cracklib crypt css cxx djvu dri dvb dvi freetype gd gdbm gif glibc-omitfp gnutls gpm gstreamer gtk iconv icu ipv6 jabber jpeg lame lm_sensors maildir mmx modules mp3 mp4 mplayer mtp multilib ncurses nfsv3 nls nptl ogg opengl pam pcre readline session slang sse sse2 ssl ssse3 tcpd theora tiff udev unicode v4l v4l2 vaapi wifi wimax win32codecs x264 xcomposite xinerama xv xvid zlib" ABI_X86="64" ALSA_CARDS="hda-intel" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="efi-64 pc" INPUT_DEVICES="evdev synaptics keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en ru" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_3" RUBY_TARGETS="ruby19 ruby20" USERLAND="GNU" VIDEO_CARDS="radeon intel i965 i915 fglrx" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON What also information do you need? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 11:11:40 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 18 Sep 2014 09:11:40 +0000 Subject: [issue19380] Optimize parsing of regular expressions In-Reply-To: <1382645659.73.0.868235602026.issue19380@psf.upfronthosting.co.za> Message-ID: <1411031500.03.0.583376886084.issue19380@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Actually "if x:" is slightly faster than "if x is not None:" on current implementation. ---------- Added file: http://bugs.python.org/file36649/re_parse_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 11:54:25 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 18 Sep 2014 09:54:25 +0000 Subject: [issue22410] Locale dependent regexps on different locales In-Reply-To: <1410711803.67.0.827066928752.issue22410@psf.upfronthosting.co.za> Message-ID: <1411034065.07.0.85336433297.issue22410@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, it is possible to build full property table for bytes regexps at regexp compile time. But it is impossible for unicode regexps (issue22407). And in any case this doesn't solve original problem: re.match(pattern, string, re.L|re.I) can return unexpected result if the same pattern already was used with different locale. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 11:56:28 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 18 Sep 2014 09:56:28 +0000 Subject: [issue22415] Fix re debugging output In-Reply-To: <1410768434.94.0.831625656606.issue22415@psf.upfronthosting.co.za> Message-ID: <1411034188.57.0.57368977486.issue22415@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If there are no objections I'll commit the patch soon. ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 11:58:40 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 18 Sep 2014 09:58:40 +0000 Subject: [issue22434] Use named constants internally in the re module In-Reply-To: <1410970188.53.0.105353417029.issue22434@psf.upfronthosting.co.za> Message-ID: <1411034320.94.0.653624198762.issue22434@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If there are no objections I'll commit the patch soon. ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 12:01:17 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 18 Sep 2014 10:01:17 +0000 Subject: [issue20678] re does not allow back references in {} matching operator In-Reply-To: <1392756208.32.0.772076498816.issue20678@psf.upfronthosting.co.za> Message-ID: <1411034477.35.0.328689912886.issue20678@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 12:03:23 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 18 Sep 2014 10:03:23 +0000 Subject: [issue22362] Warn about octal escapes > 0o377 in re In-Reply-To: <1410174440.93.0.911211496637.issue22362@psf.upfronthosting.co.za> Message-ID: <1411034603.09.0.43560038799.issue22362@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Warning or exception? This is a question. ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 12:54:53 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 18 Sep 2014 10:54:53 +0000 Subject: [issue1519638] Unmatched Group issue - workaround Message-ID: <1411037693.5.0.325353352142.issue1519638@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch which make unmatched groups to be replaced by empty string. These changes looks rather as new feature than bug fix and therefore can be applied only to 3.5. ---------- components: +Library (Lib) keywords: +patch nosy: +serhiy.storchaka stage: -> patch review type: -> enhancement versions: +Python 3.5 -Python 2.6, Python 2.7 Added file: http://bugs.python.org/file36650/re_sub_unmatched_group.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 13:05:05 2014 From: report at bugs.python.org (Matthew Barnett) Date: Thu, 18 Sep 2014 11:05:05 +0000 Subject: [issue22410] Locale dependent regexps on different locales In-Reply-To: <1410711803.67.0.827066928752.issue22410@psf.upfronthosting.co.za> Message-ID: <1411038305.53.0.0234029635723.issue22410@psf.upfronthosting.co.za> Matthew Barnett added the comment: When you lookup the pattern in the cache, include the current locale as part of the key if the pattern is locale-sensitive (you can let it be None if the pattern is not locale-sensitive). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 14:44:27 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 18 Sep 2014 12:44:27 +0000 Subject: [issue22362] Warn about octal escapes > 0o377 in re In-Reply-To: <1410174440.93.0.911211496637.issue22362@psf.upfronthosting.co.za> Message-ID: <1411044267.24.0.440541300293.issue22362@psf.upfronthosting.co.za> STINNER Victor added the comment: > Warning or exception? This is a question. Using -Werror, warnings raise exceptions :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 15:11:46 2014 From: report at bugs.python.org (william tonkin) Date: Thu, 18 Sep 2014 13:11:46 +0000 Subject: [issue22382] sqlite3 connection built from apsw connection should raise IntegrityError, not DatabaseError In-Reply-To: <1410373815.55.0.143596528672.issue22382@psf.upfronthosting.co.za> Message-ID: <1411045906.47.0.406311332975.issue22382@psf.upfronthosting.co.za> Changes by william tonkin : ---------- nosy: +ghaering _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 15:17:06 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 18 Sep 2014 13:17:06 +0000 Subject: [issue22362] Warn about octal escapes > 0o377 in re In-Reply-To: <1410174440.93.0.911211496637.issue22362@psf.upfronthosting.co.za> Message-ID: <1411046226.05.0.365063653699.issue22362@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This is an error, so it should really be an exception. There's no use case for being lenient, IMO. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 15:17:17 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 18 Sep 2014 13:17:17 +0000 Subject: [issue22435] socketserver.TCPSocket leaks socket to garbage collector if server_bind() fails In-Reply-To: <1410999922.66.0.432841070426.issue22435@psf.upfronthosting.co.za> Message-ID: <1411046237.71.0.558083557488.issue22435@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 15:23:28 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 18 Sep 2014 13:23:28 +0000 Subject: [issue19380] Optimize parsing of regular expressions In-Reply-To: <1382645659.73.0.868235602026.issue19380@psf.upfronthosting.co.za> Message-ID: <1411046608.61.0.666754680195.issue19380@psf.upfronthosting.co.za> Antoine Pitrou added the comment: "is not None" is more readable, though. When using plain boolean testing, it's never obvious whether you can have a zero-length string, a null number, etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 15:38:10 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 18 Sep 2014 13:38:10 +0000 Subject: [issue16827] Remove the relatively advanced content from section 2 in tutorial In-Reply-To: <1356964896.19.0.673901752517.issue16827@psf.upfronthosting.co.za> Message-ID: <20140918133757.110108.41732@mail.hg.python.org> Roundup Robot added the comment: New changeset 2e3a81a0fa14 by Senthil Kumaran in branch '2.7': Issue #16827: Make Interpreter introduction section of the tutorial more https://hg.python.org/cpython/rev/2e3a81a0fa14 New changeset 1e81c7a261a7 by Senthil Kumaran in branch '3.4': Issue #16827: Make Interpreter introduction section of the tutorial more https://hg.python.org/cpython/rev/1e81c7a261a7 New changeset ea401e7c55e4 by Senthil Kumaran in branch 'default': merge from 3.4 https://hg.python.org/cpython/rev/ea401e7c55e4 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 15:40:24 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Thu, 18 Sep 2014 13:40:24 +0000 Subject: [issue16827] Remove the relatively advanced content from section 2 in tutorial In-Reply-To: <1356964896.19.0.673901752517.issue16827@psf.upfronthosting.co.za> Message-ID: <1411047624.15.0.688083078141.issue16827@psf.upfronthosting.co.za> Senthil Kumaran added the comment: I addressed Berker Peksag's review comments on Jame's patch, tested the local building of docs, verified the content and looks. Committed this in 2.7, 3.4 and 3.5. Thank you all! ---------- assignee: docs at python -> orsenthil resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 15:52:49 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 18 Sep 2014 13:52:49 +0000 Subject: [issue22410] Locale dependent regexps on different locales In-Reply-To: <1410711803.67.0.827066928752.issue22410@psf.upfronthosting.co.za> Message-ID: <1411048369.81.0.631997440993.issue22410@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch which implements Matthew's suggestion. It significant slow down the use of locale-sensitive regular expressions, there is a possibility for race condition between compiling and matching, and it doesn't solve the issue for explicitly cached expressions. Also I prefer that matching depends on locale at the time of matching, not at the time of compiling. This patch can be considered as nonperfect solution for 3.4 and 2.7. But for 3.5 I'll try to implement better solution. Microbenchmark: $ ./python -m timeit -s 'import re' -- 're.match(br"\w+", b"abc", re.L)' Before patch: 100000 loops, best of 3: 10.4 usec per loop After patch: 10000 loops, best of 3: 37.5 usec per loop ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file36651/re_locale_caching.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 15:54:04 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 18 Sep 2014 13:54:04 +0000 Subject: [issue22410] Locale dependent regexps on different locales In-Reply-To: <1410711803.67.0.827066928752.issue22410@psf.upfronthosting.co.za> Message-ID: <1411048444.01.0.00924375752291.issue22410@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Rather than introduce a perf regression in 2.7 and 3.4, I would suggest to simply fix the issue in 3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 16:11:51 2014 From: report at bugs.python.org (Matthew Barnett) Date: Thu, 18 Sep 2014 14:11:51 +0000 Subject: [issue22410] Locale dependent regexps on different locales In-Reply-To: <1410711803.67.0.827066928752.issue22410@psf.upfronthosting.co.za> Message-ID: <1411049511.68.0.618428735503.issue22410@psf.upfronthosting.co.za> Matthew Barnett added the comment: @Serhiy: You're overlooking that the LOCALE flag could be inline, e.g. r'(?L)\w+'. Basically, if you've seen the pattern before, you know whether it has an inline LOCALE flag; if you haven't seen the pattern before, you'll need to parse it anyway, and then you'll discover whether it has an inline LOCALE flag. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 16:26:28 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 18 Sep 2014 14:26:28 +0000 Subject: [issue22436] logging geteffectivelevel does not document its return value Message-ID: <1411050388.19.0.961403060223.issue22436@psf.upfronthosting.co.za> New submission from R. David Murray: https://docs.python.org/3/library/logging.html#logging.Logger.getEffectiveLevel This says the logging level is returned, but it doesn't mention that what is returned is an integer, nor does it link to whatever method is needed to convert the integer return value into the symbolic name that the user has been using elsewhere in interacting with logging. Indeed, the section that shows the mapping between names and numbers implies that the user of the library never needs to worry about the numbers unless they are creating a new level, but if they want to use getEffectiveLevel, this is not true. ---------- assignee: docs at python components: Documentation messages: 227047 nosy: docs at python, r.david.murray, vinay.sajip priority: normal severity: normal status: open title: logging geteffectivelevel does not document its return value type: behavior versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 16:50:52 2014 From: report at bugs.python.org (Demian Brecht) Date: Thu, 18 Sep 2014 14:50:52 +0000 Subject: [issue22278] urljoin duplicate slashes In-Reply-To: <1409075887.24.0.237889697027.issue22278@psf.upfronthosting.co.za> Message-ID: <1411051852.73.0.916420926001.issue22278@psf.upfronthosting.co.za> Demian Brecht added the comment: Antoine: On (finally) getting back to this and re-reading your test case, the current behaviour is incorrect and is corrected by the patch. I've added a few more test cases to ensure trailing slashes are handled correctly. ---------- Added file: http://bugs.python.org/file36652/issue22278_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 17:03:26 2014 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 18 Sep 2014 15:03:26 +0000 Subject: [issue22434] Use named constants internally in the re module In-Reply-To: <1410970188.53.0.105353417029.issue22434@psf.upfronthosting.co.za> Message-ID: <1411052606.54.0.148066024739.issue22434@psf.upfronthosting.co.za> Guido van Rossum added the comment: Hm. Could you not use the new Enum class? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 17:38:06 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 18 Sep 2014 15:38:06 +0000 Subject: [issue22410] Locale dependent regexps on different locales In-Reply-To: <1410711803.67.0.827066928752.issue22410@psf.upfronthosting.co.za> Message-ID: <1411054686.17.0.208991557999.issue22410@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Good catch Matthew! After fixing this and yet one bug (LC_CTYPE should be used instead of LC_ALL), and adding more optimizations, the performance is increased. Now the result of above microbenchmark is 18.5 usec per loop. ---------- Added file: http://bugs.python.org/file36653/re_locale_caching2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 18:14:49 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 18 Sep 2014 16:14:49 +0000 Subject: [issue22434] Use named constants internally in the re module In-Reply-To: <1410970188.53.0.105353417029.issue22434@psf.upfronthosting.co.za> Message-ID: <1411056889.22.0.204567318009.issue22434@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Answering Guido's question about the Enum class. No, it is not appropriate here. It has too cumbersome repr ( instead of IN_IGNORE). Enum function syntax can't by used because it enumerates values from 1. We need three Enum subclasses for three groups of constants, and fourth class for MAXREPEAT, and fifth base abstract class. To fit the Enum class to our need we need more boilerplate code than to implement minimal needed functionality from scratch. And I'm not sure that this will not create circular dependency. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 18:15:57 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 18 Sep 2014 16:15:57 +0000 Subject: [issue22410] Locale dependent regexps on different locales In-Reply-To: <1410711803.67.0.827066928752.issue22410@psf.upfronthosting.co.za> Message-ID: <1411056957.36.0.985794082382.issue22410@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file36651/re_locale_caching.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 18:36:07 2014 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 18 Sep 2014 16:36:07 +0000 Subject: [issue22436] logging geteffectivelevel does not document its return value In-Reply-To: <1411050388.19.0.961403060223.issue22436@psf.upfronthosting.co.za> Message-ID: <1411058166.99.0.939844705761.issue22436@psf.upfronthosting.co.za> Vinay Sajip added the comment: Users generally use integer values when specifying logging levels, unless they are e.g. using the configuration machinery, when they will specify strings (just because the configuration is in text files). I will update the documentation to try to make things clearer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 18:54:39 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 18 Sep 2014 16:54:39 +0000 Subject: [issue19380] Optimize parsing of regular expressions In-Reply-To: <1411046608.61.0.666754680195.issue19380@psf.upfronthosting.co.za> Message-ID: <1678274.70NzGKQmof@raxxla> Serhiy Storchaka added the comment: Well, then please look at re_parse_2.patch (it is still applied cleanly). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 19:03:18 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 18 Sep 2014 17:03:18 +0000 Subject: [issue22436] logging geteffectivelevel does not document its return value In-Reply-To: <1411050388.19.0.961403060223.issue22436@psf.upfronthosting.co.za> Message-ID: <20140918170241.110108.40471@mail.hg.python.org> Roundup Robot added the comment: New changeset dd17c3eda73c by Vinay Sajip in branch '2.7': Issue #22436: Improved documentation for getEffectiveLevel() and getLevelName(). https://hg.python.org/cpython/rev/dd17c3eda73c New changeset 72a91df86b07 by Vinay Sajip in branch '3.4': Issue #22436: Improved documentation for getEffectiveLevel() and getLevelName(). https://hg.python.org/cpython/rev/72a91df86b07 New changeset 49dfe2630ae3 by Vinay Sajip in branch 'default': Closes #22436: Merged documentation update from 3.4. https://hg.python.org/cpython/rev/49dfe2630ae3 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 19:39:42 2014 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 18 Sep 2014 17:39:42 +0000 Subject: [issue22437] re module: number of named groups is limited to 100 max Message-ID: <1411061982.07.0.646375842297.issue22437@psf.upfronthosting.co.za> New submission from Yury Selivanov: While writing a lexer for javascript language, I managed to hit the limit of named groups in one regexp, it's 100. The check is in sre_compile.py:compile() function, and there is even an XXX comment on this. Unfortunately, I'm not an expert in this module, so I'm not sure if this check can be lifted, or at least if the number can be bumped to 200 or 500 (why is 100 btw?) Please share your thoughts. ---------- components: Library (Lib), Regular Expressions messages: 227055 nosy: ezio.melotti, haypo, mrabarnett, pitrou, serhiy.storchaka, yselivanov priority: normal severity: normal status: open title: re module: number of named groups is limited to 100 max type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 19:53:15 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 18 Sep 2014 17:53:15 +0000 Subject: [issue22436] logging geteffectivelevel does not document its return value In-Reply-To: <1411050388.19.0.961403060223.issue22436@psf.upfronthosting.co.za> Message-ID: <1411062795.13.0.429007156207.issue22436@psf.upfronthosting.co.za> R. David Murray added the comment: Ah, yes, I was just being dense, because the context I was in was exactly that context: configuration via strings. Probably no change is required, but if can think of way of making it obvious to someone thinking crooked like I was that would be great. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 19:54:21 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 18 Sep 2014 17:54:21 +0000 Subject: [issue22436] logging geteffectivelevel does not document its return value In-Reply-To: <1411050388.19.0.961403060223.issue22436@psf.upfronthosting.co.za> Message-ID: <1411062861.25.0.939776032213.issue22436@psf.upfronthosting.co.za> R. David Murray added the comment: Woops, should have looked at the rest of my email. Yes, that change looks great. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 20:04:00 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 18 Sep 2014 18:04:00 +0000 Subject: [issue22437] re module: number of named groups is limited to 100 max In-Reply-To: <1411061982.07.0.646375842297.issue22437@psf.upfronthosting.co.za> Message-ID: <1411063440.16.0.537544845456.issue22437@psf.upfronthosting.co.za> R. David Murray added the comment: It is 100 to avoid a syntactic ambiguity between numbered groups and octal numbers, if I remember correctly. I can't remember if that constraint still applies in python3, where the octal notation was made more strict in general. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 20:06:44 2014 From: report at bugs.python.org (Jakub Wilk) Date: Thu, 18 Sep 2014 18:06:44 +0000 Subject: [issue22427] TemporaryDirectory attempts to clean up twice In-Reply-To: <1410931119.87.0.05617613507.issue22427@psf.upfronthosting.co.za> Message-ID: <1411063604.68.0.908505546905.issue22427@psf.upfronthosting.co.za> Changes by Jakub Wilk : ---------- nosy: +jwilk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 20:06:57 2014 From: report at bugs.python.org (Jakub Wilk) Date: Thu, 18 Sep 2014 18:06:57 +0000 Subject: [issue22417] PEP 476: verify HTTPS certificates by default In-Reply-To: <1410784469.95.0.475937020841.issue22417@psf.upfronthosting.co.za> Message-ID: <1411063617.99.0.543069833809.issue22417@psf.upfronthosting.co.za> Changes by Jakub Wilk : ---------- nosy: +jwilk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 20:26:11 2014 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 18 Sep 2014 18:26:11 +0000 Subject: [issue22434] Use named constants internally in the re module In-Reply-To: <1411056889.22.0.204567318009.issue22434@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: I think you are too casual in rejecting a standard approach over a custom clever hack. Making the values enums gives them a standard interface that goes beyond what you implemented, and just the fact that we can say "these are IntEnum instances" specifies a lot more of the semantics than pointing to your class hack. It's easy to make a subclass of IntEnum that overrides __repr__ and __str__. It's also easy enough to override the constructor to make the values start at 0 (though it would be a nice feature if we could add a keyword arg to the EnumMeta.__call__() definition to override the start position). I don't really care that this is more code. I don't see where there would be a circular dependency; the enum module doesn't import the re module. There is one thing that might be less convenient: defining an enum doesn't automatically make the values globals. But wouldn't the code be better if the values weren't globals? Finally. You objected to adding __all__ in the code review. That too, suggests a somewhat casual attitude. This code may be maintained by your grandchildren. Give them something future-proof, please. On Thu, Sep 18, 2014 at 9:14 AM, Serhiy Storchaka wrote: > > Serhiy Storchaka added the comment: > > Answering Guido's question about the Enum class. No, it is not appropriate > here. It has too cumbersome repr ( instead of > IN_IGNORE). Enum function syntax can't by used because it enumerates values > from 1. We need three Enum subclasses for three groups of constants, and > fourth class for MAXREPEAT, and fifth base abstract class. To fit the Enum > class to our need we need more boilerplate code than to implement minimal > needed functionality from scratch. And I'm not sure that this will not > create circular dependency. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 20:54:25 2014 From: report at bugs.python.org (Matthew Barnett) Date: Thu, 18 Sep 2014 18:54:25 +0000 Subject: [issue22437] re module: number of named groups is limited to 100 max In-Reply-To: <1411061982.07.0.646375842297.issue22437@psf.upfronthosting.co.za> Message-ID: <1411066465.74.0.0885115681894.issue22437@psf.upfronthosting.co.za> Matthew Barnett added the comment: In the regex module, I borrowed the \g<...> escape from .sub's replacement string to provide an alternative way to refer to a group in a pattern, and that let me remove the limit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 21:40:24 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 18 Sep 2014 19:40:24 +0000 Subject: [issue21308] PEP 466: backport ssl changes In-Reply-To: <9f606957-c0fc-42fe-b0e1-52ea1cb44333@email.android.com> Message-ID: <1411069224.7.0.112257451943.issue21308@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Note that this change broke eventlet: https://github.com/eventlet/eventlet/issues/135 ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 21:40:31 2014 From: report at bugs.python.org (Ned Deily) Date: Thu, 18 Sep 2014 19:40:31 +0000 Subject: [issue22430] Build failure if configure flags --prefix or --exec-prefix is set In-Reply-To: <1410960816.78.0.977499217062.issue22430@psf.upfronthosting.co.za> Message-ID: <1411069231.27.0.920585255265.issue22430@psf.upfronthosting.co.za> Ned Deily added the comment: Sorry, I don't see where you have shown exactly what Python ./configure and make commands you are using and it is not at all obvious to me what you mean by "After generating Makefile if comment string, contain LD_CONFIG_PATH all build success". But, if it is the case that you are using Gentoo tools to build ("python version 2.7.8 from ebuild") then perhaps you should be asking on a Gentoo forum as we have no control or specific knowledge of how Gentoo packages things. If you can show exactly how a Python build fails using an unpacked Python source package, the Python's ./configure and make, then we can investigate. In other words, we would need to see the exact sequence of the exact commands you use. There are just too many variables to try to guess what you might be seeing (other than my original speculation about Issue21166). Did you try the recommendations above in msg227011? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 22:36:02 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 18 Sep 2014 20:36:02 +0000 Subject: [issue22437] re module: number of named groups is limited to 100 max In-Reply-To: <1411061982.07.0.646375842297.issue22437@psf.upfronthosting.co.za> Message-ID: <1411072562.8.0.812199434108.issue22437@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There is two reasons for this limitation. First reason is mentioned by David. There is no syntax to backreference a group with number > 99 (but there is a syntax for conditional groups and for substitutions). Second reason is that current implementation of regexp engine uses an array of constant size for groups. Here is a patch which increases static limit to 1000 groups. It also allows to specify arbitrary group number in form of "(?P=number)". This is conformed to the syntax of conditional groups and for substitutions. ---------- keywords: +patch Added file: http://bugs.python.org/file36654/re_maxgroups.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 22:36:43 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 18 Sep 2014 20:36:43 +0000 Subject: [issue22437] re module: number of named groups is limited to 100 max In-Reply-To: <1411061982.07.0.646375842297.issue22437@psf.upfronthosting.co.za> Message-ID: <1411072603.19.0.0270439186255.issue22437@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka stage: -> patch review versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 22:53:23 2014 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 18 Sep 2014 20:53:23 +0000 Subject: [issue22437] re module: number of named groups is limited to 100 max In-Reply-To: <1411061982.07.0.646375842297.issue22437@psf.upfronthosting.co.za> Message-ID: <1411073603.46.0.323704825782.issue22437@psf.upfronthosting.co.za> Yury Selivanov added the comment: Serhiy, This is awesome! Is is possible to split the patch in two, and commit the one that just increases the groups limit to 3.4 as well? Thank you ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 23:08:21 2014 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 18 Sep 2014 21:08:21 +0000 Subject: [issue22364] Unify error messages of re and regex In-Reply-To: <1410178976.27.0.421938794422.issue22364@psf.upfronthosting.co.za> Message-ID: <1411074501.0.0.578723349365.issue22364@psf.upfronthosting.co.za> Mark Lawrence added the comment: How can anything that's in the stdlib be unified with something that's not in the stdlib and currently has no prospects of getting in the stdlib? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 23:13:27 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 18 Sep 2014 21:13:27 +0000 Subject: [issue22437] re module: number of named groups is limited to 100 max In-Reply-To: <1411073603.46.0.323704825782.issue22437@psf.upfronthosting.co.za> Message-ID: <18093134.oOvU5gnIO7@raxxla> Serhiy Storchaka added the comment: This is definitely not a bug fix. May be Matthew will commit it to the regex module and then you could use regex instead of re. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 23:21:12 2014 From: report at bugs.python.org (Alex Gaynor) Date: Thu, 18 Sep 2014 21:21:12 +0000 Subject: [issue22438] eventlet broke by python 2.7.x Message-ID: <1411075272.39.0.133162978572.issue22438@psf.upfronthosting.co.za> New submission from Alex Gaynor: https://github.com/eventlet/eventlet/issues/135 ---------- components: Library (Lib) messages: 227067 nosy: alex, benjamin.peterson, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou priority: normal severity: normal status: open title: eventlet broke by python 2.7.x versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 23:21:23 2014 From: report at bugs.python.org (Alex Gaynor) Date: Thu, 18 Sep 2014 21:21:23 +0000 Subject: [issue21308] PEP 466: backport ssl changes In-Reply-To: <9f606957-c0fc-42fe-b0e1-52ea1cb44333@email.android.com> Message-ID: <1411075283.36.0.0292508443099.issue21308@psf.upfronthosting.co.za> Alex Gaynor added the comment: Filed http://bugs.python.org/issue22438 to track it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 23:21:53 2014 From: report at bugs.python.org (Alex Gaynor) Date: Thu, 18 Sep 2014 21:21:53 +0000 Subject: [issue22438] eventlet broke by python 2.7.x In-Reply-To: <1411075272.39.0.133162978572.issue22438@psf.upfronthosting.co.za> Message-ID: <1411075313.33.0.132862707051.issue22438@psf.upfronthosting.co.za> Alex Gaynor added the comment: It looks like something was removed from the `_ssl` module; is that considered an implementation detail, or does it need to be added back? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 23:22:12 2014 From: report at bugs.python.org (Alex Gaynor) Date: Thu, 18 Sep 2014 21:22:12 +0000 Subject: [issue22438] eventlet broke by python 2.7.x In-Reply-To: <1411075272.39.0.133162978572.issue22438@psf.upfronthosting.co.za> Message-ID: <1411075332.55.0.651377548392.issue22438@psf.upfronthosting.co.za> Alex Gaynor added the comment: (It didn't have any direct tests as far as I can tell, which is why I didn't catch the "regression") ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 23:23:27 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 18 Sep 2014 21:23:27 +0000 Subject: [issue22438] eventlet broke by python 2.7.x In-Reply-To: <1411075272.39.0.133162978572.issue22438@psf.upfronthosting.co.za> Message-ID: <1411075407.51.0.555098374837.issue22438@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Certainly not an official API anyway. Let eventlet get their stuff straight. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 18 23:32:15 2014 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 18 Sep 2014 21:32:15 +0000 Subject: [issue16007] Improved Error message for failing re expressions In-Reply-To: <1348416868.74.0.37879499143.issue16007@psf.upfronthosting.co.za> Message-ID: <1411075935.13.0.688735916225.issue16007@psf.upfronthosting.co.za> Mark Lawrence added the comment: The original try/except that leads to the raise does not exist in the latest 3.5 code. I'd be inclined to close this as "out of date" for compatibility reasons if nothing else. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 00:19:45 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 18 Sep 2014 22:19:45 +0000 Subject: [issue22378] SO_MARK support for Linux In-Reply-To: <1410313373.25.0.741471917751.issue22378@psf.upfronthosting.co.za> Message-ID: <20140918221934.40068.94645@mail.hg.python.org> Roundup Robot added the comment: New changeset ca0aa0d89273 by Charles-Fran?ois Natali in branch 'default': Issue #22378: socket module: add SO_MARK. https://hg.python.org/cpython/rev/ca0aa0d89273 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 00:20:56 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 18 Sep 2014 22:20:56 +0000 Subject: [issue22378] SO_MARK support for Linux In-Reply-To: <1410313373.25.0.741471917751.issue22378@psf.upfronthosting.co.za> Message-ID: <1411078856.44.0.859507505289.issue22378@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Thanks, I committed a simpler version of the patch. ---------- resolution: -> fixed stage: test needed -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 00:21:51 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 18 Sep 2014 22:21:51 +0000 Subject: [issue22378] SO_MARK support for Linux In-Reply-To: <1410313373.25.0.741471917751.issue22378@psf.upfronthosting.co.za> Message-ID: <1411078911.19.0.67392629988.issue22378@psf.upfronthosting.co.za> STINNER Victor added the comment: > Patch for python 2.7 and 3.4 Only Python 3.5 accept new features. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 01:17:49 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Thu, 18 Sep 2014 23:17:49 +0000 Subject: [issue19380] Optimize parsing of regular expressions In-Reply-To: <1382645659.73.0.868235602026.issue19380@psf.upfronthosting.co.za> Message-ID: <1411082269.22.0.0576176096898.issue19380@psf.upfronthosting.co.za> Changes by Josh Rosenberg : ---------- nosy: +josh.rosenberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 01:33:01 2014 From: report at bugs.python.org (Sworddragon) Date: Thu, 18 Sep 2014 23:33:01 +0000 Subject: [issue22439] subprocess.PIPE.stdin.flush() causes to hang while subprocess.PIPE.stdin.close() not Message-ID: <1411083181.34.0.264014648396.issue22439@psf.upfronthosting.co.za> New submission from Sworddragon: On sending something to stdin of a process that was called with subprocess (for example diff) I have figured out that all is working fine if stdin is closed but flushing stdin will cause a hang (the same as nothing would be done). In the attachments is a testcase that shows this problem. If executed the application will hang but if #pipe.stdin.close() will be uncommented (and optionally pipe.stdin.flush() commented out) all is working fine. ---------- components: Library (Lib) files: test.py messages: 227076 nosy: Sworddragon priority: normal severity: normal status: open title: subprocess.PIPE.stdin.flush() causes to hang while subprocess.PIPE.stdin.close() not type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file36655/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 03:02:06 2014 From: report at bugs.python.org (Alex Gaynor) Date: Fri, 19 Sep 2014 01:02:06 +0000 Subject: [issue22366] urllib.request.urlopen shoudl take a "context" (SSLContext) argument In-Reply-To: <1410198352.63.0.605714024836.issue22366@psf.upfronthosting.co.za> Message-ID: <1411088526.96.0.499052839009.issue22366@psf.upfronthosting.co.za> Alex Gaynor added the comment: Just wanted to ping you on this Senthil about committing this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 03:40:18 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 19 Sep 2014 01:40:18 +0000 Subject: [issue22439] subprocess.PIPE.stdin.flush() causes to hang while subprocess.PIPE.stdin.close() not In-Reply-To: <1411083181.34.0.264014648396.issue22439@psf.upfronthosting.co.za> Message-ID: <1411090818.47.0.663626325473.issue22439@psf.upfronthosting.co.za> R. David Murray added the comment: This has nothing to do with subprocess. If you call a (blocking and unlimited) read() on a file, the read will not return until the file is closed. ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 04:38:55 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Fri, 19 Sep 2014 02:38:55 +0000 Subject: [issue22438] eventlet broke by python 2.7.x In-Reply-To: <1411075272.39.0.133162978572.issue22438@psf.upfronthosting.co.za> Message-ID: <1411094335.17.0.809672540936.issue22438@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 04:39:59 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Fri, 19 Sep 2014 02:39:59 +0000 Subject: [issue22438] eventlet broke by python 2.7.x In-Reply-To: <1411075272.39.0.133162978572.issue22438@psf.upfronthosting.co.za> Message-ID: <1411094399.32.0.572013471382.issue22438@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: I tend to agree. I don't even think it was documented. I wonder though if it makes sense to at least mention this in the PEP and/or release notes for 2.7.9. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 07:20:36 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 19 Sep 2014 05:20:36 +0000 Subject: [issue22438] eventlet broke by python 2.7.x In-Reply-To: <1411075272.39.0.133162978572.issue22438@psf.upfronthosting.co.za> Message-ID: <1411104036.72.0.514775888158.issue22438@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 08:08:05 2014 From: report at bugs.python.org (paul j3) Date: Fri, 19 Sep 2014 06:08:05 +0000 Subject: [issue22401] argparse: 'resolve' conflict handler damages the actions of the parent parser In-Reply-To: <1410673598.78.0.274465754789.issue22401@psf.upfronthosting.co.za> Message-ID: <1411106885.85.0.777071772706.issue22401@psf.upfronthosting.co.za> Changes by paul j3 : Added file: http://bugs.python.org/file36656/sample3.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 08:08:27 2014 From: report at bugs.python.org (paul j3) Date: Fri, 19 Sep 2014 06:08:27 +0000 Subject: [issue22401] argparse: 'resolve' conflict handler damages the actions of the parent parser In-Reply-To: <1410673598.78.0.274465754789.issue22401@psf.upfronthosting.co.za> Message-ID: <1411106907.55.0.628255512531.issue22401@psf.upfronthosting.co.za> Changes by paul j3 : Removed file: http://bugs.python.org/file36648/sample3.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 09:23:42 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 19 Sep 2014 07:23:42 +0000 Subject: [issue22366] urllib.request.urlopen shoudl take a "context" (SSLContext) argument In-Reply-To: <1410198352.63.0.605714024836.issue22366@psf.upfronthosting.co.za> Message-ID: <20140919072340.97812.11127@mail.hg.python.org> Roundup Robot added the comment: New changeset c0b0dda16009 by Senthil Kumaran in branch 'default': Issue #22366: urllib.request.urlopen will accept a context object (SSLContext) https://hg.python.org/cpython/rev/c0b0dda16009 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 09:26:02 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Fri, 19 Sep 2014 07:26:02 +0000 Subject: [issue22366] urllib.request.urlopen shoudl take a "context" (SSLContext) argument In-Reply-To: <1410198352.63.0.605714024836.issue22366@psf.upfronthosting.co.za> Message-ID: <1411111562.97.0.0849246066002.issue22366@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Committed this in 3.5. (Since this is adding an new argument, it should not be backported to 3.4). Thank you! ---------- resolution: -> fixed stage: -> resolved status: open -> closed versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 09:53:10 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Fri, 19 Sep 2014 07:53:10 +0000 Subject: [issue22440] Setting SSLContext object's check_hostname manually might accidentally skip hostname verification Message-ID: <1411113190.48.0.396840225305.issue22440@psf.upfronthosting.co.za> New submission from Senthil Kumaran: While working on issue22366, I found a tricky bit of code in: https://hg.python.org/cpython/file/ca0aa0d89273/Lib/http/client.py#l1295 https://hg.python.org/cpython/rev/1a945fb875bf/ The statement is if not self._context.check_hostname and self._check_hostname: The context object's check_hostname (created by ssl._create_stdlib_context() - note private ) is False by default and the statement holds good and acts only on self._check_hostname But if the context is constructed manually and the context object's check_hostname is set to True (with correct intentions), that statement will lead to skipping of matching hostname! Is my analysis right here? ---------- messages: 227082 nosy: alex, christian.heimes, dstufft, orsenthil, pitrou priority: normal severity: normal status: open title: Setting SSLContext object's check_hostname manually might accidentally skip hostname verification versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 10:00:14 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 19 Sep 2014 08:00:14 +0000 Subject: [issue22434] Use named constants internally in the re module In-Reply-To: <1410970188.53.0.105353417029.issue22434@psf.upfronthosting.co.za> Message-ID: <1411113614.13.0.291581810254.issue22434@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch using enums. I still think enums are superfluous here. Advanced the Enum class features (pickling, access by name, type checking) are not needed - these constants don't leaked in outer word. > I don't see where there would be a circular dependency; the enum module > doesn't import the re module. Right now there is no circular dependency. But the enum module imports collections which imports a lot of other modules, some of which import other modules. In future some of indirectly imported module can import the re module. > There is one thing that might be less convenient: defining an enum doesn't > automatically make the values globals. But wouldn't the code be better if > the values weren't globals? I afraid this will make the code of parser and compiler less readable and slower. In any case the sre_constants module itself is a namespace. ---------- Added file: http://bugs.python.org/file36657/re_opcode_enums.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 10:03:28 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 19 Sep 2014 08:03:28 +0000 Subject: [issue22364] Unify error messages of re and regex In-Reply-To: <1411074501.0.0.578723349365.issue22364@psf.upfronthosting.co.za> Message-ID: <4885270.8sfm5aXzfk@raxxla> Serhiy Storchaka added the comment: The regex module is potential candidate for replacement of the re module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 10:51:28 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 19 Sep 2014 08:51:28 +0000 Subject: [issue22427] TemporaryDirectory attempts to clean up twice In-Reply-To: <1410931119.87.0.05617613507.issue22427@psf.upfronthosting.co.za> Message-ID: <1411116688.17.0.715805984555.issue22427@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Fixed a bug in the test and partially addressed Victor's and Yury's comments. Antoine, could your pleas answer following question? Is it safe to remove the "self._finalizer is not None" check in cleanup()? I.e. is it possible that self._finalizer becomes None at garbage collection? ---------- Added file: http://bugs.python.org/file36658/tempfile_exit_on_shutdown3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 11:14:56 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Fri, 19 Sep 2014 09:14:56 +0000 Subject: [issue22278] urljoin duplicate slashes In-Reply-To: <1409075887.24.0.237889697027.issue22278@psf.upfronthosting.co.za> Message-ID: <1411118096.22.0.2623501461.issue22278@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Except for the minor comments made by Antoine in the review, the patch looks good to go. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 11:31:48 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 19 Sep 2014 09:31:48 +0000 Subject: [issue22410] Locale dependent regexps on different locales In-Reply-To: <1410711803.67.0.827066928752.issue22410@psf.upfronthosting.co.za> Message-ID: <1411119108.17.0.347907667043.issue22410@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Moved the import to the top level as Antoine suggested. ---------- Added file: http://bugs.python.org/file36659/re_locale_caching3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 11:35:51 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 19 Sep 2014 09:35:51 +0000 Subject: [issue22410] Locale dependent regexps on different locales In-Reply-To: <1410711803.67.0.827066928752.issue22410@psf.upfronthosting.co.za> Message-ID: <1411119351.26.0.078666052555.issue22410@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file36653/re_locale_caching2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 12:52:21 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 19 Sep 2014 10:52:21 +0000 Subject: [issue22427] TemporaryDirectory attempts to clean up twice In-Reply-To: <1410931119.87.0.05617613507.issue22427@psf.upfronthosting.co.za> Message-ID: <1411123941.79.0.603171558277.issue22427@psf.upfronthosting.co.za> Antoine Pitrou added the comment: self._finalizer can be None if an exception was raised during __init__(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 13:22:39 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 19 Sep 2014 11:22:39 +0000 Subject: [issue22427] TemporaryDirectory attempts to clean up twice In-Reply-To: <1411123941.79.0.603171558277.issue22427@psf.upfronthosting.co.za> Message-ID: <1613324.EkvKd2ciEU@raxxla> Serhiy Storchaka added the comment: But in this case cleanup() can't be called. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 14:27:06 2014 From: report at bugs.python.org (Sworddragon) Date: Fri, 19 Sep 2014 12:27:06 +0000 Subject: [issue22441] Not all attributes of the console for a subprocess with creationflags=0 are inherited Message-ID: <1411129626.26.0.561604681349.issue22441@psf.upfronthosting.co.za> New submission from Sworddragon: The application apt-get on Linux does scale its output dependent of the size of the terminal but I have noticed that there are differences if I'm calling apt-get directly or with a subprocess without shell and creationflags set (so that creationflags should be 0). From the documentation subprocess.CREATE_NEW_CONSOLE is not set so that apt-get does inherit the console and normally I would assume that this counts also for all attributes. In the attachments is a testcase for this issue. Also here are 2 screenshots to compare the results: Direct call: http://picload.org/image/crlrapg/normal.png Subprocess: http://picload.org/image/crlrapd/subprocess.png ---------- components: Library (Lib) files: test.py messages: 227090 nosy: Sworddragon priority: normal severity: normal status: open title: Not all attributes of the console for a subprocess with creationflags=0 are inherited type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file36660/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 14:40:38 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 19 Sep 2014 12:40:38 +0000 Subject: [issue22366] urllib.request.urlopen shoudl take a "context" (SSLContext) argument In-Reply-To: <1410198352.63.0.605714024836.issue22366@psf.upfronthosting.co.za> Message-ID: <1411130438.42.0.392696236238.issue22366@psf.upfronthosting.co.za> Larry Hastings added the comment: Alex said he needed this in order to implement PEP 476, and I thought PEP 476 was going in to 3.4 (hopefully for 3.4.2, which I'm tagging in like 24 hours). ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 15:30:06 2014 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 19 Sep 2014 13:30:06 +0000 Subject: [issue22366] urllib.request.urlopen shoudl take a "context" (SSLContext) argument In-Reply-To: <1410198352.63.0.605714024836.issue22366@psf.upfronthosting.co.za> Message-ID: <1411133405.99.0.720345222438.issue22366@psf.upfronthosting.co.za> Nick Coghlan added the comment: Larry, it's probably easiest to cover the backport under issue 22417 with the rest of the proposed PEP 476 changes. ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 15:38:56 2014 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 19 Sep 2014 13:38:56 +0000 Subject: [issue22417] PEP 476: verify HTTPS certificates by default In-Reply-To: <1410784469.95.0.475937020841.issue22417@psf.upfronthosting.co.za> Message-ID: <1411133936.24.0.391567249453.issue22417@psf.upfronthosting.co.za> Nick Coghlan added the comment: Currently marking as a deferred blocker, as Alex wasn't sure he'd be able to get PEP 476 fully updated in time for 3.4.2rc1, and was willing to accept waiting for 2.7.9 and 3.4.3 rather than delaying 3.4.2 any further. However, that was before Senthil accepted the patch in 22366 for 3.5, which means we're at "feature complete" for the proposed changes. There's still the issue 22366 backport patch, PEP update, docs updates and What's New updates to go, so assigning to Alex to decide if he wants to work with Larry to get this ready to go for 3.4.2 (noting that the PEP still needs the final tick of approval from Guido after being updated to reflect the proposed implementation). Otherwise we can get it ready for 2.7.9 with the other SSL changes, and it will appear in the 3.4.3 maintenance release, rather than 3.4.2. (Note that I'm busy most of this weekend, so +1 from me in advance if you decide to go ahead with getting it into 3.4.2) ---------- assignee: -> alex dependencies: +urllib.request.urlopen shoudl take a "context" (SSLContext) argument nosy: +benjamin.peterson priority: high -> deferred blocker versions: +Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 15:40:47 2014 From: report at bugs.python.org (Alex Gaynor) Date: Fri, 19 Sep 2014 13:40:47 +0000 Subject: [issue22440] Setting SSLContext object's check_hostname manually might accidentally skip hostname verification In-Reply-To: <1411113190.48.0.396840225305.issue22440@psf.upfronthosting.co.za> Message-ID: <1411134047.92.0.97506913121.issue22440@psf.upfronthosting.co.za> Alex Gaynor added the comment: If check_hostname is set on the context then do_handshake() will already perform the hostname check: https://hg.python.org/cpython/file/default/Lib/ssl.py#l787 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 15:56:39 2014 From: report at bugs.python.org (juj) Date: Fri, 19 Sep 2014 13:56:39 +0000 Subject: [issue22442] subprocess.check_call hangs on large PIPEd data. Message-ID: <1411134999.3.0.739689982343.issue22442@psf.upfronthosting.co.za> New submission from juj: On Windows, write a.py: import subprocess def ccall(cmdline, stdout, stderr): proc = subprocess.Popen(['python', 'b.py'], stdout=subprocess.PIPE, stderr=subprocess.PIPE) proc.communicate() if proc.returncode != 0: raise subprocess.CalledProcessError(proc.returncode, cmdline) return 0 # To fix subprocess.check_call, uncomment the following, which is functionally equivalent: # subprocess.check_call = ccall subprocess.check_call(['python', 'b.py'], stdout=subprocess.PIPE, stderr=subprocess.PIPE) print 'Finished!' Then write b.py: import sys str = 'aaa' for i in range(0,16): str = str + str for i in range(0,2): print >> sys.stderr, str for i in range(0,2): print str Finally, run 'python a.py'. The application will hang. Uncomment the specicied line to fix the execution. This is a documented failure on the python subprocess page, but why not just fix it up directly in python itself? One can think that modifying stdout or stderr is not the intent for subprocess.check_call, but python certainly should not hang because of that. ---------- components: Library (Lib) messages: 227095 nosy: juj priority: normal severity: normal status: open title: subprocess.check_call hangs on large PIPEd data. versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 16:05:24 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 19 Sep 2014 14:05:24 +0000 Subject: [issue22442] subprocess.check_call hangs on large PIPEd data. In-Reply-To: <1411134999.3.0.739689982343.issue22442@psf.upfronthosting.co.za> Message-ID: <1411135524.89.0.465522983878.issue22442@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- components: +Windows nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 16:05:53 2014 From: report at bugs.python.org (juj) Date: Fri, 19 Sep 2014 14:05:53 +0000 Subject: [issue22442] subprocess.check_call hangs on large PIPEd data. In-Reply-To: <1411134999.3.0.739689982343.issue22442@psf.upfronthosting.co.za> Message-ID: <1411135553.34.0.992099653531.issue22442@psf.upfronthosting.co.za> juj added the comment: The same observation applies to subprocess.call() as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 16:08:08 2014 From: report at bugs.python.org (Sworddragon) Date: Fri, 19 Sep 2014 14:08:08 +0000 Subject: [issue22443] read(1) blocks on unflushed output Message-ID: <1411135688.43.0.0648130638254.issue22443@psf.upfronthosting.co.za> New submission from Sworddragon: On reading the output of an application (for example "apt-get download firefox") that dynamically changes a line (possibly with the terminal control character \r) I have noticed that read(1) does not read the output until it has finished with a newline. This happens even with disabled buffering. In the attachments is a testcase for this problem. Also here are 2 screenshots to compare the results: Direct call: http://picload.org/image/crldgri/normal.png Subprocess: http://picload.org/image/crldgrw/subprocess.png ---------- components: Library (Lib) files: test.py messages: 227097 nosy: Sworddragon priority: normal severity: normal status: open title: read(1) blocks on unflushed output type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file36661/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 16:10:59 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 19 Sep 2014 14:10:59 +0000 Subject: [issue22443] read(1) blocks on unflushed output In-Reply-To: <1411135688.43.0.0648130638254.issue22443@psf.upfronthosting.co.za> Message-ID: <1411135859.34.0.502791535342.issue22443@psf.upfronthosting.co.za> STINNER Victor added the comment: > On reading the output of an application (for example "apt-get download firefox") that dynamically changes a line (possibly with the terminal control character \r) I have noticed that read(1) does not read the output until it has finished with a newline. The buffering of stdout and/or stderr of your application probably changes if the application runs in a terminal (TTY) or if the output is redirected to a pipe (not a TTY). Set the setvbuf() function. You can try my hack to disable buffering using LD_PRELOAD: https://bitbucket.org/haypo/misc/src/4d133ea3e46550808305b093557ee51d2de2ac9f/misc/nobuffer.c?at=default ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 16:13:06 2014 From: report at bugs.python.org (Sworddragon) Date: Fri, 19 Sep 2014 14:13:06 +0000 Subject: [issue22443] read(1) blocks on unflushed output In-Reply-To: <1411135688.43.0.0648130638254.issue22443@psf.upfronthosting.co.za> Message-ID: <1411135986.41.0.539019701132.issue22443@psf.upfronthosting.co.za> Changes by Sworddragon : Removed file: http://bugs.python.org/file36661/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 16:13:24 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 19 Sep 2014 14:13:24 +0000 Subject: [issue22427] TemporaryDirectory attempts to clean up twice In-Reply-To: <1410931119.87.0.05617613507.issue22427@psf.upfronthosting.co.za> Message-ID: <1411136004.61.0.215803670796.issue22427@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ah... you are right. It seems the None test has been superfluous all the time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 16:13:50 2014 From: report at bugs.python.org (Sworddragon) Date: Fri, 19 Sep 2014 14:13:50 +0000 Subject: [issue22443] read(1) blocks on unflushed output In-Reply-To: <1411135688.43.0.0648130638254.issue22443@psf.upfronthosting.co.za> Message-ID: <1411136030.3.0.162322725221.issue22443@psf.upfronthosting.co.za> Sworddragon added the comment: Edit: Updated testcase as I forgot to flush the output (in case somebody hints to it). ---------- Added file: http://bugs.python.org/file36662/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 16:20:29 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Fri, 19 Sep 2014 14:20:29 +0000 Subject: [issue22366] urllib.request.urlopen shoudl take a "context" (SSLContext) argument In-Reply-To: <1410198352.63.0.605714024836.issue22366@psf.upfronthosting.co.za> Message-ID: <1411136429.03.0.441209569121.issue22366@psf.upfronthosting.co.za> Senthil Kumaran added the comment: My worry is not about the timing. I can add it immediately, but are we convinced on having a new argument (API Change) for 3.4.2 ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 16:26:36 2014 From: report at bugs.python.org (Sworddragon) Date: Fri, 19 Sep 2014 14:26:36 +0000 Subject: [issue22443] read(1) blocks on unflushed output In-Reply-To: <1411135688.43.0.0648130638254.issue22443@psf.upfronthosting.co.za> Message-ID: <1411136796.25.0.71282467298.issue22443@psf.upfronthosting.co.za> Sworddragon added the comment: > The buffering of stdout and/or stderr of your application probably > changes if the application runs in a terminal (TTY) or if the output is > redirected to a pipe (not a TTY). Set the setvbuf() function. This means in the worst case there is currently no official way to get this output before it writes a newline? > You can try my hack to disable buffering using LD_PRELOAD: > https://bitbucket.org/haypo/misc/src/4d133ea3e46550808305b093557ee51d2de2ac9f/misc/nobuffer.c?at=default I will try later if I can successfully compile Python with this hack. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 16:41:05 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 19 Sep 2014 14:41:05 +0000 Subject: [issue22443] read(1) blocks on unflushed output In-Reply-To: <1411135688.43.0.0648130638254.issue22443@psf.upfronthosting.co.za> Message-ID: <1411137665.39.0.14837395544.issue22443@psf.upfronthosting.co.za> STINNER Victor added the comment: > This means in the worst case there is currently no official way to get this output before it writes a newline? The behaviour of stdout/stderr is defined in the C library, see setvbuf() manual for more information. I don't know a generic way to change the default buffering without modifying the application (or the LD_PRELOAD hack). > I will try later if I can successfully compile Python with this hack. You don't need to compile Python. Just compile nobuffer.c to libnobuffer.so. See the "documentation" in nobuffer.c. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 18:22:10 2014 From: report at bugs.python.org (Sworddragon) Date: Fri, 19 Sep 2014 16:22:10 +0000 Subject: [issue22443] read(1) blocks on unflushed output In-Reply-To: <1411135688.43.0.0648130638254.issue22443@psf.upfronthosting.co.za> Message-ID: <1411143730.42.0.169236751987.issue22443@psf.upfronthosting.co.za> Sworddragon added the comment: > You don't need to compile Python. Just compile nobuffer.c to > libnobuffer.so. See the "documentation" in nobuffer.c. Strictly following the documentation does not work: sworddragon at ubuntu:~/tmp$ gcc -shared -o nobuffer.so interceptor.c gcc: error: interceptor.c: No such file or directory gcc: fatal error: no input files compilation terminated. Trying to fix this results in this error: sworddragon at ubuntu:~/tmp$ gcc -shared -o nobuffer.so nobuffer.c /usr/bin/ld: /tmp/ccgArKHv.o: relocation R_X86_64_PC32 against undefined symbol `stdout@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 18:30:14 2014 From: report at bugs.python.org (Sworddragon) Date: Fri, 19 Sep 2014 16:30:14 +0000 Subject: [issue22439] subprocess.PIPE.stdin.flush() causes to hang while subprocess.PIPE.stdin.close() not In-Reply-To: <1411083181.34.0.264014648396.issue22439@psf.upfronthosting.co.za> Message-ID: <1411144214.2.0.881046077454.issue22439@psf.upfronthosting.co.za> Sworddragon added the comment: Why must stdin of the subprocess be closed so that a read() on stdout can return? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 18:51:38 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 19 Sep 2014 16:51:38 +0000 Subject: [issue22366] urllib.request.urlopen shoudl take a "context" (SSLContext) argument In-Reply-To: <1410198352.63.0.605714024836.issue22366@psf.upfronthosting.co.za> Message-ID: <20140919165121.54150.75749@mail.hg.python.org> Roundup Robot added the comment: New changeset 9c3249b358d0 by Alex Gaynor in branch 'default': PEP476: Updated based on proposed API from Nick. Also note that #22366 has been landed. https://hg.python.org/peps/rev/9c3249b358d0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 18:56:55 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 19 Sep 2014 16:56:55 +0000 Subject: [issue22444] Floor divide should return int Message-ID: <1411145815.79.0.695099073811.issue22444@psf.upfronthosting.co.za> New submission from Alexander Belopolsky: PEP 3141 defines floor division as floor(x/y) and specifies that floor() should return int type. Builtin float type has been made part of the PEP 3141 numerical tower, but floor division of two floats still results in a float. See also: * #1656 - Make math.{floor,ceil}(float) return ints per PEP 3141 * #1623 - Implement PEP-3141 for Decimal * https://mail.python.org/pipermail/python-ideas/2014-September/029392.html ---------- components: Interpreter Core messages: 227107 nosy: belopolsky priority: normal severity: normal stage: needs patch status: open title: Floor divide should return int type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 19:47:07 2014 From: report at bugs.python.org (Edward O) Date: Fri, 19 Sep 2014 17:47:07 +0000 Subject: [issue7434] general pprint rewrite In-Reply-To: <1259944363.21.0.149882342014.issue7434@psf.upfronthosting.co.za> Message-ID: <1411148827.9.0.932066375261.issue7434@psf.upfronthosting.co.za> Changes by Edward O : ---------- nosy: +eddygeek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 19:54:50 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 19 Sep 2014 17:54:50 +0000 Subject: [issue22439] subprocess.PIPE.stdin.flush() causes to hang while subprocess.PIPE.stdin.close() not In-Reply-To: <1411083181.34.0.264014648396.issue22439@psf.upfronthosting.co.za> Message-ID: <1411149290.95.0.853511714118.issue22439@psf.upfronthosting.co.za> R. David Murray added the comment: Because stdout isn't closed until the process completes, which happens when stdin is closed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 20:03:56 2014 From: report at bugs.python.org (Sworddragon) Date: Fri, 19 Sep 2014 18:03:56 +0000 Subject: [issue22439] subprocess.PIPE.stdin.flush() causes to hang while subprocess.PIPE.stdin.close() not In-Reply-To: <1411083181.34.0.264014648396.issue22439@psf.upfronthosting.co.za> Message-ID: <1411149836.88.0.314905606048.issue22439@psf.upfronthosting.co.za> Sworddragon added the comment: But this happens also on read(1). I'm even getting no partly output. 1. I'm calling diff in a way where it expects input to compare. 2. I'm writing and flushing to diff's stdin. 3. diff seems to not get this content until I close its stdin. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 20:09:20 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 19 Sep 2014 18:09:20 +0000 Subject: [issue22439] subprocess.PIPE.stdin.flush() causes to hang while subprocess.PIPE.stdin.close() not In-Reply-To: <1411083181.34.0.264014648396.issue22439@psf.upfronthosting.co.za> Message-ID: <1411150160.14.0.0519458321745.issue22439@psf.upfronthosting.co.za> R. David Murray added the comment: Try it at the command line. Diff doesn't produce any output in your example until stdin is closed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 20:31:33 2014 From: report at bugs.python.org (Stefan Krah) Date: Fri, 19 Sep 2014 18:31:33 +0000 Subject: [issue22444] Floor divide should return int In-Reply-To: <1411145815.79.0.695099073811.issue22444@psf.upfronthosting.co.za> Message-ID: <1411151493.91.0.301189798868.issue22444@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 20:35:40 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 19 Sep 2014 18:35:40 +0000 Subject: [issue22422] IDLE closes all when in dropdown menu In-Reply-To: <1410853910.37.0.784487772035.issue22422@psf.upfronthosting.co.za> Message-ID: <1411151740.26.0.256633723241.issue22422@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I cannot reproduce with Idle 3.4.1 on Win 7. Attempt 1: open Idle from icon (opens shell), edit file, make trivial change, return to shell, and type 'sys.'. When box appears, close shell, editor left untouched. Attempt 2: edit another file, type 'sys.', wait for box, and close editor 2. "Do you want to save before closing' message box appears. Click no, editor 2 closes, editor 1 is left untouched. Closing behavior has been patched in the last year or so. I suspect you are using an older and obsolete Idle. I also suspect everything closes because of an internal error now fixed. Start Idle from a console (command prompt) window with 'python -m idlelib' and I suspect you will see a traceback. Please either close this or provide a detailed scenario, including OS, using 2.7.8 or 3.4.1, that someone can reporduce. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 20:48:23 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 19 Sep 2014 18:48:23 +0000 Subject: [issue22433] Argparse considers unknown optional arguments with spaces as a known positional argument In-Reply-To: <1410969476.15.0.703805216421.issue22433@psf.upfronthosting.co.za> Message-ID: <1411152503.84.0.598311481783.issue22433@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +bethard _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 20:48:48 2014 From: report at bugs.python.org (Sworddragon) Date: Fri, 19 Sep 2014 18:48:48 +0000 Subject: [issue22439] subprocess.PIPE.stdin.flush() causes to hang while subprocess.PIPE.stdin.close() not In-Reply-To: <1411083181.34.0.264014648396.issue22439@psf.upfronthosting.co.za> Message-ID: <1411152528.36.0.861054608566.issue22439@psf.upfronthosting.co.za> Sworddragon added the comment: Ah, now I see it. Thanks for your hint. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 20:52:16 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 19 Sep 2014 18:52:16 +0000 Subject: [issue22434] Use named constants internally in the re module In-Reply-To: <1410970188.53.0.105353417029.issue22434@psf.upfronthosting.co.za> Message-ID: <1411152736.56.0.639623704057.issue22434@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 21:00:50 2014 From: report at bugs.python.org (Sebastian Berg) Date: Fri, 19 Sep 2014 19:00:50 +0000 Subject: [issue22445] Memoryviews require more strict contiguous checks then necessary Message-ID: <1411153250.02.0.529032306838.issue22445@psf.upfronthosting.co.za> New submission from Sebastian Berg: In NumPy we decided some time ago that if you have a multi dimensional buffer, shaped for example 1x10, then this buffer should be considered both C- and F-contiguous. Currently, some buffers which can be used validly in a contiguous fashion are rejected. CPython does not support this currently possibly creating smaller nuisance if/once we change it fully in NumPy, see for example https://github.com/numpy/numpy/issues/5085 I have attached a patch which should (sorry I did not test this at all yet) relax the checks as much as possible. I think this is right, but we did some subtle breaks in user code (mostly cython code) when we first tried changing it, and while numpy arrays may be more prominently C/F-contiguous, compatibility issues with libraries checking for contiguity explicitly and then requesting a strided buffer are very possible. If someone could give me a hint about adding tests, that would be great. Also I would like to add a small note to the PEP in any case regarding this subtlety, in the hope that more code will take care about such subtleties. ---------- components: Library (Lib) files: relaxed-strides-checking.patch keywords: patch messages: 227113 nosy: seberg priority: normal severity: normal status: open title: Memoryviews require more strict contiguous checks then necessary type: enhancement Added file: http://bugs.python.org/file36663/relaxed-strides-checking.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 22:16:21 2014 From: report at bugs.python.org (Stefan Krah) Date: Fri, 19 Sep 2014 20:16:21 +0000 Subject: [issue22445] Memoryviews require more strict contiguous checks then necessary In-Reply-To: <1411153250.02.0.529032306838.issue22445@psf.upfronthosting.co.za> Message-ID: <1411157781.88.0.964709529123.issue22445@psf.upfronthosting.co.za> Stefan Krah added the comment: There is another oddity: #12845. Does NumPy have a formal definition of array contiguity somewhere? ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 22:23:40 2014 From: report at bugs.python.org (Stefan Krah) Date: Fri, 19 Sep 2014 20:23:40 +0000 Subject: [issue22445] Memoryviews require more strict contiguous checks then necessary In-Reply-To: <1411153250.02.0.529032306838.issue22445@psf.upfronthosting.co.za> Message-ID: <1411158220.37.0.133327181966.issue22445@psf.upfronthosting.co.za> Stefan Krah added the comment: BTW, if you have NumPy installed and run test_buffer in Python3.3+, numpy.ndarray has many tests against memoryview and _testbuffer.ndarray (the latter is our exegesis of PEP-3118). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 22:25:45 2014 From: report at bugs.python.org (Sebastian Berg) Date: Fri, 19 Sep 2014 20:25:45 +0000 Subject: [issue22445] Memoryviews require more strict contiguous checks then necessary In-Reply-To: <1411153250.02.0.529032306838.issue22445@psf.upfronthosting.co.za> Message-ID: <1411158345.83.0.236082992891.issue22445@psf.upfronthosting.co.za> Sebastian Berg added the comment: #12845 should be closed, seems like a bug in some old version. The definition now is simply that the array is contiguous if you can legally access it in a contiguous fashion. Which means first stride is itemsize, second is itemsize*shape[0] for Fortran, inverted for C-order. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 22:30:20 2014 From: report at bugs.python.org (Ram Rachum) Date: Fri, 19 Sep 2014 20:30:20 +0000 Subject: [issue22446] Shortening code in abc.py Message-ID: <1411158620.58.0.416699245015.issue22446@psf.upfronthosting.co.za> New submission from Ram Rachum: Can't this code: class Sequence(Sized, Iterable, Container): # ... def __contains__(self, value): for v in self: if v == value: return True return False Be shortened into this: class Sequence(Sized, Iterable, Container): # ... def __contains__(self, value): return any(item == value for value in self) Which can even fit on one line with a lambda: class Sequence(Sized, Iterable, Container): # ... __contains__ = lambda self: any(item == value for value in self) ---------- components: Library (Lib) messages: 227117 nosy: cool-RR priority: normal severity: normal status: open title: Shortening code in abc.py versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 22:39:52 2014 From: report at bugs.python.org (Sebastian Berg) Date: Fri, 19 Sep 2014 20:39:52 +0000 Subject: [issue22445] Memoryviews require more strict contiguous checks then necessary In-Reply-To: <1411153250.02.0.529032306838.issue22445@psf.upfronthosting.co.za> Message-ID: <1411159192.28.0.809117600795.issue22445@psf.upfronthosting.co.za> Sebastian Berg added the comment: To be clear, the important part here, is that to me all elements *can* be accessed using that scheme. It is not correct to assume that `stride[-1]` or `stride[0]` is actually equal to `itemsize`. In other words, you have to be able to pass the pointer to the start of a c-contiguous array into some C-library that knows nothing about strides without any further thinking. The 0-strides badly violate that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 22:41:57 2014 From: report at bugs.python.org (Mark Lawrence) Date: Fri, 19 Sep 2014 20:41:57 +0000 Subject: [issue22364] Unify error messages of re and regex In-Reply-To: <1410178976.27.0.421938794422.issue22364@psf.upfronthosting.co.za> Message-ID: <1411159317.47.0.513528449052.issue22364@psf.upfronthosting.co.za> Mark Lawrence added the comment: The key word is "potential". I do not believe that any changes should be made to the re module until such time as there is a fully approved PEP for the regex module and that work has actually started on getting it into the stdlib. Surely backward compatibility also comes into this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 22:57:15 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 19 Sep 2014 20:57:15 +0000 Subject: [issue22446] Shortening code in abc.py In-Reply-To: <1411158620.58.0.416699245015.issue22446@psf.upfronthosting.co.za> Message-ID: <1411160235.21.0.465068413045.issue22446@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is slower. >>> import timeit >>> class A(list): ... def __contains__(self, value): ... for v in self: ... if v == value: ... return True ... return False ... >>> timeit.timeit('500 in x', setup='from __main__ import A; x = A(range(1000))', number=10000) 1.1222619999971357 >>> class B(list): ... def __contains__(self, value): ... return any(v == value for v in self) ... >>> timeit.timeit('500 in x', setup='from __main__ import B; x = B(range(1000))', number=10000) 2.05952100000286 ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 22:59:35 2014 From: report at bugs.python.org (Ram Rachum) Date: Fri, 19 Sep 2014 20:59:35 +0000 Subject: [issue22446] Shortening code in abc.py In-Reply-To: <1411158620.58.0.416699245015.issue22446@psf.upfronthosting.co.za> Message-ID: <1411160375.68.0.715003151629.issue22446@psf.upfronthosting.co.za> Ram Rachum added the comment: Oh. I wonder why `any` is slow like that, you'd figure it's be optimized. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 23:06:21 2014 From: report at bugs.python.org (Ed Sesek) Date: Fri, 19 Sep 2014 21:06:21 +0000 Subject: [issue22447] logging.config.fileConfig attempts to write to file even when none configured Message-ID: <1411160781.56.0.728660343296.issue22447@psf.upfronthosting.co.za> New submission from Ed Sesek: See the attached config file. logging.config.fileConfig() is attempting to write to the file specified in the file_handler section even though that handler is not configured for use in this config. If its going to write to the file, it should only do so if the file is configured to be used. In the case where it cannot write to the file it throws an exception with a blank message. ---------- components: Library (Lib) files: pixcli_template.ini messages: 227122 nosy: esesek priority: normal severity: normal status: open title: logging.config.fileConfig attempts to write to file even when none configured type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file36664/pixcli_template.ini _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 23:12:38 2014 From: report at bugs.python.org (Stefan Krah) Date: Fri, 19 Sep 2014 21:12:38 +0000 Subject: [issue12845] PEP-3118: C-contiguity with zero strides In-Reply-To: <1314354585.27.0.717961402517.issue12845@psf.upfronthosting.co.za> Message-ID: <1411161158.47.0.899344560357.issue12845@psf.upfronthosting.co.za> Stefan Krah added the comment: This was a bug in NumPy that has been fixed. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 23:15:54 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 19 Sep 2014 21:15:54 +0000 Subject: [issue22446] Shortening code in abc.py In-Reply-To: <1411160375.68.0.715003151629.issue22446@psf.upfronthosting.co.za> Message-ID: <19601905.xO6J7KDMM5@raxxla> Serhiy Storchaka added the comment: Because in first case there is one iterator, iter(self), and in second case there are two iterators: iter(self) and iter((v == value for v in self)). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 23:21:03 2014 From: report at bugs.python.org (Ram Rachum) Date: Fri, 19 Sep 2014 21:21:03 +0000 Subject: [issue22446] Shortening code in abc.py In-Reply-To: <1411158620.58.0.416699245015.issue22446@psf.upfronthosting.co.za> Message-ID: <1411161663.36.0.548663633967.issue22446@psf.upfronthosting.co.za> Ram Rachum added the comment: Thanks for the clarification. Oh well, sad to see the more verbose code win, but I guess that's life. I tried on PyPy but the difference was even more pronounced, 0.008922450399566156 for the long version and 0.042124665810088044 for the short version. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 23:21:36 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Fri, 19 Sep 2014 21:21:36 +0000 Subject: [issue22435] socketserver.TCPSocket leaks socket to garbage collector if server_bind() fails In-Reply-To: <1410999922.66.0.432841070426.issue22435@psf.upfronthosting.co.za> Message-ID: <1411161696.16.0.374037032857.issue22435@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Patch attached. The test wouldn't result in FD exhaustion on CPython because of the reference counting, but should still trigger RessourceWarning. ---------- keywords: +patch nosy: +haypo, pitrou stage: -> patch review Added file: http://bugs.python.org/file36665/socketserver_bind_leak.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 23:35:58 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 19 Sep 2014 21:35:58 +0000 Subject: [issue22446] Shortening code in abc.py In-Reply-To: <1411158620.58.0.416699245015.issue22446@psf.upfronthosting.co.za> Message-ID: <1411162558.72.0.741382039104.issue22446@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 19 23:37:12 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 19 Sep 2014 21:37:12 +0000 Subject: [issue22438] eventlet broke by python 2.7.x In-Reply-To: <1411075272.39.0.133162978572.issue22438@psf.upfronthosting.co.za> Message-ID: <1411162632.79.0.155409597333.issue22438@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Definitely a case of eventlet playing with fire (private apis). ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 00:00:35 2014 From: report at bugs.python.org (Stefan Krah) Date: Fri, 19 Sep 2014 22:00:35 +0000 Subject: [issue22445] Memoryviews require more strict contiguous checks then necessary In-Reply-To: <1411153250.02.0.529032306838.issue22445@psf.upfronthosting.co.za> Message-ID: <1411164035.65.0.415338086084.issue22445@psf.upfronthosting.co.za> Stefan Krah added the comment: Thanks, #12845 is indeed fixed in NumPy. Why does NumPy consider an array with a stride that will almost certainly lead to undefined behavior (unless you compile with -fwrapv) as valid? In CPython we try to eliminate these kinds of issues (though they may still be present). >>> import numpy as np import io x = np.arange(10) y = np.array([x]) print(y.strides) (9223372036854775807, 8) >>> >>> >>> y.flags C_CONTIGUOUS : True F_CONTIGUOUS : True OWNDATA : True WRITEABLE : True ALIGNED : True UPDATEIFCOPY : False ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 00:12:38 2014 From: report at bugs.python.org (Sebastian Berg) Date: Fri, 19 Sep 2014 22:12:38 +0000 Subject: [issue22445] Memoryviews require more strict contiguous checks then necessary In-Reply-To: <1411153250.02.0.529032306838.issue22445@psf.upfronthosting.co.za> Message-ID: <1411164758.15.0.630260881211.issue22445@psf.upfronthosting.co.za> Sebastian Berg added the comment: Well, the 9223372036854775807 is certainly no good for production code and we would never have it in a release version, it is just there currently to expose if there are more problems. However I don't care what happens on overflow (as long as it is not an error). Note that the stride here is on a dimension with shape 1. The only valid index is thus always 0 and 0*9223372036854775807=0, so the stride value does not actually matter when calculating offsets into the array. You could simply set it to 80 to get something that would be considered C-contiguous or to 8 to get something that is considered F-contiguous. But both is the case in a way, so just "cleaning up" the strides does not actually get you all the way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 00:55:24 2014 From: report at bugs.python.org (Berker Peksag) Date: Fri, 19 Sep 2014 22:55:24 +0000 Subject: [issue22447] logging.config.fileConfig attempts to write to file even when none configured In-Reply-To: <1411160781.56.0.728660343296.issue22447@psf.upfronthosting.co.za> Message-ID: <1411167324.07.0.746487089996.issue22447@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 01:03:38 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 19 Sep 2014 23:03:38 +0000 Subject: [issue22364] Improve some re error messages using regex for hints In-Reply-To: <1410178976.27.0.421938794422.issue22364@psf.upfronthosting.co.za> Message-ID: <1411167818.42.0.316435976643.issue22364@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Steven and Mark are correct that a tracker patch cannot change a 3rd party module. On the other hand, we are free to improve error messages in new versions. And we are free to borrow ideas from 3rd part modules. I changed the title accordingly. (Back compatibility comes into play in not making message enhancements in bugfix releases even though message details are not part of the documented API. People who write code that depends on those details, and doctexts need not so depend, should expect to revise for new versions. I expect that some of our re tests would need to be changed.) Re and regex are a bit special in that regex is the only re replacement (that I know of) and is (almost) a drop-in replacement. So some people *are*, on their own, replacing re with regex by installing regex (easy with pip) and adding 'import regex as re' at the top of their code. Serhiy suggested either picking the best or writing a new one, I think a new one combining both would be best in many of the cases. As a user, I like "name missing terminal '>'" for #2 (is there an adjective for a name in this context?) and for #4, "group name missing terminal '>'". (Note that we usually quote literals, as in #8.) For #12, I would like a parallel construction "set expression missing terminal ']'" if that is possible. But the currently vague re message "unexpected end of regular expression" might be raised as a point where the specific information is lost and only the general version is correct. As for #14, either UNICODE and LOCALE *are* compatible (for re) or this is buggy. >>> import re >>> re.compile(r'\w', re.UNICODE | re.LOCALE) re.compile('\\w', re.LOCALE|re.UNICODE) ---------- title: Unify error messages of re and regex -> Improve some re error messages using regex for hints _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 01:20:29 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 19 Sep 2014 23:20:29 +0000 Subject: [issue22443] read(1) blocks on unflushed output In-Reply-To: <1411135688.43.0.0648130638254.issue22443@psf.upfronthosting.co.za> Message-ID: <1411168829.01.0.240481846677.issue22443@psf.upfronthosting.co.za> STINNER Victor added the comment: Ah yes, try "gcc -shared nobuffer.c -o libnobuffer.so -fPIC". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 01:20:30 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 19 Sep 2014 23:20:30 +0000 Subject: [issue22445] Memoryviews require more strict contiguous checks then necessary In-Reply-To: <1411153250.02.0.529032306838.issue22445@psf.upfronthosting.co.za> Message-ID: <1411168830.09.0.772397731868.issue22445@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 01:23:14 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 19 Sep 2014 23:23:14 +0000 Subject: [issue22385] Define a binary output formatting mini-language for *.hex() In-Reply-To: <1410393301.25.0.193851592698.issue22385@psf.upfronthosting.co.za> Message-ID: <1411168994.21.0.668635393578.issue22385@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 01:56:03 2014 From: report at bugs.python.org (Steven D'Aprano) Date: Fri, 19 Sep 2014 23:56:03 +0000 Subject: [issue22364] Unify error messages of re and regex In-Reply-To: <1411159317.47.0.513528449052.issue22364@psf.upfronthosting.co.za> Message-ID: <20140919235556.GV9293@ando.pearwood.info> Steven D'Aprano added the comment: On Fri, Sep 19, 2014 at 08:41:57PM +0000, Mark Lawrence wrote: > I do not believe that any changes should be made to the re module > until such time as there is a fully approved PEP [....] Why is this so controversial? We're not talking about functional changes to the re module, we're talking about improving error messages. Firstly, the actual wording of error messages are not part of the API and are subject to change without notice. Secondly, nobody is talking about keeping the two modules syncronised on an on-going basis. This is just to improve the re error messages using regex as inspiration. ---------- title: Improve some re error messages using regex for hints -> Unify error messages of re and regex _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 01:56:12 2014 From: report at bugs.python.org (Sworddragon) Date: Fri, 19 Sep 2014 23:56:12 +0000 Subject: [issue22443] read(1) blocks on unflushed output In-Reply-To: <1411135688.43.0.0648130638254.issue22443@psf.upfronthosting.co.za> Message-ID: <1411170972.23.0.343356904884.issue22443@psf.upfronthosting.co.za> Sworddragon added the comment: I was able to compile the library but after executing "LD_PRELOAD=./libnobuffer.so ./test.py" I'm seeing no difference. The unflushed output is still not being read with read(1). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 02:02:25 2014 From: report at bugs.python.org (eryksun) Date: Sat, 20 Sep 2014 00:02:25 +0000 Subject: [issue22443] read(1) blocks on unflushed output In-Reply-To: <1411135688.43.0.0648130638254.issue22443@psf.upfronthosting.co.za> Message-ID: <1411171345.09.0.6105488497.issue22443@psf.upfronthosting.co.za> eryksun added the comment: stdbuf is the typical way to apply the LD_PRELOAD trick: https://www.gnu.org/software/coreutils/manual/html_node/stdbuf-invocation.html There's also the "unbuffer" expect script: http://expect.sourceforge.net/example/unbuffer.man.html ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 02:10:53 2014 From: report at bugs.python.org (Sworddragon) Date: Sat, 20 Sep 2014 00:10:53 +0000 Subject: [issue22443] read(1) blocks on unflushed output In-Reply-To: <1411135688.43.0.0648130638254.issue22443@psf.upfronthosting.co.za> Message-ID: <1411171853.1.0.496329022811.issue22443@psf.upfronthosting.co.za> Sworddragon added the comment: "stdbuf -o 0 ./test.py" and "unbuffer ./test.py" doesn't change the result too. Or is something wrong with my testcase? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 02:14:01 2014 From: report at bugs.python.org (Joshua Moore-Oliva) Date: Sat, 20 Sep 2014 00:14:01 +0000 Subject: [issue22448] call_at/call_later with Timer cancellation can result in (practically) unbounded memory usage. Message-ID: <1411172040.41.0.974691283228.issue22448@psf.upfronthosting.co.za> New submission from Joshua Moore-Oliva: The core issue stems from the implementation of Timer cancellation. (which features like asyncio.wait_for build upon). BaseEventLoop stores scheduled events in an array backed heapq named _scheduled. Once an event has been scheduled with call_at, cancelling the event only marks the event as cancelled, it does not remove it from the array backed heap. It is only removed once the cancelled event is at the next scheduled event for the loop. In a system where many events are run (and then cancelled) that may have long timeout periods, and there always exists at least one event that is scheduled for an earlier time, memory use is practically unbounded. The attached program wait_for.py demonstrates a trivial example where memory use is practically unbounded for an hour of time. This is the case even though the program only ever has two "uncancelled" events and two coroutines at any given time in its execution. This could be fixed in a variety of ways: a) Timer cancellation could result in the object being removed from the heap like in the sched module. This would be at least O(N) where N is the number of scheduled events. b) Timer cancellation could trigger a callback that tracks the number of cancelled events in the _scheduled list. Once this number exceeds a threshold ( 50% ? ), the list could be cleared of all cancelled events and then be re-heapified. c) A balanced tree structure could be used to implement the scheduled events O(log N) time complexity (current module is O(log N) for heappop anyways). Given python's lack of a balanced tree structure in the standard library, I assume option c) is a non-starter. I would prefer option b) over option a) as when there are a lot of scheduled events in the system (upwards of 50,000 - 100,000 in some of my use cases) the amortized complexity for cancelling an event trends towards O(1) (N/2 cancellations are handled by a single O(N) event) at the cost of slightly more, but bounded relative to the amount of events, memory. I would be willing to take a shot at implementing this patch with the most agreeable option. Please let me know if that would be appreciated, or if someone else would rather tackle this issue. (First time bug report for python, not sure of the politics/protocols involved). Disclaimer that I by no means an asyncio expert, my understanding of the code base is based on my reading of it debugging this memory leak. ---------- components: asyncio files: wait_for.py messages: 227136 nosy: chatgris, gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: call_at/call_later with Timer cancellation can result in (practically) unbounded memory usage. type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file36666/wait_for.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 02:16:19 2014 From: report at bugs.python.org (Sworddragon) Date: Sat, 20 Sep 2014 00:16:19 +0000 Subject: [issue22441] Not all attributes of the console for a subprocess with creationflags=0 are inherited In-Reply-To: <1411129626.26.0.561604681349.issue22441@psf.upfronthosting.co.za> Message-ID: <1411172179.0.0.271841913628.issue22441@psf.upfronthosting.co.za> Changes by Sworddragon : Removed file: http://bugs.python.org/file36660/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 02:16:32 2014 From: report at bugs.python.org (Sworddragon) Date: Sat, 20 Sep 2014 00:16:32 +0000 Subject: [issue22441] Not all attributes of the console for a subprocess with creationflags=0 are inherited In-Reply-To: <1411129626.26.0.561604681349.issue22441@psf.upfronthosting.co.za> Message-ID: <1411172192.79.0.877251384845.issue22441@psf.upfronthosting.co.za> Changes by Sworddragon : Added file: http://bugs.python.org/file36667/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 02:21:54 2014 From: report at bugs.python.org (Sworddragon) Date: Sat, 20 Sep 2014 00:21:54 +0000 Subject: [issue22441] Not all attributes of the console for a subprocess with creationflags=0 are inherited In-Reply-To: <1411129626.26.0.561604681349.issue22441@psf.upfronthosting.co.za> Message-ID: <1411172514.64.0.666804546067.issue22441@psf.upfronthosting.co.za> Sworddragon added the comment: Edit: Updated testcase as it contained an unneeded argument from an older testcase (in case it confuses somebody). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 02:35:17 2014 From: report at bugs.python.org (Akira Li) Date: Sat, 20 Sep 2014 00:35:17 +0000 Subject: [issue22442] subprocess.check_call hangs on large PIPEd data. In-Reply-To: <1411134999.3.0.739689982343.issue22442@psf.upfronthosting.co.za> Message-ID: <1411173317.9.0.0557618249228.issue22442@psf.upfronthosting.co.za> Akira Li added the comment: > This is a documented failure on the python subprocess page, > but why not just fix it up directly in python itself? If you want to discard the output; you could use: check_call(args, stdin=DEVNULL, stdout=DEVNULL, stderr=STDOUT) check_call() passes its parameters to Popen() as is. The only parameter it knows about is args that is used to raise an exception. Do you want check_call() to inspect the parameters and to do something about stdout=PIPE, stderr=PIPE? Where "something" could be: - nothing -- the current behavior: everything works until the child process produces enough output to fill any of OS pipe buffers as documented - call proc.communicate() -- store (unlimited) output in memory instead of just hanging: everything works slowly until the system runs out of memory - replace with DEVNULL -- "do what I mean" behavior: inconsistent with the direct Popen() call - raise ValueError with informative error message (about DEVNULL option) after issueing a DeprecationWarning for a release: it fixes this particular misuse of check_call(). Are there other common "wrong in every case" check_call() parameters? ---------- nosy: +akira _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 03:07:45 2014 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 20 Sep 2014 01:07:45 +0000 Subject: [issue22448] call_at/call_later with Timer cancellation can result in (practically) unbounded memory usage. In-Reply-To: <1411172040.41.0.974691283228.issue22448@psf.upfronthosting.co.za> Message-ID: <1411175265.51.0.0536478077389.issue22448@psf.upfronthosting.co.za> Guido van Rossum added the comment: Hi Joshua, This is indeed a problem -- I just never expected that you would be having that many events and and canceling the majority. I am sorry you had to debug this. :-( This was anticipated by the author of pyftpdlib (Giampaolo Roloda'), who proposed an elegant solution: keep track of the number of cancelled events, and when the number gets too high (according to some measure) the heapq is simply rebuilt by filtering out cancelled events. I think this is similar to your proposal (b). I would love it if you could implement this! Just make sure to add some tests and follow the PEP 8 style guide. You can contribute upstream to the Tulip project first. https://code.google.com/p/tulip/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 04:39:50 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 20 Sep 2014 02:39:50 +0000 Subject: [issue22420] Use print(file=sys.stderr) instead of sys.stderr.write() in IDLE In-Reply-To: <1410808520.06.0.74767353905.issue22420@psf.upfronthosting.co.za> Message-ID: <20140920023948.97822.21128@mail.hg.python.org> Roundup Robot added the comment: New changeset 90a2a12fa34d by Terry Jan Reedy in branch '2.7': Issue #22420: Avoid 'write to None' crashes by using print instead. https://hg.python.org/cpython/rev/90a2a12fa34d New changeset 42b03d5b1cbb by Terry Jan Reedy in branch '3.4': Issue #22420: Avoid 'write to None' crashes by using print instead. https://hg.python.org/cpython/rev/42b03d5b1cbb New changeset ab050bd7e51c by Terry Jan Reedy in branch 'default': Issue #22420: Merge with 3.4 https://hg.python.org/cpython/rev/ab050bd7e51c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 04:41:02 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 20 Sep 2014 02:41:02 +0000 Subject: [issue22420] Use print(file=sys.stderr) instead of sys.stderr.write() in IDLE In-Reply-To: <1410808520.06.0.74767353905.issue22420@psf.upfronthosting.co.za> Message-ID: <1411180862.23.0.632548971652.issue22420@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 04:56:29 2014 From: report at bugs.python.org (Akira Li) Date: Sat, 20 Sep 2014 02:56:29 +0000 Subject: [issue22377] %Z in strptime doesn't match EST and others In-Reply-To: <1410301455.57.0.912701656833.issue22377@psf.upfronthosting.co.za> Message-ID: <1411181789.57.0.23832418806.issue22377@psf.upfronthosting.co.za> Akira Li added the comment: > I don't think we are going to support a timezone list like that without PEP 431. PEP 431 won't fix this issue. See below. > You should attach your patch to a new issue. When I said this should > the doc issue, that is because only a doc fix is acceptable for 3.4. > Adding more timezones to recognize would be an enhancement, given the > complexity of the proposed solution. The docs are correct (they imply that %Z should accept EST). It is the implementation that is deficient. The patch introduces a new parameter therefore I agree: it should be applied only in 3.5+ > On the other hand, if timezone names are ambiguous, I'm not sure there > *is* a fix other than using the "defacto standard" names and offsets > used by the email library. Actually, isn't there a written standard > that addresses this issue? I seem to remember reading a discussion of > the problem somewhere... Multi-timezone programming email._parseaddr._timezones with CST=-600 is like US-ASCII (the standard). Code that uses local timezone is bilingual (locale-based): CST=-600 in Chicago but it is CST=+800 in China and it may be something else in other parts of the world. The *timezones* parameter in my patch allows to specify the encoding different from the current locale. Code that uses the tz database is multilingual (Unicode): knowing the encoding (zoneinfo name and the time) it is possible to decode almost all encoded characters (to find out whether the timezone abbreviation is valid with a given time and to find the correct UTC offset). If you don't know the encoding then the support for Unicode (the presence of the tz database (PEP 431)) along won't allow you to decode a byte sequence (time string). You need an encoding (timezone name, time) to interpret the input correctly. Given that the list is used to accept a string as a timezone abbreviation, I don't think it should depend on PEP 431 e.g., old date strings/people may use WST even if the new pytz timezones do not use it. The initial list could be seeded from using pytz as in my patch and then expanded as necessary by hand (there is no official entity that tracks timezone abbreviations). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 05:20:56 2014 From: report at bugs.python.org (Akira Li) Date: Sat, 20 Sep 2014 03:20:56 +0000 Subject: [issue22443] read(1) blocks on unflushed output In-Reply-To: <1411135688.43.0.0648130638254.issue22443@psf.upfronthosting.co.za> Message-ID: <1411183256.04.0.142414946564.issue22443@psf.upfronthosting.co.za> Akira Li added the comment: Related: http://stackoverflow.com/questions/25923901/last-unbuffered-line-cant-be-read Make sure you follow the links in the comments. ---------- nosy: +akira _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 06:06:58 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 20 Sep 2014 04:06:58 +0000 Subject: [issue15661] OS X installer packages should be signed for OS X 10.8 Gatekeeper feature In-Reply-To: <1345013707.82.0.343684011424.issue15661@psf.upfronthosting.co.za> Message-ID: <20140920040656.105633.16626@mail.hg.python.org> Roundup Robot added the comment: New changeset 569a889e3b6c by Ned Deily in branch '3.4': Issue #15661: Update OS X installer welcome and readme files for 3.4.2. https://hg.python.org/cpython/rev/569a889e3b6c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 06:25:41 2014 From: report at bugs.python.org (Case Van Horsen) Date: Sat, 20 Sep 2014 04:25:41 +0000 Subject: [issue22444] Floor divide should return int In-Reply-To: <1411145815.79.0.695099073811.issue22444@psf.upfronthosting.co.za> Message-ID: <1411187141.61.0.449475043441.issue22444@psf.upfronthosting.co.za> Changes by Case Van Horsen : ---------- nosy: +casevh _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 07:11:00 2014 From: report at bugs.python.org (Berker Peksag) Date: Sat, 20 Sep 2014 05:11:00 +0000 Subject: [issue12916] Add inspect.splitdoc In-Reply-To: <1315326747.38.0.43030903994.issue12916@psf.upfronthosting.co.za> Message-ID: <1411189860.19.0.1412629943.issue12916@psf.upfronthosting.co.za> Berker Peksag added the comment: I left a couple of comments on Rietveld. ---------- stage: commit review -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 07:12:05 2014 From: report at bugs.python.org (Berker Peksag) Date: Sat, 20 Sep 2014 05:12:05 +0000 Subject: [issue22406] uu-codec trailing garbage workaround is Python 2 code In-Reply-To: <1410702414.35.0.316849103636.issue22406@psf.upfronthosting.co.za> Message-ID: <1411189925.01.0.103196100245.issue22406@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 07:53:43 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 20 Sep 2014 05:53:43 +0000 Subject: [issue22247] More incomplete module.__all__ lists In-Reply-To: <1408675368.08.0.766854982306.issue22247@psf.upfronthosting.co.za> Message-ID: <20140920055340.54244.70313@mail.hg.python.org> Roundup Robot added the comment: New changeset eb9eac80c17a by Berker Peksag in branch '3.4': Issue #22247: Add NNTPError to nntplib.__all__. https://hg.python.org/cpython/rev/eb9eac80c17a New changeset e21b0bbc06ea by Berker Peksag in branch 'default': Issue #22247: Add NNTPError to nntplib.__all__. https://hg.python.org/cpython/rev/e21b0bbc06ea ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 08:27:32 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 20 Sep 2014 06:27:32 +0000 Subject: [issue22444] Floor divide should return int In-Reply-To: <1411145815.79.0.695099073811.issue22444@psf.upfronthosting.co.za> Message-ID: <1411194452.91.0.0149525317066.issue22444@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I think you're misreading the PEP. Floor division is defined to return a value *equal* to floor(x/y) but the type is unrestricted. That let's us correctly implement floor division for a variety of types including ints, floats, decimals, and fractions. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 08:56:37 2014 From: report at bugs.python.org (eryksun) Date: Sat, 20 Sep 2014 06:56:37 +0000 Subject: [issue22443] read(1) blocks on unflushed output In-Reply-To: <1411135688.43.0.0648130638254.issue22443@psf.upfronthosting.co.za> Message-ID: <1411196197.53.0.434323502223.issue22443@psf.upfronthosting.co.za> eryksun added the comment: unbuffer works for me. It fakes a tty, so apt-get doesn't automatically enter quiet mode. import io import subprocess args = ['unbuffer', 'apt-get', 'download', 'firefox'] p = subprocess.Popen(args, stdout=subprocess.PIPE, stderr=subprocess.STDOUT) out = io.TextIOWrapper(p.stdout, newline='') while True: c = out.read(1) if c == '': break print(c, end='', flush=True) p.wait() unbuffer isn't required if you disable quiet mode as follows: args = ['apt-get', '-q=0', 'download', 'firefox'] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 10:17:12 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 20 Sep 2014 08:17:12 +0000 Subject: [issue22444] Floor divide should return int In-Reply-To: <1411145815.79.0.695099073811.issue22444@psf.upfronthosting.co.za> Message-ID: <1411201032.74.0.31449659524.issue22444@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- Removed message: http://bugs.python.org/msg227146 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 10:51:06 2014 From: report at bugs.python.org (juj) Date: Sat, 20 Sep 2014 08:51:06 +0000 Subject: [issue22442] subprocess.check_call hangs on large PIPEd data. In-Reply-To: <1411134999.3.0.739689982343.issue22442@psf.upfronthosting.co.za> Message-ID: <1411203066.38.0.0836982332771.issue22442@psf.upfronthosting.co.za> juj added the comment: Very good question akira. In one codebase where I have fixed this kind of bug, see https://github.com/kripken/emscripten/commit/1b2badd84bc6f54a3125a494fa38a51f9dbb5877 https://github.com/kripken/emscripten/commit/2f048a4e452f5bacdb8fa31481c55487fd64d92a the intended usage by the original author had certainly been to throw in a PIPE just to mute both stdout and stderr output, and there was no intent to capture the results or anything. I think passing PIPE to those is meaningless, since they effectively behave as "throw the results away", since they are not returned. Throwing an exception might be nice, but perhaps that would break existing codebases and therefore is not good to add(?). Therefore I think the best course of action would be to do what is behaviorally as developer intends: "please treat as if stdout and stderr had been captured to a pipe, and throw those pipes away, since they aren't returned.", so your third option, while inconsistent with direct Popen(), sounds most correct in practice. What do you think? I am not currently aware of other such cases, although it would be useful to go through the docs and recheck the commit history of when that documentation note was added in to see if there was more related discussions that occurred. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 11:30:23 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 20 Sep 2014 09:30:23 +0000 Subject: [issue22444] Floor divide should return int In-Reply-To: <1411145815.79.0.695099073811.issue22444@psf.upfronthosting.co.za> Message-ID: <1411205423.47.0.791244657912.issue22444@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Is this change compelling enough to break compatibility, or is it just a matter of purity? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 12:35:39 2014 From: report at bugs.python.org (Christian Heimes) Date: Sat, 20 Sep 2014 10:35:39 +0000 Subject: [issue22449] SSLContext.load_verify_locations behavior on Windows and OSX Message-ID: <1411209339.34.0.91149685596.issue22449@psf.upfronthosting.co.za> New submission from Christian Heimes: The behavior of SSLContext.load_verify_locations is rather inconsistent across platforms: On most POSIX platforms (Linux, BSD, non-Apple builds of OpenSSL) it loads certificates from predefined locations. The locations are defined during compile time and usually differ between vendors and platforms. My WiP "Improve TLS/SSL support" PEP lists all common locations and the packages that offer the certs. On these platforms SSL_CERT_DIR and SSL_CERT_FILE overwrite the location. On Windows SSL_CERT_DIR and SSL_CERT_FILE are never taken into account by SSLContext.load_verify_locations because it doesn't call SSLContext.set_default_verify_paths(). The attached patch is a semi-fix for the problem. With the patch certs from SSL_CERT_DIR and SSL_CERT_FILE are only *added* to trusted root CA certs. The certs from Windows' cert store 'CA' and 'ROOT' are still loaded. On OSX with Apple's custom build of OpenSSL SSL_CERT_DIR and SSL_CERT_FILE take effect. But there is a twist! In case a root CA cert is not found Apple's Trust Evaluation Agent (TEA) kicks in and looks up certs from Apple's keychain. It's almost the same situation as on Windows but more magical. In order to disable TEA one has to set the env var OPENSSL_X509_TEA_DISABLE=1 *before* the first cert is validated. After that the env var has no effect as the value is cached. Hynek has documted it in his blog: https://hynek.me/articles/apple-openssl-verification-surprises/ ---------- components: Extension Modules, Library (Lib) files: win32_load_SSL_CERT_env.patch keywords: patch messages: 227150 nosy: alex, christian.heimes, dstufft, giampaolo.rodola, hynek, janssen, ncoghlan, pitrou priority: normal severity: normal stage: needs patch status: open title: SSLContext.load_verify_locations behavior on Windows and OSX type: behavior versions: Python 2.7, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file36668/win32_load_SSL_CERT_env.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 12:49:51 2014 From: report at bugs.python.org (Stefan Krah) Date: Sat, 20 Sep 2014 10:49:51 +0000 Subject: [issue22444] Floor divide should return int In-Reply-To: <1411205423.47.0.791244657912.issue22444@psf.upfronthosting.co.za> Message-ID: <20140920104949.GA29642@sleipnir.bytereef.org> Stefan Krah added the comment: Perhaps it's worth mentioning that several people on Python-ideas took the opposite view: math.floor() should return a float. PEP-3141 does not mention Infinities and NaNs: "The Real ABC indicates that the value is on the real line, and supports the operations of the float builtin. Real numbers are totally ordered except for NaNs (which this PEP basically ignores)." Floats, however, are on the extended real number line, so we have a problem. :) Other languages =============== The PEP says that inspiration came from Scheme and Haskell. However, Scheme returns floats: ------------------------------- https://mail.python.org/pipermail/python-ideas/2014-September/029432.html Haskell seems to return the highest representable integer: ---------------------------------------------------------- Prelude> floor (1/0) 179769313486231590772930519078902473361797697894230657273430081157732675805500963132708477322407536021120113879871393357658789768814416622492847430639474124377767893424865485276302219601246094119453082952085005768838150682342462881473913110540827237163350510684586298239947245938479716304835356329624224137216 However, Haskell float support looks sketchy: --------------------------------------------- Prelude> floor (0/0) -269653970229347386159395778618353710042696546841345985910145121736599013708251444699062715983611304031680170819807090036488184653221624933739271145959211186566651840137298227914453329401869141179179624428127508653257226023513694322210869665811240855745025766026879447359920868907719574457253034494436336205824 Prelude> let x = 1 / 0 Prelude> x Infinity Prelude> x / 0 Infinity Considering the last two examples, I think Haskell should not provide any guidance here. ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 12:54:26 2014 From: report at bugs.python.org (Stefan Krah) Date: Sat, 20 Sep 2014 10:54:26 +0000 Subject: [issue22444] Floor divide should return int In-Reply-To: <20140920104949.GA29642@sleipnir.bytereef.org> Message-ID: <20140920105425.GB29642@sleipnir.bytereef.org> Stefan Krah added the comment: Argh, forget the second Haskell example: inf / 0 is fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 13:23:57 2014 From: report at bugs.python.org (Stefan Krah) Date: Sat, 20 Sep 2014 11:23:57 +0000 Subject: [issue22445] Memoryviews require more strict contiguous checks then necessary In-Reply-To: <1411153250.02.0.529032306838.issue22445@psf.upfronthosting.co.za> Message-ID: <1411212237.53.0.573609680488.issue22445@psf.upfronthosting.co.za> Stefan Krah added the comment: Ok, so it is a debug thing in the current NumPy sources. IMO ultimately the getbufferproc needs to return valid strides, even if the first value isn't used. For that matter, the getbufferproc is free to translate the multi- dimensional corner case array to a one-dimensional array that is automatically C and F-contiguous. Does it matter if you lose some (irrelevant?) information about the original array structure? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 13:42:03 2014 From: report at bugs.python.org (Ned Deily) Date: Sat, 20 Sep 2014 11:42:03 +0000 Subject: [issue15661] OS X installer packages should be signed for OS X 10.8 Gatekeeper feature In-Reply-To: <1345013707.82.0.343684011424.issue15661@psf.upfronthosting.co.za> Message-ID: <1411213323.91.0.655564795866.issue15661@psf.upfronthosting.co.za> Ned Deily added the comment: After a fair amount of research, trial-and-error, and testing on all of the OS X platforms we support, I think we're now ready to switch to signed flat packages for the OS X installers and thereby greatly improve the user installation experience on current systems. I've found that it *is* possible to produce signed installers that work as expected on the same set of o/s releases and platforms as the current legacy installers (i386/ppc for 10.5+ and x86_64/i386 for 10.6+), with the same set of user installation options, although there were a number of gotchas along the way. One unexpected issue was that our Python frameworks are not immutable - since they include install paths such as the site-packages and scripts directories - and the current Apple packaging tools aren't designed to support a configuration like that. On newer releases where codesigning is fully supported, the installer wants to treat framework bundles as atomic elements which, I discovered, can result in the user's site-installed packages being deleted during an maintenance release upgrade. I was able to work around that in a way that works across all supported releases but it does point out that we should consider modifying our framework deployments to move to "read-only" bundles if possible. We produce the two installer variants by running build-installer.py on two different OS X systems (10.5 and 10.6) and then move the resultant bundle installers encapsulated in OS X disk image files (.dmg) to a third current (10.9) system for pgp signing, archiving, and uploading. The new process, beginning with the upcoming 3.4.2, remains the same except that the build artifacts from the two builds are now post-processed on the 10.9 system using the current Apple packaging tools to produce the flat package installer files and to do the "Gatekeeper" signings. For 3.4.2rc1, the configuration files for the packaging tools have been manually generated. The next step, probably post-3.4.2, will be for build-installer.py to auto-generate the config files. Another advantage of flat-format installers is that they are a compressed single file and don't need to be wrapped in another container like the legacy bundle installers do. So, starting with 3.4.2, the installer file (.pkg) will be downloaded directly rather than within a .dmg file. This simplifies the user installation process: double-clicking on the downloaded .pkg file will start the installer directly rather than having to click on the downloaded dmg, waiting for it to mount, double-clicking on the installer file in the window that opens, and remembering to dismount the volume when the install is complete. And, in some browser configurations, the installer will be launched automatically, although in all cases, user action is still required to complete the install. One possible downside to eliminating the dmg (or similar) container is that there will no longer be a redundant readme file outside of the installer. The installer presents the package's welcome, readme, and license files and the opportunity for the user to save and/or print each, but previously we also made a copy of the readme file available in the dmg directory next to the installer file. The primary case where that could be useful is if the user cannot launch the installer for some reason and the readme provides a workaround. But that unusual case is the one we are fixing by moving to signed packages. Not surprisingly, many users do not read readmes anyway: the previous readme files did include instructions on how to workaround the Gatekeeper issue yet many users still had problems. In the unlikely event that a similar problem arises, we still have the option to revert to a zip or a dmg if just providing info on the python.org download pages proves insufficient. To address the points in the original issue: (1) I think the risk has been minimized as there are no changes to the actual installer builds and the user experience in the installer is virtually unchanged; what we have changed is removing obstacles to getting to the installer. (2) While I still think in the long run it would be best to have a PSF-owned Apple developer company account for signing (and I still intend to pursue that with the board at some point after coming up with a concrete proposal), I don't think it is a particularly pressing issue. Initially, the installers are being signed with my personal developer id, just as other release files are signed by the personal pgp keys of the release team members who produce them. Unlike the Windows installer, the OS X installer does not display information about the signing key unsolicited other than an indication that one is present if you know where to look. There's a small icon indicating a signed installer in the upper-right corner of the installer window; clicking it causes the certificate info to be displayed. (3) is no longer an issue. As noted, we have already dropped installer support for OS X 10.3 and 10.4 in 3.x releases. Because of the extended life of the 2.7 series, with 2.7.7, we started the deprecation of those old systems by adding a 10.5+ format installer similar to 3.x releases while continuing to provide a 10.3+ format. With the next 2.x release (2.7.9) we plan to drop the 10.3+ installer altogether. So, going forward, all release installers will be flat and signed. Note that the daily dmg buildbot is still producing (old-format) test installers on a 10.4 system, which should help to ensure we don't needlessly break things on older systems. ---------- type: enhancement -> behavior versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 13:43:45 2014 From: report at bugs.python.org (Sebastian Berg) Date: Sat, 20 Sep 2014 11:43:45 +0000 Subject: [issue22445] Memoryviews require more strict contiguous checks then necessary In-Reply-To: <1411212237.53.0.573609680488.issue22445@psf.upfronthosting.co.za> Message-ID: <1411213422.22337.14.camel@sebastian-t440> Sebastian Berg added the comment: An extra dimension is certainly not irrelevant! The strides *are* valid and numpy currently actually commonly creates such arrays when slicing. The question is whether or not we want to ignore them for contiguity checks even if they have no effect on the memory layout. So there are three options I currently see: 1. Python also generalizes like I would like numpy to end up in the future (the current patch should do that) and just don't care about such strides, because the actual memory layout is what matters. 2. We say it is either too dangerous (which may very well be) or you want to preserve Fortran/C-order information even when it does not matter to the memory layout. This leads to this maybe: 2a) we just keep it as it is and live with minor inconsistencies (or never do the relaxed strides in numpy) 2b) We let these buffers return False on checking for contiguity but *allow* allow fetching a buffer when C-/F-contiguous is explicitly asked for when getting the buffer. Which is a weird middle way, but it might actually be a pretty sane solution (have to think about it). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 18:01:29 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 20 Sep 2014 16:01:29 +0000 Subject: [issue22444] Floor divide should return int In-Reply-To: <1411145815.79.0.695099073811.issue22444@psf.upfronthosting.co.za> Message-ID: <1411228889.28.0.752055468204.issue22444@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > Is this change compelling enough to break compatibility, > or is it just a matter of purity? According to the PEP 3141, Integer is a subtype of Real, so one should be able to substitute an Integer whenever Real is expected. The reverse is not true, for example >>> [1,2][1.0] Traceback (most recent call last): File "", line 1, in TypeError: list indices must be integers, not float This is one of the common uses of floor division - to find an index of a cell in a regular grid: (x - start) // step. In this situation, it is convenient to have the result ready to be used as an index without a cast. The substitution principle also suggests that compatibility issues are likely to be small: in most contexts integers behave the same as floats or "better". Here is an example of a "better" behavior: >>> x = 1 + 10**50 >>> x * 1 == x True >>> x * 1.0 == x False The only case I can think of where float result may be preferable is inf // 1 because integers cannot represent infinity. However, this case is arguably already broken. What are the use-cases for float // float where integer result is not acceptable? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 18:02:42 2014 From: report at bugs.python.org (Joshua Moore-Oliva) Date: Sat, 20 Sep 2014 16:02:42 +0000 Subject: [issue22448] call_at/call_later with Timer cancellation can result in (practically) unbounded memory usage. In-Reply-To: <1411172040.41.0.974691283228.issue22448@psf.upfronthosting.co.za> Message-ID: <1411228962.0.0.62806004254.issue22448@psf.upfronthosting.co.za> Joshua Moore-Oliva added the comment: > You can contribute upstream to the Tulip project first. Will I be writing a patch and tests for tulip, and then separate a patch and tests for python 3.4? Or will I submit to tulip, and then the changes will get merged from tulip into python by some other process? If possible, I would like to get this into python 3.4.2 (assuming all goes well). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 18:06:29 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 20 Sep 2014 16:06:29 +0000 Subject: [issue22444] Floor divide should return int In-Reply-To: <1411145815.79.0.695099073811.issue22444@psf.upfronthosting.co.za> Message-ID: <1411229189.33.0.0497651075083.issue22444@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > However, Scheme returns floats Does Scheme's default integer type support arbitrarily large values? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 18:23:13 2014 From: report at bugs.python.org (Case Van Horsen) Date: Sat, 20 Sep 2014 16:23:13 +0000 Subject: [issue22444] Floor divide should return int In-Reply-To: <1411229189.33.0.0497651075083.issue22444@psf.upfronthosting.co.za> Message-ID: Case Van Horsen added the comment: > > Does Scheme's default integer type support arbitrarily large values? > Yes, at least is does on the version I tested. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 18:32:38 2014 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 20 Sep 2014 16:32:38 +0000 Subject: [issue22448] call_at/call_later with Timer cancellation can result in (practically) unbounded memory usage. In-Reply-To: <1411228962.0.0.62806004254.issue22448@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: We can merge the changes into 3.4 and 3.5 for you, it's just a simple copy (the codebases are identical). However, the 3.4.2 release candidate is apparently in 2 days, so I think you've missed that train already. On Sat, Sep 20, 2014 at 9:02 AM, Joshua Moore-Oliva wrote: > > Joshua Moore-Oliva added the comment: > > > You can contribute upstream to the Tulip project first. > > Will I be writing a patch and tests for tulip, and then separate a patch > and tests for python 3.4? Or will I submit to tulip, and then the changes > will get merged from tulip into python by some other process? > > If possible, I would like to get this into python 3.4.2 (assuming all goes > well). > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 18:38:08 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 20 Sep 2014 16:38:08 +0000 Subject: [issue22444] Floor divide should return int In-Reply-To: <1411145815.79.0.695099073811.issue22444@psf.upfronthosting.co.za> Message-ID: <1411231088.07.0.732795088443.issue22444@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > Perhaps it's worth mentioning that several people on Python-ideas > took the opposite view: math.floor() should return a float. I sympathize with the idea that math module functions should return floats. I find it unfortunate that math.floor delegates to the __floor__ dunder on non-floats instead of doing math.floor(x.__float__()). It would be more natural to have a floor builtin that *always* delegates to __floor__ and keep math a pure float library. Note that math module provides the means to compute C-style floor: >>> x = float('inf') >>> math.modf(x)[1] inf >>> x = -3.4 >>> math.modf(x)[1] -3.0 Maybe we should add floorf, ceilf, etc. as well. This, however, is a different issue from the one at hand here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 18:39:28 2014 From: report at bugs.python.org (Case Van Horsen) Date: Sat, 20 Sep 2014 16:39:28 +0000 Subject: [issue22444] Floor divide should return int In-Reply-To: <1411228889.28.0.752055468204.issue22444@psf.upfronthosting.co.za> Message-ID: Case Van Horsen added the comment: > What are the use-cases for float // float where integer result is not acceptable? It can lead to unexpected memory consumption when dealing with arbitrary precision values. What should Decimal('1e123456')//1 return? The result is exactly equal to Decimal('1e123456') but the corresponding Python integer will consume ~55KB of RAM. I'm also concerned that returning a very large integer will lead users to assume that the result is more precise than it really is. Assuming standard 64-bit double format, only the first 53 bits are significant. All the remaining bits are 0. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 18:44:52 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 20 Sep 2014 16:44:52 +0000 Subject: [issue22444] Floor divide should return int In-Reply-To: <1411145815.79.0.695099073811.issue22444@psf.upfronthosting.co.za> Message-ID: <1411231492.71.0.0479328543707.issue22444@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > What should Decimal('1e123456')//1 return? I think Decimal case should be considered separately. Note that unlike float, they are not part of the numerical tower, so PEP 3141 arguments don't apply: >>> isinstance(1.0, numbers.Real) True >>> isinstance(decimal.Decimal(1), numbers.Real) False ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 19:05:05 2014 From: report at bugs.python.org (Case Van Horsen) Date: Sat, 20 Sep 2014 17:05:05 +0000 Subject: [issue22444] Floor divide should return int In-Reply-To: <1411231088.07.0.732795088443.issue22444@psf.upfronthosting.co.za> Message-ID: Case Van Horsen added the comment: On Sat, Sep 20, 2014 at 9:38 AM, Alexander Belopolsky wrote: > > Alexander Belopolsky added the comment: > >> Perhaps it's worth mentioning that several people on Python-ideas >> took the opposite view: math.floor() should return a float. > > I sympathize with the idea that math module functions should return floats. I find it unfortunate that math.floor delegates to the __floor__ dunder on non-floats instead of doing math.floor(x.__float__()). It would be more natural to have a floor builtin that *always* delegates to __floor__ and keep math a pure float library. +1 > > Note that math module provides the means to compute C-style floor: > >>>> x = float('inf') >>>> math.modf(x)[1] > inf >>>> x = -3.4 >>>> math.modf(x)[1] > -3.0 That's not immediately obvious... > > Maybe we should add floorf, ceilf, etc. as well. This, however, is a different issue from the one at hand here. > i think the issues are related. PEP-3141 defines x//y as int(floor(x/y)). It also defines divmod(x, y) as (x//y, x % y). These definitions cannot all be satisfied at the same Python's divmod function takes extra effort to calculate x//y precisely. Those corrections are not possible via floor(). I maintain gmpy2 which wraps the GMP, MPFR, and MPC arbitrary precision libraries. I originally implemented x//y as floor(x/y). That choice lead to errors in divmod() that I've fixed in the development version. I still need to fix floor division: do I make it compatible with divmod() or floor()? My preference would be to define floor division and divmod in terms of each other and allow math.ceil()/floor()/trunc() to return floating point values. The current definitions are impossible to satisfy. I mentioned my concerns about memory growth in another comment. I'm not as concerned about the unexpected memory growth in floor division as I am in floor() etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 19:13:22 2014 From: report at bugs.python.org (Case Van Horsen) Date: Sat, 20 Sep 2014 17:13:22 +0000 Subject: [issue22444] Floor divide should return int In-Reply-To: <1411231492.71.0.0479328543707.issue22444@psf.upfronthosting.co.za> Message-ID: Case Van Horsen added the comment: >> What should Decimal('1e123456')//1 return? > > I think Decimal case should be considered separately. Note that unlike float, they are not part of the numerical tower, so PEP 3141 arguments don't apply: > >>>> isinstance(1.0, numbers.Real) > True >>>> isinstance(decimal.Decimal(1), numbers.Real) > False > I maintain gmpy2 and I've had requests to support the numeric tower. gmpy2 has integral, rational, real, and complex types so I should be able to. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 19:29:09 2014 From: report at bugs.python.org (Christian Heimes) Date: Sat, 20 Sep 2014 17:29:09 +0000 Subject: [issue22417] PEP 476: verify HTTPS certificates by default In-Reply-To: <1410784469.95.0.475937020841.issue22417@psf.upfronthosting.co.za> Message-ID: <1411234149.33.0.778107082287.issue22417@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 19:49:47 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 20 Sep 2014 17:49:47 +0000 Subject: [issue22444] Floor divide should return int In-Reply-To: <1411145815.79.0.695099073811.issue22444@psf.upfronthosting.co.za> Message-ID: <1411235387.69.0.548927066699.issue22444@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > What are the use-cases for float // float where integer result is not acceptable? I can't think of any. I was mostly making the case for conservatism here. The indexing use case is interesting, although I suppose enumerate() should eliminate most instances of it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 20:57:12 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 20 Sep 2014 18:57:12 +0000 Subject: [issue19776] Provide expanduser() on Path objects In-Reply-To: <1385409778.55.0.842571848249.issue19776@psf.upfronthosting.co.za> Message-ID: <1411239432.14.0.205664464284.issue19776@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Serhiy, would you like to update your patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 21:10:14 2014 From: report at bugs.python.org (Stefan Krah) Date: Sat, 20 Sep 2014 19:10:14 +0000 Subject: [issue22445] Memoryviews require more strict contiguous checks then necessary In-Reply-To: <1411213422.22337.14.camel@sebastian-t440> Message-ID: <20140920191012.GA32091@sleipnir.bytereef.org> Stefan Krah added the comment: I think it would help discussing your options if the patch passes test_buffer first. Currently it segfaults because shape can be NULL. Also, code in memoryobject.c relies on the fact that ndim==0 means contiguous. Then, it would help enormously if you give Python function definitions of the revised C and F-contiguity. I mean something like verify_structure() from Lib/test/test_buffer.py -- that function definition was largely supplied by Pauli Virtanen, but I may have added the check for strides-is-multiple-of-itemsize (which 2**63-1 usually isn't, so the new debug numpy strides don't pass that test). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 21:23:32 2014 From: report at bugs.python.org (Christian Heimes) Date: Sat, 20 Sep 2014 19:23:32 +0000 Subject: [issue22440] Setting SSLContext object's check_hostname manually might accidentally skip hostname verification In-Reply-To: <1411113190.48.0.396840225305.issue22440@psf.upfronthosting.co.za> Message-ID: <1411241012.64.0.66908447005.issue22440@psf.upfronthosting.co.za> Christian Heimes added the comment: Alex's analysis is correct. Starting with 3.4 the SSLSocket object can perform a hostname check during the handshake. More recent versions of OpenSSL or a custom verify callback could do the check even earlier during the handshake. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 21:29:47 2014 From: report at bugs.python.org (Alex Gaynor) Date: Sat, 20 Sep 2014 19:29:47 +0000 Subject: [issue22440] Setting SSLContext object's check_hostname manually might accidentally skip hostname verification In-Reply-To: <1411113190.48.0.396840225305.issue22440@psf.upfronthosting.co.za> Message-ID: <1411241387.31.0.953399668855.issue22440@psf.upfronthosting.co.za> Alex Gaynor added the comment: This can be closed then I think? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 21:33:24 2014 From: report at bugs.python.org (Christian Heimes) Date: Sat, 20 Sep 2014 19:33:24 +0000 Subject: [issue22440] Setting SSLContext object's check_hostname manually might accidentally skip hostname verification In-Reply-To: <1411113190.48.0.396840225305.issue22440@psf.upfronthosting.co.za> Message-ID: <1411241604.37.0.745654792055.issue22440@psf.upfronthosting.co.za> Christian Heimes added the comment: Yeah. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 22:14:38 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 20 Sep 2014 20:14:38 +0000 Subject: [issue22444] Floor divide should return int In-Reply-To: <1411145815.79.0.695099073811.issue22444@psf.upfronthosting.co.za> Message-ID: <1411244078.35.0.118536249973.issue22444@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > Is this change compelling enough to break compatibility, > or is it just a matter of purity? I agree with Antoine that making this change is a really bad idea. 1) The current behavior has been around for a long time and is implemented in several modules including decimal and fractions. As core devs, we need to keep focused on a priority of making the language stable (not making changes that truly necessary and invalidating all previously published material) and more importantly not adding yet more obstacles to converting from Python 2 to Python 3 (which Guido has called "death by a thousand cuts"). 2) The current behavior can be useful it that it allows floor division operations without unexpected type conversions occurring in the middle of an expression. We really don't want to break those use cases. # Here is a simple example of a chain of calculations # where preserving the type matters from __future__ import print_function from fractions import Fraction from decimal import Decimal def f(x, y): return x // 3 * 5 / 7 + y def g(x, y): return int(x // 3) * 5 / 7 + y for x, y in [ (Fraction(85, 7), Fraction(2, 3)), (Decimal('12.143'), Decimal('0.667')), (12.143, 0.667), ]: print(f(x, y), g(x, y)) In Python 2: ------------ 8/3 8/3 3.524142857142857142857142857 2.667 3.52414285714 2.667 In Python 3: ------------ 3.5238095238095237 3.5238095238095237 Traceback (most recent call last): ... return int(x // 3) * 5 / 7 + y TypeError: unsupported operand type(s) for +: 'float' and 'decimal.Decimal' I am a strong -1 against breaking code that relies on the floor division being type preserving. The PEP should be revised to say that floor division is defined to return a value that is *equal* to an Integral but not place any restriction on the return type. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 22:15:04 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 20 Sep 2014 20:15:04 +0000 Subject: [issue22444] Floor divide should return int In-Reply-To: <1411145815.79.0.695099073811.issue22444@psf.upfronthosting.co.za> Message-ID: <1411244104.88.0.522996934168.issue22444@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 22:31:46 2014 From: report at bugs.python.org (Marco Paolini) Date: Sat, 20 Sep 2014 20:31:46 +0000 Subject: [issue21163] asyncio doesn't warn if a task is destroyed during its execution In-Reply-To: <1396732231.93.0.182409018223.issue21163@psf.upfronthosting.co.za> Message-ID: <1411245106.39.0.369221804548.issue21163@psf.upfronthosting.co.za> Marco Paolini added the comment: Sorry for keeping this alive. Take a look at the `wait_for.py` just submitted in the unrelated #22448: no strong refs to the tasks are kept. Tasks remain alive only because they are timers and the event loop keeps strong ref. Do you think my proposed patch is OK? Sould I open a new issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 22:32:25 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 20 Sep 2014 20:32:25 +0000 Subject: [issue19776] Provide expanduser() on Path objects In-Reply-To: <1385409778.55.0.842571848249.issue19776@psf.upfronthosting.co.za> Message-ID: <1411245144.99.0.687808541569.issue19776@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Sorry. Here is updated patch. ---------- Added file: http://bugs.python.org/file36669/pathlib_expanduser_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 23:00:36 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 20 Sep 2014 21:00:36 +0000 Subject: [issue21091] EmailMessage.is_attachment should be a method In-Reply-To: <1396056379.22.0.363709068017.issue21091@psf.upfronthosting.co.za> Message-ID: <1411246836.97.0.437475228887.issue21091@psf.upfronthosting.co.za> R. David Murray added the comment: Here is a patch. Sorry for leaving it until the last minute...maybe someone can review it, but it is simple enough I'll commit it soon regardless. ---------- Added file: http://bugs.python.org/file36670/is_attachment_as_method.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 23:14:38 2014 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 20 Sep 2014 21:14:38 +0000 Subject: [issue21163] asyncio doesn't warn if a task is destroyed during its execution In-Reply-To: <1396732231.93.0.182409018223.issue21163@psf.upfronthosting.co.za> Message-ID: <1411247678.26.0.838686369.issue21163@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'm not sure how that wait_for.py example from issue2116 relates to this issue -- it seems to demonstrate the opposite problem (tasks are kept alive even though they are cancelled). Then again I admit I haven't looked deeply into the example (though I am sympathetic with the issue it purports to demonstrate). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 23:15:28 2014 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 20 Sep 2014 21:15:28 +0000 Subject: [issue21163] asyncio doesn't warn if a task is destroyed during its execution In-Reply-To: <1396732231.93.0.182409018223.issue21163@psf.upfronthosting.co.za> Message-ID: <1411247728.61.0.687859503762.issue21163@psf.upfronthosting.co.za> Guido van Rossum added the comment: (Whoops meant to link to issue22448.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 23:17:42 2014 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 20 Sep 2014 21:17:42 +0000 Subject: [issue22448] call_at/call_later with Timer cancellation can result in (practically) unbounded memory usage. In-Reply-To: <1411172040.41.0.974691283228.issue22448@psf.upfronthosting.co.za> Message-ID: <1411247862.83.0.793667840089.issue22448@psf.upfronthosting.co.za> Guido van Rossum added the comment: By the way I just looked at wait_for.py; it has a bug where do_work() isn't using yield-from with the sleep() call. But that may well be the issue you were trying to debug, and this does not change my opinion about the issue -- I am still looking forward to your patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 23:29:37 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 20 Sep 2014 21:29:37 +0000 Subject: [issue14293] Message methods delegated via __getattr__ inaccessible using super(). In-Reply-To: <1331676773.49.0.0306891177672.issue14293@psf.upfronthosting.co.za> Message-ID: <1411248577.2.0.874016457472.issue14293@psf.upfronthosting.co.za> R. David Murray added the comment: _Headerlist never made it into the committed code. Subclassing Message works fine in both the mainline email code and the provisional extensions. ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 23:34:25 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 20 Sep 2014 21:34:25 +0000 Subject: [issue22444] Floor divide should return int In-Reply-To: <1411145815.79.0.695099073811.issue22444@psf.upfronthosting.co.za> Message-ID: <1411248865.17.0.375890523523.issue22444@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +alex _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 23:35:55 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 20 Sep 2014 21:35:55 +0000 Subject: [issue21083] Add get_content_disposition() to email.message.Message In-Reply-To: <1396005202.84.0.754707033491.issue21083@psf.upfronthosting.co.za> Message-ID: <1411248955.58.0.743527131379.issue21083@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 23:48:45 2014 From: report at bugs.python.org (Tim Peters) Date: Sat, 20 Sep 2014 21:48:45 +0000 Subject: [issue22444] Floor divide should return int In-Reply-To: <1411145815.79.0.695099073811.issue22444@psf.upfronthosting.co.za> Message-ID: <1411249725.14.0.722075905042.issue22444@psf.upfronthosting.co.za> Tim Peters added the comment: Floor division on floats is an unattractive nuisance and should be removed, period - so there ;-) But short of that, I favor leaving it alone. Whose life would be improved by changing it to return an int? Not mine - and doing so anyway is bound to break existing code. +1 on changing the PEP instead (as Raymond suggested). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 23:49:08 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 20 Sep 2014 21:49:08 +0000 Subject: [issue21079] EmailMessage.is_attachment == False if filename is present In-Reply-To: <1395940330.14.0.456041860337.issue21079@psf.upfronthosting.co.za> Message-ID: <20140920214906.58653.39224@mail.hg.python.org> Roundup Robot added the comment: New changeset 0044ed0af96f by R David Murray in branch '3.4': #21079: is_attachment now looks only at the value, ignoring parameters. https://hg.python.org/cpython/rev/0044ed0af96f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 23:50:01 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 20 Sep 2014 21:50:01 +0000 Subject: [issue21079] EmailMessage.is_attachment == False if filename is present In-Reply-To: <1395940330.14.0.456041860337.issue21079@psf.upfronthosting.co.za> Message-ID: <20140920215000.83944.75142@mail.hg.python.org> Roundup Robot added the comment: New changeset 54392c4a8880 by R David Murray in branch 'default': Merge: #21079: is_attachment now looks only at the value, ignoring parameters. https://hg.python.org/cpython/rev/54392c4a8880 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 23:50:29 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 20 Sep 2014 21:50:29 +0000 Subject: [issue21079] EmailMessage.is_attachment == False if filename is present In-Reply-To: <1395940330.14.0.456041860337.issue21079@psf.upfronthosting.co.za> Message-ID: <1411249829.0.0.586462233682.issue21079@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 20 23:51:39 2014 From: report at bugs.python.org (Ned Deily) Date: Sat, 20 Sep 2014 21:51:39 +0000 Subject: [issue22449] SSLContext.load_verify_locations behavior on Windows and OSX In-Reply-To: <1411209339.34.0.91149685596.issue22449@psf.upfronthosting.co.za> Message-ID: <1411249899.11.0.0758300328229.issue22449@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 00:16:16 2014 From: report at bugs.python.org (Alex Gaynor) Date: Sat, 20 Sep 2014 22:16:16 +0000 Subject: [issue22444] Floor divide should return int In-Reply-To: <1411145815.79.0.695099073811.issue22444@psf.upfronthosting.co.za> Message-ID: <1411251376.07.0.718436692722.issue22444@psf.upfronthosting.co.za> Alex Gaynor added the comment: I can't say that I've ever used // on floats, but it seems to me anyone doing so (as opposed to normal division + explicit rounding) *intentionally* might be broken by this change, but anyone doing this incidentally is not really in a "gotcha" situation. Since this is a type-specific behavior, and not a value-specific one, I don't really think there's a win in changing the behavior, and staying backwards compatible is much better. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 00:17:26 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 20 Sep 2014 22:17:26 +0000 Subject: [issue21091] EmailMessage.is_attachment should be a method In-Reply-To: <1396056379.22.0.363709068017.issue21091@psf.upfronthosting.co.za> Message-ID: <20140920221714.54244.3520@mail.hg.python.org> Roundup Robot added the comment: New changeset a3df1c24d586 by R David Murray in branch '3.4': #21091: make is_attachment a method. https://hg.python.org/cpython/rev/a3df1c24d586 New changeset f7aff40609e7 by R David Murray in branch 'default': Merge: #21091: make is_attachment a method. https://hg.python.org/cpython/rev/f7aff40609e7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 00:18:04 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 20 Sep 2014 22:18:04 +0000 Subject: [issue21091] EmailMessage.is_attachment should be a method In-Reply-To: <1396056379.22.0.363709068017.issue21091@psf.upfronthosting.co.za> Message-ID: <1411251484.35.0.629388674584.issue21091@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed type: -> behavior versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 00:18:41 2014 From: report at bugs.python.org (Joshua Moore-Oliva) Date: Sat, 20 Sep 2014 22:18:41 +0000 Subject: [issue22448] call_at/call_later with Timer cancellation can result in (practically) unbounded memory usage. In-Reply-To: <1411172040.41.0.974691283228.issue22448@psf.upfronthosting.co.za> Message-ID: <1411251521.21.0.667425925535.issue22448@psf.upfronthosting.co.za> Joshua Moore-Oliva added the comment: My patch is ready for review, if I followed the process correctly I think you should have received an email https://codereview.appspot.com/145220043 > By the way I just looked at wait_for.py; it has a bug where do_work() isn't using yield-from with the sleep() call. But that may well be the issue you were trying to debug, and this does not change my opinion about the issue That was not intended, it was just a mistake. (A quick aside on yield from, feel free to ignore, I don't expect to change anyone's opinion on this) I don't use "yield from" much - my first use of asyncio was porting an application from gevent (I made a small custom wrapper with fibers (https://pypi.python.org/pypi/fibers) that can internally yield on coroutines). I have read https://glyph.twistedmatrix.com/2014/02/unyielding.html but in my cases, I tend to write my code with the thought that any non standard library function can yield (I initially tried porting to vanilla asyncio, but I ended up having yield from almost everywhere). In the rare cases I want to ensure no yielding takes place across function calls, I like the way gruvi (https://github.com/geertj/gruvi) handles it with a construct to assert no yielding takes place. with assert_no_switchpoints(): do_something() do_something_else() I also find that it is less error prone (missing a yield from), but that is a minor point as I could write a static analyzer (on top of test cases ofc) to check for that. But that's just my opinion and opinion's evolve :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 00:24:16 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 20 Sep 2014 22:24:16 +0000 Subject: [issue22359] Remove incorrect uses of recursive make In-Reply-To: <1410165869.76.0.203082844365.issue22359@psf.upfronthosting.co.za> Message-ID: <20140920222413.17735.24357@mail.hg.python.org> Roundup Robot added the comment: New changeset c2a53aa27cad by Antoine Pitrou in branch 'default': Issue #22359: Remove incorrect uses of recursive make. Patch by Jonas Wagner. https://hg.python.org/cpython/rev/c2a53aa27cad ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 00:24:41 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 20 Sep 2014 22:24:41 +0000 Subject: [issue22359] Remove incorrect uses of recursive make In-Reply-To: <1410165869.76.0.203082844365.issue22359@psf.upfronthosting.co.za> Message-ID: <1411251881.84.0.3927316932.issue22359@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, I've pushed the patch. Let's see if anyone complains. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 00:26:09 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 20 Sep 2014 22:26:09 +0000 Subject: [issue5309] distutils doesn't parallelize extension module compilation In-Reply-To: <1235007592.93.0.0598331575131.issue5309@psf.upfronthosting.co.za> Message-ID: <1411251969.52.0.400044490348.issue5309@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Updated patch raising DistutilsOptionError. I couldn't find any docs so I didn't update them :-) ---------- Added file: http://bugs.python.org/file36671/build_ext_parallel6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 00:26:50 2014 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 20 Sep 2014 22:26:50 +0000 Subject: [issue22448] call_at/call_later with Timer cancellation can result in (practically) unbounded memory usage. In-Reply-To: <1411251521.21.0.667425925535.issue22448@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: I will try to review later tonight. One thing though: > I tend to write my code with the thought that any non standard library function can yield That makes sense when using geven, but not when using asyncio or Trollius. Nothing will make events run if you don't use yield [from]. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 00:38:50 2014 From: report at bugs.python.org (Joshua Moore-Oliva) Date: Sat, 20 Sep 2014 22:38:50 +0000 Subject: [issue22448] call_at/call_later with Timer cancellation can result in (practically) unbounded memory usage. In-Reply-To: <1411172040.41.0.974691283228.issue22448@psf.upfronthosting.co.za> Message-ID: <1411252730.95.0.643207208614.issue22448@psf.upfronthosting.co.za> Joshua Moore-Oliva added the comment: > I will try to review later tonight. Thanks! > That makes sense when using gevent, but not when using asyncio or Trollius. Nothing will make events run if you don't use yield [from]. Yes, I am aware of that. I have written a small custom library using fibers (a greenlet-like library) on top of asyncio so that I don't need to use yield from in my application(s). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 00:46:53 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 20 Sep 2014 22:46:53 +0000 Subject: [issue21354] PyCFunction_New no longer exposed by python DLL breaking bdist_wininst installers In-Reply-To: <1398499255.25.0.881446688113.issue21354@psf.upfronthosting.co.za> Message-ID: <1411253213.39.0.441359065465.issue21354@psf.upfronthosting.co.za> Larry Hastings added the comment: This is still not fixed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 00:50:43 2014 From: report at bugs.python.org (Georg Brandl) Date: Sat, 20 Sep 2014 22:50:43 +0000 Subject: [issue21354] PyCFunction_New no longer exposed by python DLL breaking bdist_wininst installers In-Reply-To: <1398499255.25.0.881446688113.issue21354@psf.upfronthosting.co.za> Message-ID: <1411253443.28.0.413506285406.issue21354@psf.upfronthosting.co.za> Georg Brandl added the comment: Sorry for the "mismanagement", I probably didn't check again after the final resolution. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 00:58:18 2014 From: report at bugs.python.org (paul j3) Date: Sat, 20 Sep 2014 22:58:18 +0000 Subject: [issue22433] Argparse considers unknown optional arguments with spaces as a known positional argument In-Reply-To: <1410969476.15.0.703805216421.issue22433@psf.upfronthosting.co.za> Message-ID: <1411253898.52.0.113275383247.issue22433@psf.upfronthosting.co.za> paul j3 added the comment: Your patch fails: python3 -m unittest test_argparse.TestEmptyAndSpaceContainingArguments specifically these 2 subcases: (['-a badger'], NS(x='-a badger', y=None)), (['-y', '-a badger'], NS(x=None, y='-a badger')), -------------------- At issue is the ambiguity when the user gives you a string that looks like an optionals flag, but doesn't match one of the defined arguments. When should it be treated as a positional, and when should it be treated as an unknown? The code, and test says - if it has the space, treat it like a positional. You are trying to reverse that choice - if it has the prefix, treat it like an unknown optional. At the point where you apply the patch, we already know that the string has a prefixchar. So you are, effectively, eliminating the 'space' test. I've added a simpler example of where the presence of the space flips that choice. ---------- nosy: +paul.j3 Added file: http://bugs.python.org/file36672/example.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 01:00:16 2014 From: report at bugs.python.org (paul j3) Date: Sat, 20 Sep 2014 23:00:16 +0000 Subject: [issue22401] argparse: 'resolve' conflict handler damages the actions of the parent parser In-Reply-To: <1410673598.78.0.274465754789.issue22401@psf.upfronthosting.co.za> Message-ID: <1411254016.6.0.619419279194.issue22401@psf.upfronthosting.co.za> Changes by paul j3 : ---------- nosy: +bethard _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 01:33:33 2014 From: report at bugs.python.org (Joshua Moore-Oliva) Date: Sat, 20 Sep 2014 23:33:33 +0000 Subject: [issue21965] Add support for Memory BIO to _ssl In-Reply-To: <1405156134.57.0.513965198344.issue21965@psf.upfronthosting.co.za> Message-ID: <1411256013.57.0.11648537756.issue21965@psf.upfronthosting.co.za> Changes by Joshua Moore-Oliva : ---------- nosy: +chatgris _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 01:50:32 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 20 Sep 2014 23:50:32 +0000 Subject: [issue22450] urllib doesn't put Accept: */* in the headers Message-ID: <1411257032.38.0.526589346468.issue22450@psf.upfronthosting.co.za> New submission from Raymond Hettinger: The use of urllib for REST APIs is impaired in the absence of a "Accept: */*" header such as that added automatically by the requests package or by the CURL command-line tool. # Example that gets an incorrect result due to the missing header import urllib print urllib.urlopen('http://graph.facebook.com/raymondh').headers['Content-Type'] # Equivalent call using CURL $ curl -v http://graph.facebook.com/raymondh ... * Connected to graph.facebook.com (31.13.75.1) port 80 (#0) > GET /raymondh HTTP/1.1 > User-Agent: curl/7.30.0 > Host: graph.facebook.com > Accept: */* > ---------- files: accept.diff keywords: patch messages: 227194 nosy: rhettinger priority: normal severity: normal stage: patch review status: open title: urllib doesn't put Accept: */* in the headers type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file36673/accept.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 02:00:01 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 21 Sep 2014 00:00:01 +0000 Subject: [issue22450] urllib doesn't put Accept: */* in the headers In-Reply-To: <1411257032.38.0.526589346468.issue22450@psf.upfronthosting.co.za> Message-ID: <1411257601.98.0.933216051017.issue22450@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Patch looks good. Will need similar addition in urllib2 and inclusion of tests. ---------- nosy: +orsenthil versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 02:00:21 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 21 Sep 2014 00:00:21 +0000 Subject: [issue22450] urllib doesn't put Accept: */* in the headers In-Reply-To: <1411257032.38.0.526589346468.issue22450@psf.upfronthosting.co.za> Message-ID: <1411257621.62.0.393475107312.issue22450@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Can you explain how the result is incorrect? >>> f = urllib.request.urlopen('http://graph.facebook.com/raymondh') >>> json.loads(f.read().decode()) {'link': 'https://www.facebook.com/raymondh', 'id': '562805507', 'last_name': 'Hettinger', 'gender': 'male', 'first_name': 'Raymond', 'name': 'Raymond Hettinger', 'locale': 'en_US', 'username': 'raymondh'} ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 02:03:52 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 21 Sep 2014 00:03:52 +0000 Subject: [issue22450] urllib doesn't put Accept: */* in the headers In-Reply-To: <1411257032.38.0.526589346468.issue22450@psf.upfronthosting.co.za> Message-ID: <1411257832.91.0.738735289261.issue22450@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Well, the result with loading using json will be same. but without sending Accept */*. The content-type returned is text/javascript; charset=UTF-8 and with sending of Accept */* the content-type is set to application/json; charset=UTF-8 (which is more desirable). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 02:07:18 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 21 Sep 2014 00:07:18 +0000 Subject: [issue22450] urllib doesn't put Accept: */* in the headers In-Reply-To: <1411257032.38.0.526589346468.issue22450@psf.upfronthosting.co.za> Message-ID: <1411258038.11.0.395450671298.issue22450@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > The content-type returned is text/javascript; charset=UTF-8 and with > sending of Accept */* the content-type is set to application/json; > charset=UTF-8 (which is more desirable). Is that a bug in urllib, or in Facebook's HTTP implementation? Frankly, we shouldn't jump to conclusions just because one specific use case is made better by this. Forcing an accept header may totally change the output of other servers and break existing uses. (and besides, the content-type header is unimportant when you know what to expect, which is normally the case when calling an API) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 03:04:35 2014 From: report at bugs.python.org (Joshua Landau) Date: Sun, 21 Sep 2014 01:04:35 +0000 Subject: [issue22451] filtertuple, filterstring and filterunicode don't have optimization for PyBool_Type Message-ID: <1411261475.31.0.855934223682.issue22451@psf.upfronthosting.co.za> New submission from Joshua Landau: All code referred to is from bltinmodule.c, Python 2.7.8: https://github.com/python/cpython/blob/2.7/Python/bltinmodule.c filter implements and optimization for PyBool_Type, making it equivalent to PyNone: # Line 303 if (func == (PyObject *)&PyBool_Type || func == Py_None) The specializations for tuples, byte strings and unicode don't have this: # Lines 2776, 2827, 2956, 2976 if (func == Py_None) This is a damper against recommending `filter(bool, ...)`. --- Python 3 of course does not have these specializations, so has no bug. ---------- components: Library (Lib) messages: 227199 nosy: Joshua.Landau priority: normal severity: normal status: open title: filtertuple, filterstring and filterunicode don't have optimization for PyBool_Type type: performance versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 03:32:31 2014 From: report at bugs.python.org (paul j3) Date: Sun, 21 Sep 2014 01:32:31 +0000 Subject: [issue22433] Argparse considers unknown optional arguments with spaces as a known positional argument In-Reply-To: <1410969476.15.0.703805216421.issue22433@psf.upfronthosting.co.za> Message-ID: <1411263151.08.0.941037735379.issue22433@psf.upfronthosting.co.za> Changes by paul j3 : Removed file: http://bugs.python.org/file36672/example.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 03:32:46 2014 From: report at bugs.python.org (paul j3) Date: Sun, 21 Sep 2014 01:32:46 +0000 Subject: [issue22433] Argparse considers unknown optional arguments with spaces as a known positional argument In-Reply-To: <1410969476.15.0.703805216421.issue22433@psf.upfronthosting.co.za> Message-ID: <1411263166.78.0.219439896985.issue22433@psf.upfronthosting.co.za> Changes by paul j3 : Added file: http://bugs.python.org/file36674/example.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 03:55:26 2014 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 21 Sep 2014 01:55:26 +0000 Subject: [issue22448] call_at/call_later with Timer cancellation can result in (practically) unbounded memory usage. In-Reply-To: <1411252730.95.0.643207208614.issue22448@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: On Sat, Sep 20, 2014 at 3:38 PM, Joshua Moore-Oliva wrote: > > Joshua Moore-Oliva added the comment: > > > I will try to review later tonight. > > Thanks! > > > That makes sense when using gevent, but not when using asyncio or > Trollius. Nothing will make events run if you don't use yield [from]. > > Yes, I am aware of that. I have written a small custom library using > fibers (a greenlet-like library) on top of asyncio so that I don't need to > use yield from in my application(s). > Hm. That sounds like you won't actually be interoperable with other asyncio-using code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 05:19:21 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 21 Sep 2014 03:19:21 +0000 Subject: [issue22451] filtertuple, filterstring and filterunicode don't have optimization for PyBool_Type In-Reply-To: <1411261475.31.0.855934223682.issue22451@psf.upfronthosting.co.za> Message-ID: <1411269561.68.0.280221316041.issue22451@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Is there code that isn't working as documented or are you asking for additional optimizations to make the other cases run a bit faster when 'bool' is passed in as the filter function? ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 06:17:28 2014 From: report at bugs.python.org (Joshua Landau) Date: Sun, 21 Sep 2014 04:17:28 +0000 Subject: [issue22451] filtertuple, filterstring and filterunicode don't have optimization for PyBool_Type In-Reply-To: <1411261475.31.0.855934223682.issue22451@psf.upfronthosting.co.za> Message-ID: <1411273048.29.0.804797541789.issue22451@psf.upfronthosting.co.za> Joshua Landau added the comment: It's solely a speed thing. I think it was an oversight that the optimisation was only applied to lists. I didn't expect the optimisation to break when applied to tuples. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 06:55:50 2014 From: report at bugs.python.org (Alex Gaynor) Date: Sun, 21 Sep 2014 04:55:50 +0000 Subject: [issue22449] SSLContext.load_verify_locations behavior on Windows and OSX In-Reply-To: <1411209339.34.0.91149685596.issue22449@psf.upfronthosting.co.za> Message-ID: <1411275350.65.0.861132887883.issue22449@psf.upfronthosting.co.za> Alex Gaynor added the comment: Does this effect anything besides causing SSL_CERT_DIR and SSL_CERT_FILE to be respected? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 09:25:23 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 21 Sep 2014 07:25:23 +0000 Subject: [issue22451] filtertuple, filterstring and filterunicode don't have optimization for PyBool_Type In-Reply-To: <1411261475.31.0.855934223682.issue22451@psf.upfronthosting.co.za> Message-ID: <1411284323.63.0.852557374286.issue22451@psf.upfronthosting.co.za> Raymond Hettinger added the comment: It is a bit late in the game for 2.7 micro-optimizations. FWIW, I don't think these weren't oversights. There isn't really much of a use case for the bool filter for strings and unicode inputs. And the case of tuple inputs isn't used much ("lists are for looping/filtering and tuples are like records in a DB or structs in C"). Since there is no bug here and we're trying to touch 2.7 as little as possible these days, I recommend closing as "not a bug" or "won't fix". If optimizing uncommon cases is important for you, then just use "filter(None, iterable)" instead of "filter(bool, iterable)" or work with itertools.ifilter() and itertools.ifilterfalse(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 10:03:33 2014 From: report at bugs.python.org (Vinay Sajip) Date: Sun, 21 Sep 2014 08:03:33 +0000 Subject: [issue22447] logging.config.fileConfig attempts to write to file even when none configured In-Reply-To: <1411160781.56.0.728660343296.issue22447@psf.upfronthosting.co.za> Message-ID: <1411286613.91.0.750671362228.issue22447@psf.upfronthosting.co.za> Vinay Sajip added the comment: I don't propose to make any changes to `fileConfig()`, for the following reasons: 1. It's not a bug, because there is no requirement to do what you suggest. You could (a) either not mention the handler in the config if you aren't going to use it, (b) use a delay parameter so the file opening is deferred until it's first needed, or (c) specify a file location which is accessible to the running process. 2. While it is not deprecated, the fileConfig() API has been supplanted by the dictConfig() API and is not receiving any functional changes. For the specific case you mention, dictConfig() would behave similarly to fileConfig(), and this wouldn't be a bug either: please use an approach such as those suggested in my earlier point to overcome your problem. ---------- resolution: -> not a bug status: open -> closed type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 10:05:04 2014 From: report at bugs.python.org (Berker Peksag) Date: Sun, 21 Sep 2014 08:05:04 +0000 Subject: [issue19119] duplicate test name in Lib/test/test_heapq.py In-Reply-To: <1380401602.68.0.29924709136.issue19119@psf.upfronthosting.co.za> Message-ID: <1411286704.31.0.518299193978.issue19119@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: -> patch review versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 10:10:13 2014 From: report at bugs.python.org (Akira Li) Date: Sun, 21 Sep 2014 08:10:13 +0000 Subject: [issue22442] subprocess.check_call hangs on large PIPEd data. In-Reply-To: <1411134999.3.0.739689982343.issue22442@psf.upfronthosting.co.za> Message-ID: <1411287013.03.0.685213648714.issue22442@psf.upfronthosting.co.za> Akira Li added the comment: > What do you think? I would prefer to deprecate PIPE argument for subprocess.call(): issue DeprecationWarning in 3.5 and raise ValueError in 3.6+ I've uploaded a patch that issues the warning. ---------- keywords: +patch type: -> enhancement versions: +Python 3.5 -Python 2.7 Added file: http://bugs.python.org/file36675/subprocess.call-deprecate-PIPE.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 10:15:26 2014 From: report at bugs.python.org (Berker Peksag) Date: Sun, 21 Sep 2014 08:15:26 +0000 Subject: [issue11798] Test cases not garbage collected after run In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za> Message-ID: <1411287326.29.0.434080308749.issue11798@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 10:26:35 2014 From: report at bugs.python.org (Joshua Landau) Date: Sun, 21 Sep 2014 08:26:35 +0000 Subject: [issue22451] filtertuple, filterstring and filterunicode don't have optimization for PyBool_Type In-Reply-To: <1411261475.31.0.855934223682.issue22451@psf.upfronthosting.co.za> Message-ID: <1411287995.02.0.909286815241.issue22451@psf.upfronthosting.co.za> Joshua Landau added the comment: That sounds OK to me. It's a bit of a non-issue once you know about it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 10:32:12 2014 From: report at bugs.python.org (juj) Date: Sun, 21 Sep 2014 08:32:12 +0000 Subject: [issue22442] subprocess.check_call hangs on large PIPEd data. In-Reply-To: <1411134999.3.0.739689982343.issue22442@psf.upfronthosting.co.za> Message-ID: <1411288332.86.0.820299177243.issue22442@psf.upfronthosting.co.za> juj added the comment: Hmm, that path does it for stdout=PIPE in subprocess.call only? It could equally apply to stderr=PIPE in subprocess.call as well, and also to both stdout=PIPE and stderr=PIPE in subprocess.check_call? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 11:02:51 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 21 Sep 2014 09:02:51 +0000 Subject: [issue22417] PEP 476: verify HTTPS certificates by default In-Reply-To: <1410784469.95.0.475937020841.issue22417@psf.upfronthosting.co.za> Message-ID: <1411290171.08.0.367339076747.issue22417@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 11:05:15 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 21 Sep 2014 09:05:15 +0000 Subject: [issue22419] wsgiref request length In-Reply-To: <1410804386.26.0.756558523053.issue22419@psf.upfronthosting.co.za> Message-ID: <1411290315.47.0.923097001404.issue22419@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 11:09:34 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 21 Sep 2014 09:09:34 +0000 Subject: [issue22425] 2to3 import fixer writes dotted_as_names into import_as_names In-Reply-To: <1410901227.13.0.545813784004.issue22425@psf.upfronthosting.co.za> Message-ID: <1411290574.28.0.794169523126.issue22425@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 11:27:33 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 21 Sep 2014 09:27:33 +0000 Subject: [issue22407] re.LOCALE is nonsensical for Unicode In-Reply-To: <1410709398.9.0.134852560063.issue22407@psf.upfronthosting.co.za> Message-ID: <1411291653.06.0.30230564282.issue22407@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 11:43:42 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 21 Sep 2014 09:43:42 +0000 Subject: [issue22444] Floor divide should return int In-Reply-To: <1411145815.79.0.695099073811.issue22444@psf.upfronthosting.co.za> Message-ID: <1411292622.69.0.808281248455.issue22444@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 11:47:11 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 21 Sep 2014 09:47:11 +0000 Subject: [issue22450] urllib doesn't put Accept: */* in the headers In-Reply-To: <1411257032.38.0.526589346468.issue22450@psf.upfronthosting.co.za> Message-ID: <1411292831.92.0.202625990362.issue22450@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 11:57:07 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 21 Sep 2014 09:57:07 +0000 Subject: [issue22366] urllib.request.urlopen should take a "context" (SSLContext) argument In-Reply-To: <1410198352.63.0.605714024836.issue22366@psf.upfronthosting.co.za> Message-ID: <1411293427.12.0.00235193584411.issue22366@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever title: urllib.request.urlopen shoudl take a "context" (SSLContext) argument -> urllib.request.urlopen should take a "context" (SSLContext) argument _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 12:41:14 2014 From: report at bugs.python.org (Christian Heimes) Date: Sun, 21 Sep 2014 10:41:14 +0000 Subject: [issue22449] SSLContext.load_verify_locations behavior on Windows and OSX In-Reply-To: <1411209339.34.0.91149685596.issue22449@psf.upfronthosting.co.za> Message-ID: <1411296074.26.0.0644532520776.issue22449@psf.upfronthosting.co.za> Christian Heimes added the comment: 'to respect' is the wrong term. The patch makes the code use the two env vars. Even with my patch the function doesn't respect SSL_CERT_DIR and SSL_CERT_FILE because Windows' cert store is still in use. On Linux and BSD the two env vars replace the default locations. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 13:12:08 2014 From: report at bugs.python.org (Simon Zack) Date: Sun, 21 Sep 2014 11:12:08 +0000 Subject: [issue22452] addTypeEqualityFunc is not used in assertListEqual Message-ID: <1411297928.75.0.716793613355.issue22452@psf.upfronthosting.co.za> New submission from Simon Zack: Functions added by addTypeEqualityFunc is not used for comparing list elements in assertListEqual, and only used in assertEqual. It would be nice to have assertListEqual use functions added by addTypeEqualityFunc for comparisons of list elements. I think this provides more flexibility, and we get nicely formatted error messages for nested list compares for free. ---------- components: Library (Lib) messages: 227210 nosy: simonzack priority: normal severity: normal status: open title: addTypeEqualityFunc is not used in assertListEqual _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 13:12:16 2014 From: report at bugs.python.org (Simon Zack) Date: Sun, 21 Sep 2014 11:12:16 +0000 Subject: [issue22452] addTypeEqualityFunc is not used in assertListEqual In-Reply-To: <1411297928.75.0.716793613355.issue22452@psf.upfronthosting.co.za> Message-ID: <1411297936.97.0.388766898539.issue22452@psf.upfronthosting.co.za> Changes by Simon Zack : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 13:15:13 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 21 Sep 2014 11:15:13 +0000 Subject: [issue22449] SSLContext.load_verify_locations behavior on Windows and OSX In-Reply-To: <1411209339.34.0.91149685596.issue22449@psf.upfronthosting.co.za> Message-ID: <1411298113.14.0.880890782726.issue22449@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Do we have tests for SSL_CERT_DIR and SSL_CERT_FILE being "respected"? Otherwise, it might make sense to add one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 13:16:05 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 21 Sep 2014 11:16:05 +0000 Subject: [issue22452] addTypeEqualityFunc is not used in assertListEqual In-Reply-To: <1411297928.75.0.716793613355.issue22452@psf.upfronthosting.co.za> Message-ID: <1411298165.44.0.755421177647.issue22452@psf.upfronthosting.co.za> Antoine Pitrou added the comment: That sounds reasonable to me. Do you want to provide a patch? See https://docs.python.org/devguide/ for guidelines. ---------- nosy: +ezio.melotti, michael.foord, pitrou stage: -> needs patch versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 13:33:51 2014 From: report at bugs.python.org (Sebastian Berg) Date: Sun, 21 Sep 2014 11:33:51 +0000 Subject: [issue22445] Memoryviews require more strict contiguous checks then necessary In-Reply-To: <1411153250.02.0.529032306838.issue22445@psf.upfronthosting.co.za> Message-ID: <1411299231.66.0.64462677973.issue22445@psf.upfronthosting.co.za> Sebastian Berg added the comment: I am very sorry. The attached patch fixes this (not sure if quite right, but if anything should be more general then necessary). One test fails, but it looks like exactly the intended change. ---------- Added file: http://bugs.python.org/file36676/relaxed-strides-checking.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 14:04:13 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 21 Sep 2014 12:04:13 +0000 Subject: [issue22451] filtertuple, filterstring and filterunicode don't have optimization for PyBool_Type In-Reply-To: <1411261475.31.0.855934223682.issue22451@psf.upfronthosting.co.za> Message-ID: <1411301053.11.0.0801870580844.issue22451@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 14:12:36 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 21 Sep 2014 12:12:36 +0000 Subject: [issue22434] Use named constants internally in the re module In-Reply-To: <1410970188.53.0.105353417029.issue22434@psf.upfronthosting.co.za> Message-ID: <1411301556.53.0.370228869919.issue22434@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I think I agree with Serhiy. Augmenting the import dependencies from the re module can have side effects. While the alternative (a custom Int subclass) isn't extremely pretty, it does the job. NamedIntConstant should be private, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 14:14:46 2014 From: report at bugs.python.org (Sebastian Berg) Date: Sun, 21 Sep 2014 12:14:46 +0000 Subject: [issue22445] Memoryviews require more strict contiguous checks then necessary In-Reply-To: <1411153250.02.0.529032306838.issue22445@psf.upfronthosting.co.za> Message-ID: <1411301686.63.0.715120763494.issue22445@psf.upfronthosting.co.za> Changes by Sebastian Berg : Added file: http://bugs.python.org/file36677/relaxed-strides-checking.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 14:20:02 2014 From: report at bugs.python.org (Sebastian Berg) Date: Sun, 21 Sep 2014 12:20:02 +0000 Subject: [issue22445] Memoryviews require more strict contiguous checks then necessary In-Reply-To: <1411153250.02.0.529032306838.issue22445@psf.upfronthosting.co.za> Message-ID: <1411302002.88.0.927397093438.issue22445@psf.upfronthosting.co.za> Changes by Sebastian Berg : Added file: http://bugs.python.org/file36678/contiguous.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 14:39:32 2014 From: report at bugs.python.org (Christian Heimes) Date: Sun, 21 Sep 2014 12:39:32 +0000 Subject: [issue22449] SSLContext.load_verify_locations behavior on Windows and OSX In-Reply-To: <1411209339.34.0.91149685596.issue22449@psf.upfronthosting.co.za> Message-ID: <1411303172.01.0.76885374313.issue22449@psf.upfronthosting.co.za> Christian Heimes added the comment: There is only a test case for ssl.get_default_verify_paths(), but not for SSLContext or SSLSocket. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 14:54:09 2014 From: report at bugs.python.org (Akira Li) Date: Sun, 21 Sep 2014 12:54:09 +0000 Subject: [issue21332] subprocess bufsize=1 docs are misleading In-Reply-To: <1398209745.28.0.851161689347.issue21332@psf.upfronthosting.co.za> Message-ID: <1411304049.61.0.708637622846.issue21332@psf.upfronthosting.co.za> Changes by Akira Li <4kir4.1i at gmail.com>: Added file: http://bugs.python.org/file36679/subprocess-line-buffering-issue21332-ps5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 15:07:57 2014 From: report at bugs.python.org (Sebastian Berg) Date: Sun, 21 Sep 2014 13:07:57 +0000 Subject: [issue22445] Memoryviews require more strict contiguous checks then necessary In-Reply-To: <1411153250.02.0.529032306838.issue22445@psf.upfronthosting.co.za> Message-ID: <1411304877.65.0.819205197638.issue22445@psf.upfronthosting.co.za> Changes by Sebastian Berg : Added file: http://bugs.python.org/file36680/contiguous.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 15:21:31 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 21 Sep 2014 13:21:31 +0000 Subject: [issue21332] subprocess bufsize=1 docs are misleading In-Reply-To: <1398209745.28.0.851161689347.issue21332@psf.upfronthosting.co.za> Message-ID: <1411305691.62.0.186224233664.issue21332@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- assignee: gregory.p.smith -> stage: -> commit review versions: -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 15:21:46 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 21 Sep 2014 13:21:46 +0000 Subject: [issue21332] subprocess bufsize=1 docs are misleading In-Reply-To: <1398209745.28.0.851161689347.issue21332@psf.upfronthosting.co.za> Message-ID: <1411305706.45.0.201187564773.issue21332@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The latest patch looks good to me. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 16:03:12 2014 From: report at bugs.python.org (Akira Li) Date: Sun, 21 Sep 2014 14:03:12 +0000 Subject: [issue22442] subprocess.check_call hangs on large PIPEd data. In-Reply-To: <1411134999.3.0.739689982343.issue22442@psf.upfronthosting.co.za> Message-ID: <1411308192.84.0.204567285112.issue22442@psf.upfronthosting.co.za> Akira Li added the comment: @juj: DeprecationWarning is generated if PIPE is passed to call() as any positional or keyword argument in particular stdin, stdout, stderr. It also applies to check_call() that uses call() internally. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 17:48:37 2014 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 21 Sep 2014 15:48:37 +0000 Subject: [issue22434] Use named constants internally in the re module In-Reply-To: <1411301556.53.0.370228869919.issue22434@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: OK, then if you want to review Serhiy's original patch that would be great. On Sun, Sep 21, 2014 at 5:12 AM, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > > I think I agree with Serhiy. Augmenting the import dependencies from the > re module can have side effects. While the alternative (a custom Int > subclass) isn't extremely pretty, it does the job. > > NamedIntConstant should be private, though. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 18:26:08 2014 From: report at bugs.python.org (Chris Colbert) Date: Sun, 21 Sep 2014 16:26:08 +0000 Subject: [issue22453] PyObject_REPR macro causes refcount leak Message-ID: <1411316768.43.0.141557856004.issue22453@psf.upfronthosting.co.za> New submission from Chris Colbert: This is how the macro is defined in object.h: 2.7 /* Helper for passing objects to printf and the like */ #define PyObject_REPR(obj) PyString_AS_STRING(PyObject_Repr(obj)) 3.4 /* Helper for passing objects to printf and the like */ #define PyObject_REPR(obj) _PyUnicode_AsString(PyObject_Repr(obj)) PyObject_Repr returns a new reference, which is not released by the macro. This macro only seems to be used internally for error reporting in compile.c, so it's unlikely to be causing any pressing issues for the interpreter, but it may be biting some extension modules. ---------- components: Extension Modules, Interpreter Core messages: 227219 nosy: Chris.Colbert priority: normal severity: normal status: open title: PyObject_REPR macro causes refcount leak type: behavior versions: 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 Sun Sep 21 18:36:19 2014 From: report at bugs.python.org (R. David Murray) Date: Sun, 21 Sep 2014 16:36:19 +0000 Subject: [issue22452] addTypeEqualityFunc is not used in assertListEqual In-Reply-To: <1411297928.75.0.716793613355.issue22452@psf.upfronthosting.co.za> Message-ID: <1411317379.02.0.501049776324.issue22452@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 18:50:45 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 21 Sep 2014 16:50:45 +0000 Subject: [issue22434] Use named constants internally in the re module In-Reply-To: <1411301556.53.0.370228869919.issue22434@psf.upfronthosting.co.za> Message-ID: <2680490.2If3WBvlMO@raxxla> Serhiy Storchaka added the comment: > NamedIntConstant should be private, though. Agree. I'll add underscore to NamedIntConstant and makecode before committing (as in enum patch). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 18:55:15 2014 From: report at bugs.python.org (SilentGhost) Date: Sun, 21 Sep 2014 16:55:15 +0000 Subject: [issue17432] ucs2 In-Reply-To: <1363385884.71.0.776131230148.issue17432@psf.upfronthosting.co.za> Message-ID: <1411318515.29.0.274564647756.issue17432@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- title: PyUnicode_ functions not accessible in Limited API on Windows -> ucs2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 18:55:29 2014 From: report at bugs.python.org (SilentGhost) Date: Sun, 21 Sep 2014 16:55:29 +0000 Subject: [issue17432] PyUnicode_ functions not accessible in Limited API on Windows In-Reply-To: <1363385884.71.0.776131230148.issue17432@psf.upfronthosting.co.za> Message-ID: <1411318529.28.0.835507821516.issue17432@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- title: ucs2 -> PyUnicode_ functions not accessible in Limited API on Windows _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 19:33:43 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 21 Sep 2014 17:33:43 +0000 Subject: [issue21079] EmailMessage.is_attachment == False if filename is present In-Reply-To: <1395940330.14.0.456041860337.issue21079@psf.upfronthosting.co.za> Message-ID: <1411320823.59.0.886850022106.issue21079@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Following expression looks more clear to me: c_d is not None and c_d.content_disposition == 'attachment' ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 20:29:23 2014 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 21 Sep 2014 18:29:23 +0000 Subject: [issue22452] addTypeEqualityFunc is not used in assertListEqual In-Reply-To: <1411297928.75.0.716793613355.issue22452@psf.upfronthosting.co.za> Message-ID: <1411324163.84.0.716992603099.issue22452@psf.upfronthosting.co.za> Ezio Melotti added the comment: Currently assertListEqual calls assertSequenceEqual, and assertSequenceEqual doesn't use any function to compare list elements -- it just does "if item1 != item2:" (https://hg.python.org/cpython/file/default/Lib/unittest/case.py). Checking the types of the two items and compare them recursively could be done, but it's not as simple as it sounds, since using e.g. assertSequenceEqual will raise an error message that will need to be caught and integrated with the error message that it's already being constructed, possibly resulting in a long and unreadable message. Since this is a somewhat specific situation, it might be better if you just defined your own assert function for nested lists. In addition to nested lists you might have a dictionary that contains lists, or a set of tuples or any other combinations of arbitrarily nested containers, and having a generic way to handle them all will require quite a lot of work. One thing that could be done is to add more attributes to the exception raised by assertSequenceEqual (and others), so that you could do something like: try: self.assertEqual(nested_list1, nested_list2) except AssertionError as exc: index = exc.first_differing_index self.assertEqual(nested_list1[index], nested_list2[index], msg=str(exc)) Not sure how that will look light though, and it's still not a generic solution, but if you know what are you dealing with, it might be helpful. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 21:15:52 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 21 Sep 2014 19:15:52 +0000 Subject: [issue21332] subprocess bufsize=1 docs are misleading In-Reply-To: <1398209745.28.0.851161689347.issue21332@psf.upfronthosting.co.za> Message-ID: <20140921191550.13817.9604@mail.hg.python.org> Roundup Robot added the comment: New changeset 38867f90f1d9 by Antoine Pitrou in branch '3.4': Issue #21332: Ensure that ``bufsize=1`` in subprocess.Popen() selects line buffering, rather than block buffering. https://hg.python.org/cpython/rev/38867f90f1d9 New changeset 763d565e5840 by Antoine Pitrou in branch 'default': Issue #21332: Ensure that ``bufsize=1`` in subprocess.Popen() selects line buffering, rather than block buffering. https://hg.python.org/cpython/rev/763d565e5840 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 21:16:14 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 21 Sep 2014 19:16:14 +0000 Subject: [issue22442] subprocess.check_call hangs on large PIPEd data. In-Reply-To: <1411134999.3.0.739689982343.issue22442@psf.upfronthosting.co.za> Message-ID: <1411326974.92.0.410043000092.issue22442@psf.upfronthosting.co.za> STINNER Victor added the comment: The first place to warn uses about dangerous function calls is the documentation, and your patch doesn't touch the documentation. You can for example suggest to use check_output(), getstatusouptut() or getoutput(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 21:16:25 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 21 Sep 2014 19:16:25 +0000 Subject: [issue21332] subprocess bufsize=1 docs are misleading In-Reply-To: <1398209745.28.0.851161689347.issue21332@psf.upfronthosting.co.za> Message-ID: <1411326985.96.0.285835942657.issue21332@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Pushed! Thank you! ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 21:26:13 2014 From: report at bugs.python.org (Sworddragon) Date: Sun, 21 Sep 2014 19:26:13 +0000 Subject: [issue22443] read(1) blocks on unflushed output In-Reply-To: <1411135688.43.0.0648130638254.issue22443@psf.upfronthosting.co.za> Message-ID: <1411327573.6.0.258115796493.issue22443@psf.upfronthosting.co.za> Sworddragon added the comment: It works if "-q 0" is given without the need of a workaround. So this was just a feature of apt that was causing this behavior. I think here is nothing more to do so I'm closing this ticket. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 21:30:45 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 21 Sep 2014 19:30:45 +0000 Subject: [issue22423] Errors in printing exceptions raised in a thread In-Reply-To: <1410856630.14.0.274476260629.issue22423@psf.upfronthosting.co.za> Message-ID: <20140921193042.76054.87049@mail.hg.python.org> Roundup Robot added the comment: New changeset 4baa474b4f31 by Serhiy Storchaka in branch '2.7': Issue #22423: Unhandled exception in thread no longer causes unhandled https://hg.python.org/cpython/rev/4baa474b4f31 New changeset 176579df4edd by Serhiy Storchaka in branch '3.4': Issue #22423: Unhandled exception in thread no longer causes unhandled https://hg.python.org/cpython/rev/176579df4edd New changeset 644b677c2ae5 by Serhiy Storchaka in branch 'default': Issue #22423: Unhandled exception in thread no longer causes unhandled https://hg.python.org/cpython/rev/644b677c2ae5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 21:35:49 2014 From: report at bugs.python.org (Sworddragon) Date: Sun, 21 Sep 2014 19:35:49 +0000 Subject: [issue22454] Adding the opposite function of shlex.split() Message-ID: <1411328149.26.0.00522128245951.issue22454@psf.upfronthosting.co.za> New submission from Sworddragon: There is currently shlex.split() that is for example useful to split a command string and pass it to subprocess.Popen with shell=False. But I'm missing a function that does the opposite: Building the command string from a list that could for example then be used in subprocess.Popen with shell=True. ---------- components: Library (Lib) messages: 227228 nosy: Sworddragon priority: normal severity: normal status: open title: Adding the opposite function of shlex.split() type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 21:51:05 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 21 Sep 2014 19:51:05 +0000 Subject: [issue22423] Errors in printing exceptions raised in a thread In-Reply-To: <1410856630.14.0.274476260629.issue22423@psf.upfronthosting.co.za> Message-ID: <1411329065.55.0.377292961058.issue22423@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Senthil for your review. Committed with you suggestion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 21:51:59 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 21 Sep 2014 19:51:59 +0000 Subject: [issue22423] Errors in printing exceptions raised in a thread In-Reply-To: <1410856630.14.0.274476260629.issue22423@psf.upfronthosting.co.za> Message-ID: <20140921195156.38443.63937@mail.hg.python.org> Roundup Robot added the comment: New changeset c925b436467a by Serhiy Storchaka in branch '2.7': Issue #22423: Fixed debugging output of the GROUPREF_EXISTS opcode in the re https://hg.python.org/cpython/rev/c925b436467a New changeset e99a1df8db36 by Serhiy Storchaka in branch '3.4': Issue #22423: Fixed debugging output of the GROUPREF_EXISTS opcode in the re https://hg.python.org/cpython/rev/e99a1df8db36 New changeset fe287268e97b by Serhiy Storchaka in branch 'default': Issue #22423: Fixed debugging output of the GROUPREF_EXISTS opcode in the re https://hg.python.org/cpython/rev/fe287268e97b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 21:53:36 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 21 Sep 2014 19:53:36 +0000 Subject: [issue22415] Fix re debugging output In-Reply-To: <1410768434.94.0.831625656606.issue22415@psf.upfronthosting.co.za> Message-ID: <1411329216.19.0.331506243691.issue22415@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Committed with Antoine's suggestion. Thank you Antoine. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 22:02:11 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 21 Sep 2014 20:02:11 +0000 Subject: [issue22415] Fix re debugging output In-Reply-To: <1410768434.94.0.831625656606.issue22415@psf.upfronthosting.co.za> Message-ID: <20140921200209.5866.6959@mail.hg.python.org> Roundup Robot added the comment: New changeset d4630b1c8792 by Serhiy Storchaka in branch '2.7': Fixed issue #22415 number in Misc/NEWS for changeset c925b436467a. https://hg.python.org/cpython/rev/d4630b1c8792 New changeset 7b92518b2c21 by Serhiy Storchaka in branch '3.4': Fixed issue #22415 number in Misc/NEWS for changeset e99a1df8db36. https://hg.python.org/cpython/rev/7b92518b2c21 New changeset fb93a04832df by Serhiy Storchaka in branch 'default': Fixed issue #22415 number in Misc/NEWS for changeset fe287268e97b. https://hg.python.org/cpython/rev/fb93a04832df ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 22:15:32 2014 From: report at bugs.python.org (Stefan Krah) Date: Sun, 21 Sep 2014 20:15:32 +0000 Subject: [issue22445] Memoryviews require more strict contiguous checks then necessary In-Reply-To: <1411153250.02.0.529032306838.issue22445@psf.upfronthosting.co.za> Message-ID: <1411330532.43.0.188834353806.issue22445@psf.upfronthosting.co.za> Stefan Krah added the comment: Thanks! I still have to review the patch in depth, but generally I'm +1 now for relaxing the contiguity check. Curiously enough the existing code already considered e.g. shape=[1], strides=[-5] as contiguous. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 22:19:38 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 21 Sep 2014 20:19:38 +0000 Subject: [issue22435] socketserver.TCPSocket leaks socket to garbage collector if server_bind() fails In-Reply-To: <1410999922.66.0.432841070426.issue22435@psf.upfronthosting.co.za> Message-ID: <1411330778.74.0.834062345464.issue22435@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Patch looks of to me. ---------- versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 22:23:19 2014 From: report at bugs.python.org (Ben Roberts) Date: Sun, 21 Sep 2014 20:23:19 +0000 Subject: [issue22454] Adding the opposite function of shlex.split() In-Reply-To: <1411328149.26.0.00522128245951.issue22454@psf.upfronthosting.co.za> Message-ID: <1411330999.64.0.765115765726.issue22454@psf.upfronthosting.co.za> Ben Roberts added the comment: ' '.join(shlex.quote(x) for x in split_command) ---------- nosy: +roippi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 22:45:06 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 21 Sep 2014 20:45:06 +0000 Subject: [issue12728] Python re lib fails case insensitive matches on Unicode data In-Reply-To: <1313088501.39.0.822875623158.issue12728@psf.upfronthosting.co.za> Message-ID: <1411332306.83.0.105424261001.issue12728@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is preliminary patch which fixes case-insensitive regular expression matching of unicode strings. It is incomplete, it needs applying patches from issue17381, which fixes other aspects of case-insensitive matching. One bug is left for Turkish letters. This matching is not transitive. Three pairs of letters should match: ? ~ I ~ i ~ ?. All other combinations should not match (? !~ i, I !~ ?, ? !~ ?). This patch doesn't fixes this bug. ---------- assignee: -> serhiy.storchaka dependencies: +IGNORECASE breaks unicode literal range matching keywords: +patch nosy: +serhiy.storchaka stage: needs patch -> patch review versions: +Python 3.5 -Python 3.3 Added file: http://bugs.python.org/file36681/re_ignore_case.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 22:49:46 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 21 Sep 2014 20:49:46 +0000 Subject: [issue22437] re module: number of named groups is limited to 100 max In-Reply-To: <1411061982.07.0.646375842297.issue22437@psf.upfronthosting.co.za> Message-ID: <1411332586.84.0.627612508094.issue22437@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch which removes static limit. It is much more complicated than the first patch and I prefer first apply the first patch. Aren't 1000 groups enough for everyone? ---------- Added file: http://bugs.python.org/file36682/re_maxgroups_dynamic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 22:50:24 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 21 Sep 2014 20:50:24 +0000 Subject: [issue22362] Warn about octal escapes > 0o377 in re In-Reply-To: <1410174440.93.0.911211496637.issue22362@psf.upfronthosting.co.za> Message-ID: <1411332624.79.0.9149665445.issue22362@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If this is error, should the patch be applied to maintained releases? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 21 23:26:34 2014 From: report at bugs.python.org (Sworddragon) Date: Sun, 21 Sep 2014 21:26:34 +0000 Subject: [issue22454] Adding the opposite function of shlex.split() In-Reply-To: <1411328149.26.0.00522128245951.issue22454@psf.upfronthosting.co.za> Message-ID: <1411334794.92.0.8705349665.issue22454@psf.upfronthosting.co.za> Sworddragon added the comment: Yes, it is possible to do this with a few other commands. But I think it would be still a nice enhancement to have a direct function for it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 00:09:35 2014 From: report at bugs.python.org (Buck Golemon) Date: Sun, 21 Sep 2014 22:09:35 +0000 Subject: [issue22455] idna/punycode give wrong results on narrow builds Message-ID: <1411337375.42.0.97875155095.issue22455@psf.upfronthosting.co.za> New submission from Buck Golemon: I have "fixed" the issue in my branch here: https://github.com/bukzor/cpython/commit/013e689731ba32319f05a62a602f01dd7d7f2e83 I don't propose it as a patch, but as a proof of concept and point of discussion. If there's no chance of shipping a fix in 2.7.9, feel free to close. ---------- messages: 227240 nosy: bukzor priority: normal severity: normal status: open title: idna/punycode give wrong results on narrow builds versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 00:54:27 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 21 Sep 2014 22:54:27 +0000 Subject: [issue22456] __base__ undocumented Message-ID: <1411340067.19.0.0232279983568.issue22456@psf.upfronthosting.co.za> New submission from Arfrever Frehtes Taifersar Arahesis: __bases__ is documented, but __base__ is not. $ grep -r __base__ Doc $ grep -r __bases__ Doc Doc/c-api/object.rst:are different objects, *B*'s :attr:`~class.__bases__` attribute is searched in Doc/c-api/object.rst:a depth-first fashion for *A* --- the presence of the :attr:`~class.__bases__` Doc/extending/newtypes.rst: in its :attr:`~class.__bases__`, or else it will not be able to call your type's Doc/library/email.headerregistry.rst: class's ``__bases__`` list. Doc/library/functions.rst: tuple itemizes the base classes and becomes the :attr:`~class.__bases__` Doc/library/stdtypes.rst:.. attribute:: class.__bases__ Doc/reference/datamodel.rst: single: __bases__ (class attribute) Doc/reference/datamodel.rst: dictionary containing the class's namespace; :attr:`~class.__bases__` is a Doc/whatsnew/2.3.rst: removed: you can now assign to the :attr:`__name__` and :attr:`__bases__` Doc/whatsnew/2.3.rst: assigned to :attr:`__bases__` along the lines of those relating to assigning to ---------- assignee: docs at python components: Documentation keywords: easy messages: 227241 nosy: Arfrever, docs at python priority: normal severity: normal status: open title: __base__ undocumented type: enhancement versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 01:46:14 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 21 Sep 2014 23:46:14 +0000 Subject: [issue22456] __base__ undocumented In-Reply-To: <1411340067.19.0.0232279983568.issue22456@psf.upfronthosting.co.za> Message-ID: <1411343174.0.0.985234972689.issue22456@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I think that __base__ was intended to be a non-guaranteed implementation detail for new-style classes just like __dictoffset__ and __flags__ . ---------- nosy: +gvanrossum, rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 02:07:09 2014 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 22 Sep 2014 00:07:09 +0000 Subject: [issue22456] __base__ undocumented In-Reply-To: <1411340067.19.0.0232279983568.issue22456@psf.upfronthosting.co.za> Message-ID: <1411344429.63.0.95531745115.issue22456@psf.upfronthosting.co.za> Guido van Rossum added the comment: Raymond is correct. __base__ is closely tied to the C implementation. I think it might be worth a mention, but with an explicit note that it is CPython-specific. It is sometimes useful, e.g. when wondering why a certain case of multiple inheritance is rejected. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 02:08:21 2014 From: report at bugs.python.org (Ben Roberts) Date: Mon, 22 Sep 2014 00:08:21 +0000 Subject: [issue22454] Adding the opposite function of shlex.split() In-Reply-To: <1411328149.26.0.00522128245951.issue22454@psf.upfronthosting.co.za> Message-ID: <1411344501.47.0.74416003027.issue22454@psf.upfronthosting.co.za> Ben Roberts added the comment: For the record I am on board with a shlex.join. Even though the implementation is simple: - It is not obvious to many users if there are any "gotchas" by doing a ' '.join yourself, /even if/ you know that strings with spaces in them need to pass through shlex.quote first. - The symmetry of shlex.split and shlex.join is obvious - I don't need to read any documentation to know that they are inverse operations. - "batteries included," "one obvious way," and all that. ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 02:13:38 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 22 Sep 2014 00:13:38 +0000 Subject: [issue22456] __base__ undocumented In-Reply-To: <1411340067.19.0.0232279983568.issue22456@psf.upfronthosting.co.za> Message-ID: <1411344818.14.0.873058165922.issue22456@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: __base__ exists also in Jython and PyPy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 02:36:37 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 22 Sep 2014 00:36:37 +0000 Subject: [issue22455] idna/punycode give wrong results on narrow builds In-Reply-To: <1411337375.42.0.97875155095.issue22455@psf.upfronthosting.co.za> Message-ID: <1411346197.57.0.636486987331.issue22455@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +lemburg, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 04:07:04 2014 From: report at bugs.python.org (Ben Roberts) Date: Mon, 22 Sep 2014 02:07:04 +0000 Subject: [issue19119] duplicate test name in Lib/test/test_heapq.py In-Reply-To: <1380401602.68.0.29924709136.issue19119@psf.upfronthosting.co.za> Message-ID: <1411351624.22.0.838062027079.issue19119@psf.upfronthosting.co.za> Ben Roberts added the comment: > The major issue (there are other issues as well but not so difficult) is whether nlargest and nsmallest should support iterator that could be endless iterator or reject it (by checking __len__ attribute) straight away. Well, failing with an exception isn't right. I can imagine doing (and probably have done, at some point) nlargest on any number of generators, streams of data, etc. So unless anyone can solve the halting problem (:-)) the behavior of nlargest is correct as possible; nlargest(2, GetOnly()) behaves just like list(GetOnly()) - they both hang forever. The proper action here is just a fix in the tests: make GetOnly raise IndexError at some point so that it is a proper sequence. (also rename the second test to get_cmp_only) ---------- nosy: +roippi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 04:12:49 2014 From: report at bugs.python.org (Martin Panter) Date: Mon, 22 Sep 2014 02:12:49 +0000 Subject: [issue4887] environment inspection and manipulation API is buggy, inconsistent with "Python philosophy" for wrapping native APIs In-Reply-To: <1231452487.08.0.408278867366.issue4887@psf.upfronthosting.co.za> Message-ID: <1411351969.95.0.749948572031.issue4887@psf.upfronthosting.co.za> Martin Panter added the comment: I suspect the $PATH example is a bad example. On my Linux setup, my initial PATH value is a customized path. After popping it and calling system(), I see a simpler default path, which is probably re-initialized somewhere else. I suspect there is no environ.pop() bug. Everthing works according the documentation if you use another environment variable: $ TEST_VARIABLE=value python Python 3.4.0 (default, Mar 17 2014, 23:20:09) [GCC 4.8.2 20140206 (prerelease)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.system('echo "$TEST_VARIABLE"') value 0 >>> os.environ.pop("TEST_VARIABLE") 'value' >>> os.system('echo "$TEST_VARIABLE"') 0 The other point in this report, about synchronizing ?os.environ? with the C APIs, is a duplicate of Issue 1159. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 04:44:01 2014 From: report at bugs.python.org (Martin Panter) Date: Mon, 22 Sep 2014 02:44:01 +0000 Subject: [issue1159] os.getenv() not updated after external module uses C putenv() In-Reply-To: <1189668127.19.0.0258251668017.issue1159@psf.upfronthosting.co.za> Message-ID: <1411353841.5.0.849895510456.issue1159@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 04:49:28 2014 From: report at bugs.python.org (Ben Roberts) Date: Mon, 22 Sep 2014 02:49:28 +0000 Subject: [issue19119] duplicate test name in Lib/test/test_heapq.py In-Reply-To: <1380401602.68.0.29924709136.issue19119@psf.upfronthosting.co.za> Message-ID: <1411354168.65.0.557660405846.issue19119@psf.upfronthosting.co.za> Ben Roberts added the comment: Attached patch fixes the tests. ---------- Added file: http://bugs.python.org/file36683/fix_heapq_tests.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 05:09:17 2014 From: report at bugs.python.org (Kevin Christopher Henry) Date: Mon, 22 Sep 2014 03:09:17 +0000 Subject: [issue19111] 2to3 should remove from future_builtins import * In-Reply-To: <1380379953.79.0.934483665034.issue19111@psf.upfronthosting.co.za> Message-ID: <1411355357.23.0.431533993391.issue19111@psf.upfronthosting.co.za> Kevin Christopher Henry added the comment: I'm interested in working on this, but it's not clear to me if this has been accepted as a bug. I converted a large project recently and was shocked to find that all 100+ files were broken because of the needless "from future_builtins..." line. Perversely, this most hurts those who made the most effort to make their code forward-compatible with Python 3. One complication is that you can't simply substitute a blank line, since that could produce invalid code if the import is inside a try/except block. (This doesn't affect "from __future__..." since that can only be at the start of a file.) Substituting a "pass" should work fine though. That would be a bit unsightly, but then again so is the blank line at the start of the file produced by removing "from __future__...". More important is to produce code that actually works under Python 3. Another issue is that it's possible to simply "import future_builtins" and then use, for example, "future_builtins.zip(...)". So trying to fix that usage as well would be (I assume) a lot more complicated. Personally it seems fine with me to just fix the "from __future_builtins__..." usage. ---------- nosy: +marfire versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 05:47:54 2014 From: report at bugs.python.org (Robert Collins) Date: Mon, 22 Sep 2014 03:47:54 +0000 Subject: [issue22457] load_tests not invoked in root __init__.py when start=package root Message-ID: <1411357674.43.0.0204872118136.issue22457@psf.upfronthosting.co.za> New submission from Robert Collins: python -m unittest discover -t . foo where foo is a package will not trigger load_tests in foo/__init__.py. To reproduce: mkdir -p demo/tests cd demo cat < tests/__init__.py import sys import os def load_tests(loader, tests, pattern): print("HI WE ARE LOADING!") this_dir = os.path.dirname(__file__) tests.addTest(loader.discover(start_dir=this_dir, pattern=pattern)) return tests EOF python -m unittest discover -t . tests ---------- messages: 227250 nosy: rbcollins priority: normal severity: normal status: open title: load_tests not invoked in root __init__.py when start=package root _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 06:02:52 2014 From: report at bugs.python.org (Akira Li) Date: Mon, 22 Sep 2014 04:02:52 +0000 Subject: [issue22442] subprocess.check_call hangs on large PIPEd data. In-Reply-To: <1411134999.3.0.739689982343.issue22442@psf.upfronthosting.co.za> Message-ID: <1411358572.81.0.47017649792.issue22442@psf.upfronthosting.co.za> Akira Li added the comment: Victor, the message in my patch is copied almost verbatim from the current subprocess' documentation [1] [1] https://hg.python.org/cpython/file/850a62354402/Doc/library/subprocess.rst#l57 People use `call(cmd, stdout=PIPE)` as a *broken* way to suppress output i.e., when they actually want `call(cmd, stdout=DEVNULL)` The issue with `call(cmd, stdout=PIPE)` that it *appears* to work if cmd doesn't produce much output i.e., it might work in tests but may hang in production. It is unrelated to check_output(), getstatusouptut() or getoutput(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 06:16:40 2014 From: report at bugs.python.org (mike bayer) Date: Mon, 22 Sep 2014 04:16:40 +0000 Subject: [issue22457] load_tests not invoked in root __init__.py when start=package root In-Reply-To: <1411357674.43.0.0204872118136.issue22457@psf.upfronthosting.co.za> Message-ID: <1411359400.92.0.289776977599.issue22457@psf.upfronthosting.co.za> Changes by mike bayer : ---------- nosy: +zzzeek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 09:10:30 2014 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 22 Sep 2014 07:10:30 +0000 Subject: [issue22458] Add fractions benchmark Message-ID: <1411369830.75.0.216203072207.issue22458@psf.upfronthosting.co.za> New submission from Stefan Behnel: Fractions are great for all sorts of exact computations (including money/currency calculations), but are quite slow due to the need for normalisation at instantiation time. I adapted the existing telco benchmark to use Fraction instead of Decimal to make this problem more visible. One change I made was to take the data reading out of the measured loop. I/O is not part of what the benchmark should measure. Please consider adding it to the benchmark suite. ---------- components: Benchmarks files: telco_fractions.py messages: 227252 nosy: scoder priority: normal severity: normal status: open title: Add fractions benchmark type: enhancement Added file: http://bugs.python.org/file36684/telco_fractions.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 09:40:26 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 22 Sep 2014 07:40:26 +0000 Subject: [issue22457] load_tests not invoked in root __init__.py when start=package root In-Reply-To: <1411357674.43.0.0204872118136.issue22457@psf.upfronthosting.co.za> Message-ID: <1411371626.73.0.120873467201.issue22457@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +ezio.melotti, michael.foord _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 09:44:17 2014 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 22 Sep 2014 07:44:17 +0000 Subject: [issue22458] Add fractions benchmark In-Reply-To: <1411369830.75.0.216203072207.issue22458@psf.upfronthosting.co.za> Message-ID: <1411371857.6.0.939037260434.issue22458@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 09:49:30 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 22 Sep 2014 07:49:30 +0000 Subject: [issue22278] urljoin duplicate slashes In-Reply-To: <1409075887.24.0.237889697027.issue22278@psf.upfronthosting.co.za> Message-ID: <20140922074927.111281.35215@mail.hg.python.org> Roundup Robot added the comment: New changeset 901e4e52b20a by Senthil Kumaran in branch 'default': Issue #22278: Fix urljoin problem with relative urls, a regression observed https://hg.python.org/cpython/rev/901e4e52b20a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 09:49:30 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 22 Sep 2014 07:49:30 +0000 Subject: [issue22118] urljoin fails with messy relative URLs In-Reply-To: <1406900329.8.0.528379735401.issue22118@psf.upfronthosting.co.za> Message-ID: <20140922074927.111281.77479@mail.hg.python.org> Roundup Robot added the comment: New changeset 901e4e52b20a by Senthil Kumaran in branch 'default': Issue #22278: Fix urljoin problem with relative urls, a regression observed https://hg.python.org/cpython/rev/901e4e52b20a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 09:50:02 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Mon, 22 Sep 2014 07:50:02 +0000 Subject: [issue22278] urljoin duplicate slashes In-Reply-To: <1409075887.24.0.237889697027.issue22278@psf.upfronthosting.co.za> Message-ID: <1411372202.66.0.443665185042.issue22278@psf.upfronthosting.co.za> Senthil Kumaran added the comment: I addressed Antoine's comments with the patch and committed it. Thank you! ---------- assignee: -> orsenthil resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 09:56:07 2014 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 22 Sep 2014 07:56:07 +0000 Subject: [issue22458] Add fractions benchmark In-Reply-To: <1411369830.75.0.216203072207.issue22458@psf.upfronthosting.co.za> Message-ID: <1411372567.27.0.542888380568.issue22458@psf.upfronthosting.co.za> Stefan Behnel added the comment: I just thought that it might also be nice to have a direct comparison with Decimal, so here's an updated benchmark that has an option "--use-decimal" to run the same code with Decimal instead of Fraction. Decimal is about 66x faster with Py3.4 on my side (due to the C implementation). ---------- Added file: http://bugs.python.org/file36685/bm_telco_fractions.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 10:32:10 2014 From: report at bugs.python.org (SebKL) Date: Mon, 22 Sep 2014 08:32:10 +0000 Subject: [issue22459] str.strip() documentation: wrong example Message-ID: <1411374730.07.0.0715795458179.issue22459@psf.upfronthosting.co.za> New submission from SebKL: The following example is wrong: https://docs.python.org/3.4/library/stdtypes.html?highlight=split#str.split >>> '1,2,3'.split(',', maxsplit=1) ['1', '2 3'] Is actually returning (note the missing , ): >>> '1,2,3'.split(',', maxsplit=1) ['1', '2,3'] ---------- assignee: docs at python components: Documentation messages: 227257 nosy: SebKL, docs at python priority: normal severity: normal status: open title: str.strip() documentation: wrong example type: enhancement versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 11:46:35 2014 From: report at bugs.python.org (=?utf-8?q?Ra=C3=BAl_Cumplido?=) Date: Mon, 22 Sep 2014 09:46:35 +0000 Subject: [issue22459] str.strip() documentation: wrong example In-Reply-To: <1411374730.07.0.0715795458179.issue22459@psf.upfronthosting.co.za> Message-ID: <1411379195.55.0.989785638429.issue22459@psf.upfronthosting.co.za> Ra?l Cumplido added the comment: As it is a simple one I will try to submit a patch today or tomorrow. This will be my first contribution to Python. ---------- nosy: +raulcd _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 12:03:02 2014 From: report at bugs.python.org (Alex Willmer) Date: Mon, 22 Sep 2014 10:03:02 +0000 Subject: [issue12006] strptime should implement %V or %u directive from libc In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za> Message-ID: <1411380182.37.0.839341411109.issue12006@psf.upfronthosting.co.za> Alex Willmer added the comment: Alexander, http://bugs.python.org/file36417/12006_3.5_complete.patch updates the previous patches and is ready for review. Unit tests pass as of today. Regards, Alex W. ---------- nosy: +Alex.Willmer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 12:28:55 2014 From: report at bugs.python.org (bagrat lazaryan) Date: Mon, 22 Sep 2014 10:28:55 +0000 Subject: [issue22460] idle editor: replace all in selection Message-ID: <1411381735.15.0.967867369025.issue22460@psf.upfronthosting.co.za> New submission from bagrat lazaryan: say, for renaming a variable in a block of code, or in a function, or renaming a method name in a class, etc. nothing fancy here, a button in the replace dialog will do. i think the proposed functionality is needed much more often than the currently implemented replacing within the whole file. ---------- components: IDLE messages: 227260 nosy: bagratte priority: normal severity: normal status: open title: idle editor: replace all in selection type: enhancement versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 12:58:58 2014 From: report at bugs.python.org (=?utf-8?b?0JTQtdC90LjRgSDQmtC+0YDQtdC90LXQstGB0LrQuNC5?=) Date: Mon, 22 Sep 2014 10:58:58 +0000 Subject: [issue22433] Argparse considers unknown optional arguments with spaces as a known positional argument In-Reply-To: <1410969476.15.0.703805216421.issue22433@psf.upfronthosting.co.za> Message-ID: <1411383538.01.7.27174835887e-05.issue22433@psf.upfronthosting.co.za> ????? ??????????? added the comment: There is an standard way to solve this ambiguity. There is a special marker '--' used to force argument parsing function treat all arguments given in command after this marker as positional arguments. It was invented specially for tasks where you need to force argument parsing engine ignore option indicator and treat argument as positional. I know this argument as standard 'de facto', but can't find any documents about '--' interpretation. But you can see, that Linux 'libc' standard C library function getopt() knows about this flag: http://linux.die.net/man/3/getopt So, any utility using this function knows about '--'. For example: grep, tee, cat, tail, head, vim, less, rm, rmdir, common shells (sh, bash, csh, dash, ...) and so on. The list is large. Almost any utility except special ones like 'echo' which main function is to print any argument given to utility. So, I think, that the true way here is to parse all arguments staring with '-'/'--' and listed before special '--' marker as optional, and treat all of arguments listed after '--' as positional ones and do not try to use any secondary indicators to make a decision: 'optional' or not. For example: """ any parameter before '--' special marker starting with '--' is treated as optional # python3 example.py --bar="one two" xxx (Namespace(pos='xxx'), ['--bar=one two']) all parameters after '--' special marker are treated as positional # python3 example.py -- --bar="one two" xxx (Namespace(pos='--bar=one two'), ['xxx']) """ Yes, my patch does not the solution and argparse should be patched another way. Where and how can I get unittests for argparse module to check my code modifications before posting them here? I want to try to modify argparse and produce the patch changing argparse behaviour as described above. Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 14:20:33 2014 From: report at bugs.python.org (Stefan Krah) Date: Mon, 22 Sep 2014 12:20:33 +0000 Subject: [issue22445] Memoryviews require more strict contiguous checks then necessary In-Reply-To: <1411153250.02.0.529032306838.issue22445@psf.upfronthosting.co.za> Message-ID: <1411388433.71.0.386370729098.issue22445@psf.upfronthosting.co.za> Stefan Krah added the comment: Since the functions in abstract.c have been committed by Travis Oliphant: Could there have been a reason why the {shape=[1], strides=[-5]} case was considered but the general case was not? Or is it generally accepted among the numpy devs that not considering the general case was just an oversight? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 14:27:18 2014 From: report at bugs.python.org (Sebastian Berg) Date: Mon, 22 Sep 2014 12:27:18 +0000 Subject: [issue22445] Memoryviews require more strict contiguous checks then necessary In-Reply-To: <1411153250.02.0.529032306838.issue22445@psf.upfronthosting.co.za> Message-ID: <1411388838.61.0.0442870542039.issue22445@psf.upfronthosting.co.za> Sebastian Berg added the comment: Yeah, the code does much the same as the old numpy code (at least most of the same funny little things, though I seem to remember the old numpy code had something yet a bit weirder, would have to check). To be honest, I do not know. It isn't implausible that the original numpy code dates back 15 years or more to numeric. I doubt whoever originally wrote it thought much about it, but there may be some good reason, and there is the safety considerations that people use the strides in a way they should not, which may trip us here in any case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 14:32:18 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 22 Sep 2014 12:32:18 +0000 Subject: [issue22458] Add fractions benchmark In-Reply-To: <1411369830.75.0.216203072207.issue22458@psf.upfronthosting.co.za> Message-ID: <1411389138.87.0.0665426612063.issue22458@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Where are Fractions used in the real world? ---------- nosy: +pitrou, skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 14:51:35 2014 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 22 Sep 2014 12:51:35 +0000 Subject: [issue22458] Add fractions benchmark In-Reply-To: <1411369830.75.0.216203072207.issue22458@psf.upfronthosting.co.za> Message-ID: <1411390295.76.0.3480115528.issue22458@psf.upfronthosting.co.za> Stefan Behnel added the comment: As I said, where ever exact calculations are needed. I use them for currency calculations, for example, as they inherently avoid rounding errors during the calculations regardless of the relative size of values. They are basically like Decimal but with arbitrary precision. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 15:13:00 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 22 Sep 2014 13:13:00 +0000 Subject: [issue22458] Add fractions benchmark In-Reply-To: <1411390295.76.0.3480115528.issue22458@psf.upfronthosting.co.za> Message-ID: <54202059.8090200@free.fr> Antoine Pitrou added the comment: Le 22/09/2014 14:51, Stefan Behnel a ?crit : > > I use them for currency calculations, for example, > as they inherently avoid rounding errors during the > calculations regardless of the relative size of values. Do other people use them for that purpose, or are you the only one? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 15:14:17 2014 From: report at bugs.python.org (Larry Hastings) Date: Mon, 22 Sep 2014 13:14:17 +0000 Subject: [issue22461] Test failure: Lib/test/test_pydoc.py line 851, "topic?key=def" Message-ID: <1411391657.7.0.939727555746.issue22461@psf.upfronthosting.co.za> New submission from Larry Hastings: I get a test failure in the regression test suite. This appears to be the important bit: Traceback (most recent call last): File "/tmp/Python-3.4.2rc1/Lib/test/test_pydoc.py", line 851, in test_url_requests self.assertEqual(result, title, text) AssertionError: 'Pydoc: Error - topic?key=def' != 'Pydoc: KEYWORD def' - Pydoc: Error - topic?key=def + Pydoc: KEYWORD def I can ship 3.4.2rc1 like this, but I'd really like this fixed before 3.4.2 final. Does anybody own pydoc? There's no "expert" listed on the Python Experts page. (Adding you, Georg, because you're the DE.) ---------- messages: 227267 nosy: georg.brandl, larry priority: deferred blocker severity: normal stage: needs patch status: open title: Test failure: Lib/test/test_pydoc.py line 851, "topic?key=def" type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 15:19:05 2014 From: report at bugs.python.org (Georg Brandl) Date: Mon, 22 Sep 2014 13:19:05 +0000 Subject: [issue22461] Test failure: Lib/test/test_pydoc.py line 851, "topic?key=def" In-Reply-To: <1411391657.7.0.939727555746.issue22461@psf.upfronthosting.co.za> Message-ID: <1411391945.26.0.89639973838.issue22461@psf.upfronthosting.co.za> Georg Brandl added the comment: I have no idea about that code, and I can't reproduce the failure. (Could the buildbots?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 15:29:18 2014 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 22 Sep 2014 13:29:18 +0000 Subject: [issue22458] Add fractions benchmark In-Reply-To: <1411369830.75.0.216203072207.issue22458@psf.upfronthosting.co.za> Message-ID: <1411392558.12.0.573812448637.issue22458@psf.upfronthosting.co.za> Stefan Behnel added the comment: I admit that I keep meeting developers who are not aware of their merits, simply because many other programming languages don't have them available. Specifically, many developers with a Java background firmly believe that BigDecimal is the only way to do money calculations. That's clearly wrong, and the heap of (Big-)Decimal bugs in their software that I've been fixing over the years shows just how wrong it is. Using Fractions would have avoided most of them. Decimal is surprisingly difficult to use right, Fractions are actually difficult to get wrong. They are a major feature of the standard library. Your question is another good indication that the general awareness for them still needs to be raised. I'm not entirely sure how this relates to this ticket, though. I doubt that you are seriously suggesting that I am the only person using a module in the stdlib, so what exactly are you trying to say? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 15:42:11 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 22 Sep 2014 13:42:11 +0000 Subject: [issue22461] Test failure: Lib/test/test_pydoc.py line 851, "topic?key=def" In-Reply-To: <1411391657.7.0.939727555746.issue22461@psf.upfronthosting.co.za> Message-ID: <1411393331.25.0.705688641035.issue22461@psf.upfronthosting.co.za> R. David Murray added the comment: I can't reproduce it either, and none of the failing stable buildbots show this error. Unfortunately we can only look at tip since we can't see your tag yet. But I doubt that's the issue...the last commit to pydoc or its tests was on the 17th, and was a one line change in an unrelated area. Last change before that was in June. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 15:46:55 2014 From: report at bugs.python.org (Larry Hastings) Date: Mon, 22 Sep 2014 13:46:55 +0000 Subject: [issue22461] Test failure: Lib/test/test_pydoc.py line 851, "topic?key=def" In-Reply-To: <1411391657.7.0.939727555746.issue22461@psf.upfronthosting.co.za> Message-ID: <1411393615.8.0.804454521556.issue22461@psf.upfronthosting.co.za> Larry Hastings added the comment: FWIW, 3.4.2rc1 is based on 7af0315bdfe0. (The release process creates a couple additional changesets.) The failure is on my laptop, Ubuntu 14.04 x64. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 15:58:28 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 22 Sep 2014 13:58:28 +0000 Subject: [issue22461] Test failure: Lib/test/test_pydoc.py line 851, "topic?key=def" In-Reply-To: <1411391657.7.0.939727555746.issue22461@psf.upfronthosting.co.za> Message-ID: <1411394308.97.0.339521509514.issue22461@psf.upfronthosting.co.za> R. David Murray added the comment: No failure running test_pydoc for me on gentoo linux with that changeset. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 16:13:21 2014 From: report at bugs.python.org (Demian Brecht) Date: Mon, 22 Sep 2014 14:13:21 +0000 Subject: [issue22278] urljoin duplicate slashes In-Reply-To: <1409075887.24.0.237889697027.issue22278@psf.upfronthosting.co.za> Message-ID: <1411395201.19.0.471940247276.issue22278@psf.upfronthosting.co.za> Demian Brecht added the comment: Heh, I'd finally gotten a few minutes to address the comments... And it's already taken care of ;) Thanks Senthil. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 16:52:34 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 22 Sep 2014 14:52:34 +0000 Subject: [issue12006] strptime should implement %V or %u directive from libc In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za> Message-ID: <1411397554.23.0.523906921052.issue12006@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I find this footnote somewhat confusing: """ (8) Similar to %U and %W, %V is only used in calculations when the day of the week and the ISO year (%G) are specified when used with the strptime method. """ The existing footnote (7) is much clearer: """ (7) When used with the strptime() method, %U and %W are only used in calculations when the day of the week and the year are specified. """ Why not use the same language in (8)? """ (7) When used with the strptime() method, %V is only used in calculations when the day of the week and the ISO year (%G) are specified. """ ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 17:02:07 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 22 Sep 2014 15:02:07 +0000 Subject: [issue12006] strptime should implement %V or %u directive from libc In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za> Message-ID: <1411398127.23.0.220476787804.issue12006@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: How was "%Y %V" issue resolved? I don't see any tests for this case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 17:03:50 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 22 Sep 2014 15:03:50 +0000 Subject: [issue22458] Add fractions benchmark In-Reply-To: <1411369830.75.0.216203072207.issue22458@psf.upfronthosting.co.za> Message-ID: <1411398230.13.0.301735364688.issue22458@psf.upfronthosting.co.za> Antoine Pitrou added the comment: My point is that if fractions are little used right now, there's little point in adding a benchmark about them in the "official" benchmark suite. The benchmark suite does not aim at measuring every possible aspect of Python performance, but at showcasing representative workloads. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 17:39:43 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 22 Sep 2014 15:39:43 +0000 Subject: [issue22444] Floor divide should return int In-Reply-To: <1411145815.79.0.695099073811.issue22444@psf.upfronthosting.co.za> Message-ID: <1411400383.0.0.110517193167.issue22444@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: [Raymond] > The current behavior has been around for a long time and is implemented in several modules including decimal and fractions. No, in the fractions module floor division returns an int: >>> type(Fraction(2) // Fraction(1)) It is also implemented in the datetime module where >>> type(timedelta(2) // timedelta(1)) [Raymond] # Here is a simple example of a chain of calculations # where preserving the type matters .. def f(x, y): return x // 3 * 5 / 7 + y def g(x, y): return int(x // 3) * 5 / 7 + y [/Raymond] I am not sure what is the problem here. In Python 3: >>> f(12.143, 0.667) 3.5241428571428575 >>> g(12.143, 0.667) 3.5241428571428575 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 17:51:23 2014 From: report at bugs.python.org (Mark Shannon) Date: Mon, 22 Sep 2014 15:51:23 +0000 Subject: [issue22462] Modules/pyexpat.c violates PEP 384 Message-ID: <1411401083.5.0.108064936526.issue22462@psf.upfronthosting.co.za> New submission from Mark Shannon: Modules/pyexpat.c includes some archaic code to create temporary frames so that, in even of an exception being raised, expat appears in the traceback. The way this is implemented is a problem for three reasons: 1. It violates PEP 384. 2. It is incorrect, see http://bugs.python.org/issue6359. 3. It is inefficient, as a frame is generated for each call, regardless of whether an exception is raised or not. The attached patch fixes these issues. ---------- components: Library (Lib) files: expat.patch keywords: patch messages: 227278 nosy: Mark.Shannon priority: normal severity: normal status: open title: Modules/pyexpat.c violates PEP 384 versions: Python 3.5 Added file: http://bugs.python.org/file36686/expat.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 17:52:19 2014 From: report at bugs.python.org (Mark Shannon) Date: Mon, 22 Sep 2014 15:52:19 +0000 Subject: [issue22462] Modules/pyexpat.c violates PEP 384 In-Reply-To: <1411401083.5.0.108064936526.issue22462@psf.upfronthosting.co.za> Message-ID: <1411401139.26.0.66302023903.issue22462@psf.upfronthosting.co.za> Changes by Mark Shannon : ---------- nosy: +nedbat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 19:00:16 2014 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 22 Sep 2014 17:00:16 +0000 Subject: [issue22444] Floor divide should return int In-Reply-To: <1411145815.79.0.695099073811.issue22444@psf.upfronthosting.co.za> Message-ID: <1411405216.56.0.93188429423.issue22444@psf.upfronthosting.co.za> Mark Dickinson added the comment: -1 from me, too. It's an unnecessary change, and the conversion from float to integer potentially expensive compared to the computation of the floating-point result (especially in extended floating-point implementations that allow a wider exponent range). If this is about consistency between `//` and `math.floor`, I'd much rather see `math.floor` go back to returning a float instead of an int. ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 19:09:35 2014 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 22 Sep 2014 17:09:35 +0000 Subject: [issue22458] Add fractions benchmark In-Reply-To: <1411369830.75.0.216203072207.issue22458@psf.upfronthosting.co.za> Message-ID: <1411405775.27.0.433647302747.issue22458@psf.upfronthosting.co.za> Mark Dickinson added the comment: I've always viewed the `Fraction` type as more of a teaching tool than something intended for real-world calculations. If that's not how others see it, then it might be worth investing some effort in reimplementing `Fractions.gcd` in C: the `Fraction` type is almost unusably slow for serious work, and the gcd computations are a clear bottleneck. I've experimented in the past with a C-based implementation of Lehmer's algorithm for gcd computation, getting around a ten-fold speedup. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 19:23:40 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 22 Sep 2014 17:23:40 +0000 Subject: [issue22444] Floor divide should return int In-Reply-To: <1411145815.79.0.695099073811.issue22444@psf.upfronthosting.co.za> Message-ID: <1411406620.96.0.652849044208.issue22444@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: [Raymond] > The PEP should be revised to say that floor division is defined to > return a value that is *equal* to an Integral but not place any > restriction on the return type. If we take this route, what float('inf') // 1 and float('nan') // 1 should return? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 19:29:15 2014 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 22 Sep 2014 17:29:15 +0000 Subject: [issue22444] Floor divide should return int In-Reply-To: <1411145815.79.0.695099073811.issue22444@psf.upfronthosting.co.za> Message-ID: <1411406955.56.0.807436019742.issue22444@psf.upfronthosting.co.za> Mark Dickinson added the comment: > If we take this route, what float('inf') // 1 and float('nan') // 1 should return? Probably exactly the same as they do right now. I think there's an argument that `float('inf') // 1` "should have been" `float('inf')`. But I'm not sure there's much of a case for *changing* the current return value. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 19:32:49 2014 From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=) Date: Mon, 22 Sep 2014 17:32:49 +0000 Subject: [issue22463] Warnings when building on AIX Message-ID: <1411407169.47.0.841951681699.issue22463@psf.upfronthosting.co.za> New submission from Julien ?LIE: Building Python 2.7.8 on AIX 7.1 gives the following warnings: Parser/pgen.c:282:9: warning: variable 'i' set but not used [-Wunused-but-set-variable] Include/objimpl.h:164:66: warning: right-hand operand of comma expression has no effect [-Wunused-value] /home/iulius/autobuild/src/Python-2.7.8/Modules/cPickle.c:4495:8: warning: assuming signed overflow does not occur when assuming that (X - c) > X is always false [-Wstrict-overflow] /home/iulius/autobuild/src/Python-2.7.8/Modules/cPickle.c:202:8: warning: assuming signed overflow does not occur when assuming that (X - c) > X is always false [-Wstrict-overflow] /home/iulius/autobuild/src/Python-2.7.8/Modules/readline.c:777:1: warning: 'on_completion_display_matches_hook' defined but not used [-Wunused-function] ./pyconfig.h:1182:0: warning: "_POSIX_C_SOURCE" redefined ./pyconfig.h:1204:0: warning: "_XOPEN_SOURCE" redefined /home/iulius/autobuild/src/Python-2.7.8/Modules/tkappinit.c:29:15: warning: variable 'main_window' set but not used [-Wunused-but-set-variable] /home/iulius/autobuild/src/Python-2.7.8/Modules/_ctypes/ctypes.h:456:13: warning: 'capsule_destructor_CTYPES_CAPSULE_WCHAR_T' defined but not used [-Wunused-function] /home/iulius/autobuild/src/Python-2.7.8/Modules/_ctypes/cfield.c:50:29: warning: variable 'length' set but not used [-Wunused-but-set-variable] /home/iulius/autobuild/src/Python-2.7.8/Modules/_ctypes/ctypes.h:456:13: warning: 'capsule_destructor_CTYPES_CAPSULE_WCHAR_T' defined but not used [-Wunused-function] ---------- components: Build messages: 227283 nosy: jelie priority: normal severity: normal status: open title: Warnings when building on AIX type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 19:37:14 2014 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 22 Sep 2014 17:37:14 +0000 Subject: [issue22464] Speed up fractions implementation Message-ID: <1411407434.75.0.285038516488.issue22464@psf.upfronthosting.co.za> New submission from Stefan Behnel: Fractions are an excellent way to do exact money calculations and largely beat Decimal in terms of simplicity, accuracy and safety. Clearly not in terms of speed, though. The current implementation does some heavy type checking and dispatching in __new__() and a simplistic gcd based normalisation. Here is a profiling run from the benchmark proposed in issue 22458 (which matches more or less the results with my own code): 6969671 function calls (6969278 primitive calls) in 4.835 seconds Ordered by: internal time ncalls tottime percall cumtime percall filename:lineno(function) 519644 1.324 0.000 2.928 0.000 fractions.py:73(__new__) 519632 0.654 0.000 0.654 0.000 fractions.py:17(gcd) 319744 0.637 0.000 2.694 0.000 fractions.py:400(_add) 1039260 0.507 0.000 0.950 0.000 abc.py:178(__instancecheck__) 4 0.459 0.115 4.821 1.205 bm_telco_fractions.py:38(run) 1039300 0.443 0.000 0.443 0.000 _weakrefset.py:70(__contains__) 519616 0.301 0.000 4.329 0.000 fractions.py:373(forward) 199872 0.272 0.000 1.335 0.000 fractions.py:416(_mul) 1598720 0.117 0.000 0.117 0.000 fractions.py:278(denominator) 959232 0.074 0.000 0.074 0.000 fractions.py:274(numerator) The instantiation itself takes twice as much time as the gcd calculations, and both dominate the overall runtime of the benchmark by about 60%. Improving the instantiation time would thus bring a substantial benefit. ---------- components: Library (Lib) messages: 227284 nosy: scoder priority: normal severity: normal status: open title: Speed up fractions implementation versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 19:37:41 2014 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 22 Sep 2014 17:37:41 +0000 Subject: [issue22458] Add fractions benchmark In-Reply-To: <1411369830.75.0.216203072207.issue22458@psf.upfronthosting.co.za> Message-ID: <1411407461.8.0.979653167833.issue22458@psf.upfronthosting.co.za> Stefan Behnel added the comment: Speed improvements for fractions should have their own ticket(s). I created issue 22464 for this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 19:38:47 2014 From: report at bugs.python.org (Zachary Ware) Date: Mon, 22 Sep 2014 17:38:47 +0000 Subject: [issue22461] Test failure: Lib/test/test_pydoc.py line 851, "topic?key=def" In-Reply-To: <1411391657.7.0.939727555746.issue22461@psf.upfronthosting.co.za> Message-ID: <1411407527.23.0.431386302679.issue22461@psf.upfronthosting.co.za> Zachary Ware added the comment: R. David Murray wrote (on python-committers): > So...Larry broke it, but it is not obvious how. Could it be something > wrong with the pydoc topics update for the release? Indeed, it looks like somehow the pydoc-topics update turned all of the values in the topics dict into bytes literals rather than plain strings. Unfortunately, I don't have the right setup currently to look into it further, but my best guess would be that perhaps the pydoc-topics Sphinx builder needs an update for Python 3? ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 19:42:03 2014 From: report at bugs.python.org (Georg Brandl) Date: Mon, 22 Sep 2014 17:42:03 +0000 Subject: [issue22461] Test failure: Lib/test/test_pydoc.py line 851, "topic?key=def" In-Reply-To: <1411391657.7.0.939727555746.issue22461@psf.upfronthosting.co.za> Message-ID: <1411407723.67.0.77047835457.issue22461@psf.upfronthosting.co.za> Georg Brandl added the comment: That is very likely the reason. So far nobody has run the builder with Python 3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 19:44:49 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 22 Sep 2014 17:44:49 +0000 Subject: [issue22461] Test failure: Lib/test/test_pydoc.py line 851, "topic?key=def" In-Reply-To: <1411391657.7.0.939727555746.issue22461@psf.upfronthosting.co.za> Message-ID: <1411407889.71.0.337222520304.issue22461@psf.upfronthosting.co.za> Ned Deily added the comment: Duplicate of Issue21431? ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 20:01:32 2014 From: report at bugs.python.org (Georg Brandl) Date: Mon, 22 Sep 2014 18:01:32 +0000 Subject: [issue22461] Test failure: Lib/test/test_pydoc.py line 851, "topic?key=def" In-Reply-To: <1411391657.7.0.939727555746.issue22461@psf.upfronthosting.co.za> Message-ID: <1411408892.67.0.749223062837.issue22461@psf.upfronthosting.co.za> Georg Brandl added the comment: Yep. ---------- resolution: -> duplicate status: open -> closed superseder: -> 3.4.1rc1 test_pydoc fails: pydoc_data.topics.topics values are type "bytes" not "str" _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 20:25:02 2014 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 22 Sep 2014 18:25:02 +0000 Subject: [issue22464] Speed up fractions implementation In-Reply-To: <1411407434.75.0.285038516488.issue22464@psf.upfronthosting.co.za> Message-ID: <1411410302.18.0.517725532799.issue22464@psf.upfronthosting.co.za> Stefan Behnel added the comment: Adding Mark Dickinson to the noisy list who mentioned having worked on a C implementation for gcd(). I think this would be a good thing to try. However, the most important part would be to restructure and specialise Fraction.__new__(). ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 20:26:32 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 22 Sep 2014 18:26:32 +0000 Subject: [issue22458] Add fractions benchmark In-Reply-To: <1411369830.75.0.216203072207.issue22458@psf.upfronthosting.co.za> Message-ID: <1411410392.31.0.445915103697.issue22458@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Where are Fractions used in the real world? For example Andrew Svetlov uses them in his online game [1]. May be it will explain this in detail. [1] http://asvetlov.blogspot.com/2012/08/numerics.html (on Russian). ---------- nosy: +asvetlov, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 20:41:43 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 22 Sep 2014 18:41:43 +0000 Subject: [issue18629] future division breaks timedelta division by integer In-Reply-To: <1375456931.04.0.558889166858.issue18629@psf.upfronthosting.co.za> Message-ID: <1411411303.79.0.368400674099.issue18629@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 20:42:48 2014 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 22 Sep 2014 18:42:48 +0000 Subject: [issue22464] Speed up fractions implementation In-Reply-To: <1411407434.75.0.285038516488.issue22464@psf.upfronthosting.co.za> Message-ID: <1411411368.95.0.494083066581.issue22464@psf.upfronthosting.co.za> Stefan Behnel added the comment: Here is a straight forward patch that special cases int values in the constructor. It gives me a 35% speedup in the benchmark. ---------- keywords: +patch Added file: http://bugs.python.org/file36687/special_case_int.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 20:45:44 2014 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 22 Sep 2014 18:45:44 +0000 Subject: [issue22464] Speed up fractions implementation In-Reply-To: <1411407434.75.0.285038516488.issue22464@psf.upfronthosting.co.za> Message-ID: <1411411544.36.0.357339466552.issue22464@psf.upfronthosting.co.za> Changes by Stefan Behnel : ---------- type: -> performance _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 20:54:26 2014 From: report at bugs.python.org (Zachary Ware) Date: Mon, 22 Sep 2014 18:54:26 +0000 Subject: [issue21431] 3.4.1rc1 test_pydoc fails: pydoc_data.topics.topics values are type "bytes" not "str" In-Reply-To: <1399234251.1.0.221071278299.issue21431@psf.upfronthosting.co.za> Message-ID: <1411412066.23.0.0248245193953.issue21431@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 20:57:10 2014 From: report at bugs.python.org (David Edelsohn) Date: Mon, 22 Sep 2014 18:57:10 +0000 Subject: [issue22463] Warnings when building on AIX In-Reply-To: <1411407169.47.0.841951681699.issue22463@psf.upfronthosting.co.za> Message-ID: <1411412230.25.0.955050736786.issue22463@psf.upfronthosting.co.za> Changes by David Edelsohn : ---------- nosy: +David.Edelsohn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 20:58:27 2014 From: report at bugs.python.org (David Edelsohn) Date: Mon, 22 Sep 2014 18:58:27 +0000 Subject: [issue22396] AIX posix_fadvise and posix_fallocate In-Reply-To: <1410546003.27.0.984640019214.issue22396@psf.upfronthosting.co.za> Message-ID: <1411412307.74.0.735431255191.issue22396@psf.upfronthosting.co.za> David Edelsohn added the comment: Any feedback about which approach would be acceptable? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 20:58:34 2014 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 22 Sep 2014 18:58:34 +0000 Subject: [issue22464] Speed up fractions implementation In-Reply-To: <1411407434.75.0.285038516488.issue22464@psf.upfronthosting.co.za> Message-ID: <1411412314.73.0.0652468651608.issue22464@psf.upfronthosting.co.za> Stefan Behnel added the comment: Updated patch - there is a somewhat hidden attempt in the code to keep nominator and denominater plain int values, not subtypes. That means that it's safer to restrict the optimisation to plain ints as well, which should still hit >95% of the use cases. ---------- Added file: http://bugs.python.org/file36688/special_case_int2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 21:10:49 2014 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 22 Sep 2014 19:10:49 +0000 Subject: [issue22464] Speed up fractions implementation In-Reply-To: <1411407434.75.0.285038516488.issue22464@psf.upfronthosting.co.za> Message-ID: <1411413049.27.0.363059116292.issue22464@psf.upfronthosting.co.za> Changes by Stefan Behnel : Added file: http://bugs.python.org/file36689/special_case_int3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 21:19:19 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 22 Sep 2014 19:19:19 +0000 Subject: [issue22464] Speed up fractions implementation In-Reply-To: <1411407434.75.0.285038516488.issue22464@psf.upfronthosting.co.za> Message-ID: <1411413559.65.0.999086111257.issue22464@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What speedup give you second change? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 21:22:30 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 22 Sep 2014 19:22:30 +0000 Subject: [issue21431] 3.4.1rc1 test_pydoc fails: pydoc_data.topics.topics values are type "bytes" not "str" In-Reply-To: <1399234251.1.0.221071278299.issue21431@psf.upfronthosting.co.za> Message-ID: <20140922192223.43654.68795@mail.hg.python.org> Roundup Robot added the comment: New changeset d71c351a6a0f by Georg Brandl in branch '3.4': Closes #21431: make docs depend on Sphinx 1.2 and fix pydoc-topics builder to https://hg.python.org/cpython/rev/d71c351a6a0f ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 21:22:57 2014 From: report at bugs.python.org (Georg Brandl) Date: Mon, 22 Sep 2014 19:22:57 +0000 Subject: [issue21431] 3.4.1rc1 test_pydoc fails: pydoc_data.topics.topics values are type "bytes" not "str" In-Reply-To: <1399234251.1.0.221071278299.issue21431@psf.upfronthosting.co.za> Message-ID: <1411413777.8.0.265673253468.issue21431@psf.upfronthosting.co.za> Georg Brandl added the comment: Should be fixed now. I didn't merge into default since someone (cough) has to null-merge all the release related stuff first. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 21:23:27 2014 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 22 Sep 2014 19:23:27 +0000 Subject: [issue22464] Speed up fractions implementation In-Reply-To: <1411407434.75.0.285038516488.issue22464@psf.upfronthosting.co.za> Message-ID: <1411413807.68.0.167721892096.issue22464@psf.upfronthosting.co.za> Stefan Behnel added the comment: The second isn't a big difference because it only hits plain instantiations from integers. They are less likely to be performance critical than those from a quotient, which happen for all calculations. It's more for symmetry, I guess. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 21:35:53 2014 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 22 Sep 2014 19:35:53 +0000 Subject: [issue22464] Speed up fractions implementation In-Reply-To: <1411407434.75.0.285038516488.issue22464@psf.upfronthosting.co.za> Message-ID: <1411414553.59.0.534536716077.issue22464@psf.upfronthosting.co.za> Stefan Behnel added the comment: I found one more place where special casing helps: equal comparisons to integers, e.g. f == 0 or f == 1 or so. timeit shows me a speedup by a factor of three for this, with only a tiny slow-down when comparing fractions on both sides. I put all of them in one patch, deselecting after applying should be easy enough. ---------- Added file: http://bugs.python.org/file36690/special_case_int4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 21:37:01 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 22 Sep 2014 19:37:01 +0000 Subject: [issue22464] Speed up fractions implementation In-Reply-To: <1411413807.68.0.167721892096.issue22464@psf.upfronthosting.co.za> Message-ID: <5043136.K0MRaVG1Ja@raxxla> Serhiy Storchaka added the comment: Microbenchmarks show about 2x speedup in both cases. The patch LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 21:40:43 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 22 Sep 2014 19:40:43 +0000 Subject: [issue22444] Floor divide should return int In-Reply-To: <1411145815.79.0.695099073811.issue22444@psf.upfronthosting.co.za> Message-ID: <1411414843.09.0.670249390173.issue22444@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Mark, Raymond suggested that "The PEP 3141 should be revised to say that floor division is defined to return a value that is *equal* to an Integral". Since nan or inf are not *equal* to any Integral, the current implementation does not comply. In the absence of a recommendation in the PEP, implementers of new numeric types are left with little guidance because existing types are inconsistent: >>> Decimal('inf') // 1 Decimal('Infinity') >>> float('inf') // 1 nan ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 21:46:55 2014 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 22 Sep 2014 19:46:55 +0000 Subject: [issue22464] Speed up fractions implementation In-Reply-To: <1411407434.75.0.285038516488.issue22464@psf.upfronthosting.co.za> Message-ID: <1411415215.74.0.341184090034.issue22464@psf.upfronthosting.co.za> Stefan Behnel added the comment: Benchmark profile after the patch: 5930670 function calls (5930288 primitive calls) in 3.748 seconds Ordered by: internal time ncalls tottime percall cumtime percall filename:lineno(function) 519632 0.828 0.000 0.828 0.000 fractions.py:17(gcd) 519644 0.806 0.000 1.700 0.000 fractions.py:73(__new__) 319744 0.630 0.000 1.983 0.000 fractions.py:408(_add) 4 0.393 0.098 3.735 0.934 bm_telco_fractions.py:38(run) 519616 0.277 0.000 3.316 0.000 fractions.py:381(forward) 199872 0.275 0.000 0.901 0.000 fractions.py:424(_mul) 1598720 0.161 0.000 0.161 0.000 fractions.py:285(denominator) 520257 0.155 0.000 0.155 0.000 {built-in method isinstance} 959232 0.118 0.000 0.118 0.000 fractions.py:281(numerator) 519657 0.066 0.000 0.066 0.000 {built-in method __new__ of type object at 0x9d1c40} Note that the gcd() call inside of __new__() now takes about as much time as the rest of the __new__() itself. It's clearly still worth optimising that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 21:48:40 2014 From: report at bugs.python.org (Stefan Krah) Date: Mon, 22 Sep 2014 19:48:40 +0000 Subject: [issue22444] Floor divide should return int In-Reply-To: <1411414843.09.0.670249390173.issue22444@psf.upfronthosting.co.za> Message-ID: <20140922194839.GA22908@sleipnir.bytereef.org> Stefan Krah added the comment: Alexander Belopolsky wrote: > Raymond suggested that "The PEP 3141 should be revised to say that floor division is defined to return a value that is *equal* to an Integral". I guess it should say "equal to an Integral or a special value". > Since nan or inf are not *equal* to any Integral, the current implementation does not comply. In the absence of a recommendation in the PEP, implementers of new numeric types are left with little guidance because existing types are inconsistent: > > >>> Decimal('inf') // 1 > Decimal('Infinity') > >>> float('inf') // 1 > nan I think both should return inf. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 21:53:33 2014 From: report at bugs.python.org (Pau Amma) Date: Mon, 22 Sep 2014 19:53:33 +0000 Subject: [issue22465] Number agreement error in section 3.2 of web docs Message-ID: <1411415613.69.0.707690037263.issue22465@psf.upfronthosting.co.za> New submission from Pau Amma: In https://docs.python.org/2/reference/datamodel.html#the-standard-type-hierarchy, under "numbers.Real (float)", in sentence "the savings in processor and memory usage that are usually the reason for using these is dwarfed by the overhead of using objects in Python" either "is dwarfed" should be "are dwarfed" (preferred) or "are usually" should be "is usually" ---------- assignee: docs at python components: Documentation messages: 227304 nosy: docs at python, pauamma priority: normal severity: normal status: open title: Number agreement error in section 3.2 of web docs type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 21:55:13 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 22 Sep 2014 19:55:13 +0000 Subject: [issue22444] Floor divide should return int In-Reply-To: <1411145815.79.0.695099073811.issue22444@psf.upfronthosting.co.za> Message-ID: <1411415713.27.0.668964329665.issue22444@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: skrah> I think both should return inf. What about this case: >>> Decimal('1') // Decimal('-inf') Decimal('-0') >>> 1. // float('-inf') -1.0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 22:02:33 2014 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 22 Sep 2014 20:02:33 +0000 Subject: [issue22444] Floor divide should return int In-Reply-To: <1411145815.79.0.695099073811.issue22444@psf.upfronthosting.co.za> Message-ID: <1411416153.92.0.551316164557.issue22444@psf.upfronthosting.co.za> Mark Dickinson added the comment: I think that one's covered by #22198. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 22:27:03 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 22 Sep 2014 20:27:03 +0000 Subject: [issue22198] Odd floor-division corner case In-Reply-To: <1408034861.79.0.503776123394.issue22198@psf.upfronthosting.co.za> Message-ID: <1411417623.16.0.620714557347.issue22198@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 22:44:13 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 22 Sep 2014 20:44:13 +0000 Subject: [issue22198] Odd floor-division corner case In-Reply-To: <1408034861.79.0.503776123394.issue22198@psf.upfronthosting.co.za> Message-ID: <1411418653.59.0.619563571239.issue22198@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I wonder if it would make sense to rewrite float_divmod using the newer POSIX/C99 remquo function. I believe it is designed to compute the exact value of round(x/y), but getting floor instead should not be hard. Its behavior on special values is fully specified. >From the Linux man-page (I believe POSIX/C99 only guarantees 3 bits in quo): NAME remquo -- floating-point remainder and quotient function SYNOPSIS #include double remquo(double x, double y, int *quo); long double remquol(long double x, long double y, int *quo); float remquof(float x, float y, int *quo); DESCRIPTION The remquo() functions compute the value r such that r = x - n*y, where n is the integer nearest the exact value of x/y. If there are two integers closest to x/y, n shall be the even one. If r is zero, it is given the same sign as x. This is the same value that is returned by the remainder() function. remquo() also calculates the lower seven bits of the integral quotient x/y, and gives that value the same sign as x/y. It stores this signed value in the object pointed to by quo. SPECIAL VALUES remquo(x, y, quo) returns a NaN and raises the "invalid" floating-point exception if x is infinite or y is 0. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 22:52:40 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 22 Sep 2014 20:52:40 +0000 Subject: [issue22198] Odd floor-division corner case In-Reply-To: <1408034861.79.0.503776123394.issue22198@psf.upfronthosting.co.za> Message-ID: <1411419160.21.0.646930961532.issue22198@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 23:11:45 2014 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 22 Sep 2014 21:11:45 +0000 Subject: [issue22464] Speed up fractions implementation In-Reply-To: <1411407434.75.0.285038516488.issue22464@psf.upfronthosting.co.za> Message-ID: <1411420305.84.0.0186675796744.issue22464@psf.upfronthosting.co.za> Stefan Behnel added the comment: Here is another little optimisation that removes the redundant property lookups for the denominator in __add__() and __sub__(). New profile: 5291182 function calls (5290800 primitive calls) in 3.596 seconds Ordered by: internal time ncalls tottime percall cumtime percall filename:lineno(function) 519632 0.843 0.000 0.843 0.000 fractions.py:17(gcd) 519644 0.800 0.000 1.709 0.000 fractions.py:73(__new__) 319744 0.520 0.000 1.816 0.000 fractions.py:408(_add) 4 0.401 0.100 3.582 0.896 bm_telco_fractions.py:38(run) 519616 0.291 0.000 3.156 0.000 fractions.py:381(forward) 199872 0.274 0.000 0.904 0.000 fractions.py:424(_mul) 520257 0.145 0.000 0.145 0.000 {built-in method isinstance} 959232 0.108 0.000 0.108 0.000 fractions.py:285(denominator) 959232 0.108 0.000 0.108 0.000 fractions.py:281(numerator) 519657 0.066 0.000 0.066 0.000 {built-in method __new__ of type object at 0x9d1c40} ---------- Added file: http://bugs.python.org/file36691/avoid_redundant_property_lookups.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 23:17:14 2014 From: report at bugs.python.org (=?utf-8?q?Ra=C3=BAl_Cumplido?=) Date: Mon, 22 Sep 2014 21:17:14 +0000 Subject: [issue22459] str.strip() documentation: wrong example In-Reply-To: <1411374730.07.0.0715795458179.issue22459@psf.upfronthosting.co.za> Message-ID: <1411420634.08.0.780874191646.issue22459@psf.upfronthosting.co.za> Ra?l Cumplido added the comment: It was also incorrect on the example for bytes split: >>> b'1,2,3'.split(b',', maxsplit=1) [b'1', b'2 3'] Patch submitted. ---------- keywords: +patch Added file: http://bugs.python.org/file36692/issue22459.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 23:25:09 2014 From: report at bugs.python.org (paul j3) Date: Mon, 22 Sep 2014 21:25:09 +0000 Subject: [issue22433] Argparse considers unknown optional arguments with spaces as a known positional argument In-Reply-To: <1410969476.15.0.703805216421.issue22433@psf.upfronthosting.co.za> Message-ID: <1411421109.76.0.798922009121.issue22433@psf.upfronthosting.co.za> paul j3 added the comment: Proposed patches like this are supposed to be generated against the current development version (3.5...), especially if they are 'enhancements' (as opposed to bugs). But there isn't much of a difference in argparse between 2.7+ and 3.4+ (except one nested yield expression). Tests are in 'lib/test/...' argparse does implement the '--' syntax. That is, anything after it is understood to be positional, regardless of its prefix characters. But before that, optionals and positionals can be freely mixed (within limits). I agree that '--foo=one two' looks a lot more like an unknown optional than the test case 'a badger'. Strings with '=' are tested earlier in _parse_optional. A fix that passes test_argparse.py and your example is: if '=' in arg_string: option_string, explicit_arg = arg_string.split('=', 1) if option_string in self._option_string_actions: action = self._option_string_actions[option_string] return action, option_string, explicit_arg else: # added for unrecognized return None, option_string, explicit_arg # or return None, arg_string, None But the '=' case is also tested in the following line: option_tuples = self._get_option_tuples(arg_string) The obvious difference is that _get_option_tuples handles abbreviations. I wonder if the two can be refined to reduce the duplication, and handler your case as well. There are other bug issues dealing with multiple '--', the mixing of optionals and positionals, and controlling whether abbreviations are allowed or not. I don't recall any others dealing with strings that contain '=' or space. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 23:45:27 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 22 Sep 2014 21:45:27 +0000 Subject: [issue21431] 3.4.1rc1 test_pydoc fails: pydoc_data.topics.topics values are type "bytes" not "str" In-Reply-To: <1399234251.1.0.221071278299.issue21431@psf.upfronthosting.co.za> Message-ID: <20140922214510.111909.23907@mail.hg.python.org> Roundup Robot added the comment: New changeset 1248796b7945 by Ned Deily in branch 'default': Issue #21431: merge from 3.4 https://hg.python.org/cpython/rev/1248796b7945 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 22 23:48:24 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 22 Sep 2014 21:48:24 +0000 Subject: [issue21431] 3.4.1rc1 test_pydoc fails: pydoc_data.topics.topics values are type "bytes" not "str" In-Reply-To: <1399234251.1.0.221071278299.issue21431@psf.upfronthosting.co.za> Message-ID: <1411422504.3.0.398232986342.issue21431@psf.upfronthosting.co.za> Ned Deily added the comment: To expedite matters, I did the almost-null post-release cleanup merge and then merged the fix for this issue. So I think this issue is now complete. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 00:11:31 2014 From: report at bugs.python.org (Larry Hastings) Date: Mon, 22 Sep 2014 22:11:31 +0000 Subject: [issue21431] 3.4.1rc1 test_pydoc fails: pydoc_data.topics.topics values are type "bytes" not "str" In-Reply-To: <1399234251.1.0.221071278299.issue21431@psf.upfronthosting.co.za> Message-ID: <1411423891.92.0.703285712214.issue21431@psf.upfronthosting.co.za> Larry Hastings added the comment: If this is fixed, then how come I hit it again today? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 00:12:21 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 22 Sep 2014 22:12:21 +0000 Subject: [issue21431] 3.4.1rc1 test_pydoc fails: pydoc_data.topics.topics values are type "bytes" not "str" In-Reply-To: <1399234251.1.0.221071278299.issue21431@psf.upfronthosting.co.za> Message-ID: <1411423941.39.0.134109463507.issue21431@psf.upfronthosting.co.za> Ned Deily added the comment: It was just fixed today, after the release. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 00:21:09 2014 From: report at bugs.python.org (Larry Hastings) Date: Mon, 22 Sep 2014 22:21:09 +0000 Subject: [issue21431] 3.4.1rc1 test_pydoc fails: pydoc_data.topics.topics values are type "bytes" not "str" In-Reply-To: <1399234251.1.0.221071278299.issue21431@psf.upfronthosting.co.za> Message-ID: <1411424469.28.0.10083039576.issue21431@psf.upfronthosting.co.za> Larry Hastings added the comment: Oh, because it was only fixed today. As Emily Litella used to say... never mind! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 00:29:25 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 22 Sep 2014 22:29:25 +0000 Subject: [issue22396] AIX posix_fadvise and posix_fallocate In-Reply-To: <1410546003.27.0.984640019214.issue22396@psf.upfronthosting.co.za> Message-ID: <1411424965.15.0.256596428268.issue22396@psf.upfronthosting.co.za> STINNER Victor added the comment: 10812_aix.patch just hides the problem. I understand that AIX doesn't declare the function prototype correctly? I would prefer to disable the function in the posix module (don't declare it) if it's the case. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 00:35:01 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 22 Sep 2014 22:35:01 +0000 Subject: [issue22396] AIX posix_fadvise and posix_fallocate In-Reply-To: <1410546003.27.0.984640019214.issue22396@psf.upfronthosting.co.za> Message-ID: <1411425301.85.0.142130774875.issue22396@psf.upfronthosting.co.za> STINNER Victor added the comment: > I understand that AIX doesn't declare the function prototype correctly? AIX bug report: http://www-01.ibm.com/support/docview.wss?uid=isg1IV56170 I like Ruby's patch: -#ifdef HAVE_POSIX_FADVISE + /* AIX currently does not support a 32-bit call to posix_fadvise() + * if _LARGE_FILES is defined. + */ +#if defined(HAVE_POSIX_FADVISE) && !(defined(_AIX) && defined(_LARGE_FILES) && !defined(_ARCH_PPC64)) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 02:29:05 2014 From: report at bugs.python.org (Robert Collins) Date: Tue, 23 Sep 2014 00:29:05 +0000 Subject: [issue19746] No introspective way to detect ModuleImportFailure in unittest In-Reply-To: <1385262963.63.0.210713286499.issue19746@psf.upfronthosting.co.za> Message-ID: <1411432145.39.0.51883534012.issue19746@psf.upfronthosting.co.za> Robert Collins added the comment: I can certainly write the reporter glue to work with either a string or a full reference. Note that the existing late-reporting glue captures the import error into a string, and then raises an exception containing that string - so what I've done is consistent with that. As for why the original code is like that - well I've had plenty of bad experiences with memory loops due to objects held in stack frames of exceptions, I don't like to keep long lived references to them, and I wager Michael has had the same experience. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 03:47:55 2014 From: report at bugs.python.org (Khalid) Date: Tue, 23 Sep 2014 01:47:55 +0000 Subject: [issue22466] problem with installing python 2.7.8 Message-ID: <1411436875.43.0.487980102228.issue22466@psf.upfronthosting.co.za> New submission from Khalid: when I'm installing python 2.7.8 I get error "there is a problem with this windows installer package. a DLL required for this install to complete could not be run". I'm using windows 8.1 64bit ---------- components: Installation files: Capture.JPG messages: 227319 nosy: elctr0 priority: normal severity: normal status: open title: problem with installing python 2.7.8 type: compile error versions: Python 2.7 Added file: http://bugs.python.org/file36693/Capture.JPG _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 03:51:57 2014 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 23 Sep 2014 01:51:57 +0000 Subject: [issue22466] problem with installing python 2.7.8 In-Reply-To: <1411436875.43.0.487980102228.issue22466@psf.upfronthosting.co.za> Message-ID: <1411437117.06.0.758333957061.issue22466@psf.upfronthosting.co.za> Eric V. Smith added the comment: Where did you download the installer from? How are you running the installer? ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 03:58:27 2014 From: report at bugs.python.org (Case Van Horsen) Date: Tue, 23 Sep 2014 01:58:27 +0000 Subject: [issue22198] Odd floor-division corner case In-Reply-To: <1408034861.79.0.503776123394.issue22198@psf.upfronthosting.co.za> Message-ID: <1411437507.73.0.876676930608.issue22198@psf.upfronthosting.co.za> Changes by Case Van Horsen : ---------- nosy: +casevh _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 04:00:01 2014 From: report at bugs.python.org (Khalid) Date: Tue, 23 Sep 2014 02:00:01 +0000 Subject: [issue22466] problem with installing python 2.7.8 In-Reply-To: <1411437117.06.0.758333957061.issue22466@psf.upfronthosting.co.za> Message-ID: Khalid added the comment: Downloaded from official website & I run it by simply double click. by the way there is no run as admin On Sep 23, 2014 4:51 AM, "Eric V. Smith" wrote: > > Eric V. Smith added the comment: > > Where did you download the installer from? > > How are you running the installer? > > ---------- > nosy: +eric.smith > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 04:22:33 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 23 Sep 2014 02:22:33 +0000 Subject: [issue22461] Test failure: Lib/test/test_pydoc.py line 851, "topic?key=def" In-Reply-To: <1411391657.7.0.939727555746.issue22461@psf.upfronthosting.co.za> Message-ID: <1411438953.65.0.852769510724.issue22461@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: needs patch -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 04:31:54 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 23 Sep 2014 02:31:54 +0000 Subject: [issue22459] str.strip() documentation: wrong example In-Reply-To: <1411374730.07.0.0715795458179.issue22459@psf.upfronthosting.co.za> Message-ID: <1411439514.32.0.74948708165.issue22459@psf.upfronthosting.co.za> Josh Rosenberg added the comment: LGTM. About a straightforward as it gets. ---------- nosy: +josh.rosenberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 04:44:44 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 23 Sep 2014 02:44:44 +0000 Subject: [issue22459] str.strip() documentation: wrong example In-Reply-To: <1411374730.07.0.0715795458179.issue22459@psf.upfronthosting.co.za> Message-ID: <20140923024436.50574.92846@mail.hg.python.org> Roundup Robot added the comment: New changeset 8eb4eec8626c by Benjamin Peterson in branch '3.4': fix error in split() examples (closes #22459) https://hg.python.org/cpython/rev/8eb4eec8626c New changeset 6dcc96fa3970 by Benjamin Peterson in branch 'default': merge 3.4 (#22459) https://hg.python.org/cpython/rev/6dcc96fa3970 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 07:20:15 2014 From: report at bugs.python.org (DS6) Date: Tue, 23 Sep 2014 05:20:15 +0000 Subject: [issue22467] Lib/http/server.py, inconsistent header casing Message-ID: <1411449615.3.0.851782925938.issue22467@psf.upfronthosting.co.za> New submission from DS6: Inconsistent casing, such as "Content-type" vs "Content-Type", "Content-Length" vs "Content-length", while technically not breaking any RFC or other HTTP-related rules (headers are case-insensitive, after all), can occasionally cause problems when attempting to retrieve already-set headers from http.server.BaseHTTPRequestHandler._headers_buffer (in my situation specifically, trying to retrie the Content-Type header in the sendfile method in an extended BaseHTTPRequestHandler class). This happens a lot in the file and I wouldn't be surprised if the problem were to crop up in other places as well. I'm a new user of Python, so despite having searched for an answer to this problem, if there's a case-insensitive way to obtain items from a list and I'm just daft, please feel free to point me in the right direction, though I feel that the casing should be corrected regardless for consistency and optimization sake. (Aside: I would try to publish a patch along with this issue report with the casing issues fixed, but I'm not too knowledgeable about versioning and stuff and would have no idea where to start.) ---------- components: Library (Lib) messages: 227324 nosy: DS6 priority: normal severity: normal status: open title: Lib/http/server.py, inconsistent header casing versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 07:24:25 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 23 Sep 2014 05:24:25 +0000 Subject: [issue22467] Lib/http/server.py, inconsistent header casing In-Reply-To: <1411449615.3.0.851782925938.issue22467@psf.upfronthosting.co.za> Message-ID: <1411449865.58.0.508561170156.issue22467@psf.upfronthosting.co.za> Senthil Kumaran added the comment: First thing (and the easiest is), if you find inconsistent casing in http/server.py itself, then make it consistent in your patch against cpython default branch (from hg.python.org). Make it Content-Length and Content-Type in your patch. Next part is while receiving the request with these headers, the client and server should store it in case-insensitive dict (there is open request and patch, which can churn up again and we can fix it as part of that issue). ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 07:34:35 2014 From: report at bugs.python.org (DS6) Date: Tue, 23 Sep 2014 05:34:35 +0000 Subject: [issue22467] Lib/http/server.py, inconsistent header casing In-Reply-To: <1411449615.3.0.851782925938.issue22467@psf.upfronthosting.co.za> Message-ID: <1411450475.03.0.423988822759.issue22467@psf.upfronthosting.co.za> DS6 added the comment: Erp, *retrieve, and I meant copyfile, not sendfile. I'm tired. Very quick reply, by the way. I suppose I forgot to mention that _headers_buffer is for sending headers, not for receiving them. As far as I can read, the received header information is already case-insensitive, due to email.message.Message being used. It also occurs to me that the _headers_buffer field probably wasn't designed to be directly accessed, seeing as how it's usually flushed immediately after being modified... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 08:46:35 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 23 Sep 2014 06:46:35 +0000 Subject: [issue22464] Speed up fractions implementation In-Reply-To: <1411407434.75.0.285038516488.issue22464@psf.upfronthosting.co.za> Message-ID: <1411454795.2.0.602384532704.issue22464@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 10:29:23 2014 From: report at bugs.python.org (Robert Collins) Date: Tue, 23 Sep 2014 08:29:23 +0000 Subject: [issue22457] load_tests not invoked in root __init__.py when start=package root In-Reply-To: <1411357674.43.0.0204872118136.issue22457@psf.upfronthosting.co.za> Message-ID: <1411460963.09.0.214398741254.issue22457@psf.upfronthosting.co.za> Robert Collins added the comment: This should fix this issue :) ---------- keywords: +patch Added file: http://bugs.python.org/file36694/issue22457.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 10:49:52 2014 From: report at bugs.python.org (Bart Olsthoorn) Date: Tue, 23 Sep 2014 08:49:52 +0000 Subject: [issue22468] Tarfile using fstat on GZip file object Message-ID: <1411462192.65.0.458428981621.issue22468@psf.upfronthosting.co.za> New submission from Bart Olsthoorn: CPython tarfile `gettarinfo` method uses fstat to determine the size of a file (using its fileobject). When that file object is actually created with Gzip.open (so a GZipfile), it will get the compressed size of the file. The addfile method will then continue to read the uncompressed data of the gzipped file, but will read too few bytes, resulting in a tar of incomplete files. I suggest checking the file object class before using fstat to determine the size, and raise a warning if it's a gzip file. To clarify, this only happens when adding a GZip file object to tar. I know that it's not a really common scenario, and the problem is really that GZip file size can only properly be determined by uncompressing and reading it entirely, but I think it's nice to not fail without warning. So this is an example that is failing: ``` import tarfile c = io.BytesIO() with tarfile.open(mode='w', fileobj=c) as tar: for textfile in ['1.txt.gz', '2.txt.gz']: with gzip.open(textfile) as f: tarinfo = tar.gettarinfo(fileobj=f) tar.addfile(tarinfo=tarinfo, fileobj=f) data = c.getvalue() return data ``` Instead this reads the proper filesize and writes the files to a tar: ``` import tarfile c = io.BytesIO() with tarfile.open(mode='w', fileobj=c) as tar: for textfile in ['1.txt.gz', '2.txt.gz']: with gzip.open(textfile) as f: buff = f.read() tarinfo = tarfile.TarInfo(name=f.name) tarinfo.size = len(buff) tar.addfile(tarinfo=tarinfo, fileobj=io.BytesIO(buff)) data = c.getvalue() return data ``` ---------- messages: 227328 nosy: bartolsthoorn priority: normal severity: normal status: open title: Tarfile using fstat on GZip file object type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 10:52:46 2014 From: report at bugs.python.org (Stefan Champailler) Date: Tue, 23 Sep 2014 08:52:46 +0000 Subject: [issue1602] windows console doesn't print or input Unicode In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za> Message-ID: <1411462366.52.0.0987454406769.issue1602@psf.upfronthosting.co.za> Stefan Champailler added the comment: I don't know if this is 100% related, but here I go. Here's a session in a windows console (cmd.exe) : Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\Users\stc>chcp 65001 Active code page: 65001 C:\Users\stc>\PORT-STCA2\opt\python3\python Python 3.4.1 (v3.4.1:c0e311e010fc, May 18 2014, 10:38:22) [MSC v.1600 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> print '?' C:\Users\stc> So basically, the python interpreters just quits without any message. Windows doesn't comply about python crashing though... Best regards, Stefan ---------- nosy: +wiz21 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 11:07:02 2014 From: report at bugs.python.org (Stefan Champailler) Date: Tue, 23 Sep 2014 09:07:02 +0000 Subject: [issue1602] windows console doesn't print or input Unicode In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za> Message-ID: <1411463222.4.0.765924487186.issue1602@psf.upfronthosting.co.za> Stefan Champailler added the comment: In my previous comment, I've shown : print '?' which is not valid python 3.4.1 (don't why the interpreter didn't complaing though). So I tested again with missing parenthesis added : C:\PORT-STCA2\pl-PRIVATE\horse>chcp 65001 Active code page: 65001 C:\PORT-STCA2\pl-PRIVATE\horse>python Python 3.4.1 (v3.4.1:c0e311e010fc, May 18 2014, 10:38:22) [MSC v.1600 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> print("?") C:\PORT-STCA2\pl-PRIVATE\horse>echo %PROCESSOR_IDENTIFIER% Intel64 Family 6 Model 42 Stepping 7, GenuineIntel Exactly the same behaviour. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 11:11:59 2014 From: report at bugs.python.org (Robert Collins) Date: Tue, 23 Sep 2014 09:11:59 +0000 Subject: [issue16662] load_tests not invoked in package/__init__.py In-Reply-To: <1355217291.85.0.41912767842.issue16662@psf.upfronthosting.co.za> Message-ID: <1411463519.55.0.190970884929.issue16662@psf.upfronthosting.co.za> Robert Collins added the comment: I've managed to get a windows setup working. Its my mini-vfs which needs to be Windows aware (because the abs path of /foo is C:\\foo). I'll work up a patch tomorrowish. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 11:22:11 2014 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 23 Sep 2014 09:22:11 +0000 Subject: [issue1602] windows console doesn't print or input Unicode In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za> Message-ID: <1411464131.84.0.593110453427.issue1602@psf.upfronthosting.co.za> Nick Coghlan added the comment: Drekin, it would be good to be able to incorporate some of your improvements for Python 3.5. Before we could do that, we'd need to review and agree to the PSF Contributor Agreement at https://www.python.org/psf/contrib/contrib-form/ The underlying licensing situation for CPython is a little messy (albeit in a way that doesn't impact users or redistributors), so we use the contributor agreement to ensure we continue to have the right to distribute Python under its current license without making the history any messier, and to preserve the option of switching to a simpler standard license at some point in the future (if it ever becomes feasible to do so). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 11:35:53 2014 From: report at bugs.python.org (Drekin) Date: Tue, 23 Sep 2014 09:35:53 +0000 Subject: [issue1602] windows console doesn't print or input Unicode In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za> Message-ID: <1411464953.71.0.110373054928.issue1602@psf.upfronthosting.co.za> Drekin added the comment: Stefan Champailler: The crash you see is maybe not a crash at all. First it has nothing to do with printing, the problem is reading of your input line. That explains why Python exited even before printing the traceback of the SyntaxError. If you try to read input using `sys.stdin.buffer.raw.read(100)` and type Unicode characters, it returns just empty bytes `b''`. So maybe Python REPL then thinks the input just ended and so standardly exits the interpreter. Why are you using chcp 65001? As far as I know, it doesn't give you the ability to use Unicode in the console. It somehow helps with printing, but there are some issues. `print("\N{euro sign}")` prints the right character, but it prints additional blank line. `sys.stdout.write("\N{euro sign}")` and `sys.stdout.buffer.write("\N{euro sign}".encode("cp65001"))` does the same, but `sys.stdout.buffer.raw.write("\N{euro sign}".encode("cp65001"))` works as expected. If you want to enter and display Unicode in Python on Windows console, try my package `win_unicode_console`, which tries to solve the issues. See https://pypi.python.org/pypi/win_unicode_console. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 11:42:32 2014 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 23 Sep 2014 09:42:32 +0000 Subject: [issue22166] test_codecs leaks references In-Reply-To: <1407444567.64.0.0425446064781.issue22166@psf.upfronthosting.co.za> Message-ID: <1411465352.3.0.186901339167.issue22166@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- assignee: -> ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 11:59:43 2014 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 23 Sep 2014 09:59:43 +0000 Subject: [issue18814] Add codecs.convert_surrogateescape to "clean" surrogate escaped strings In-Reply-To: <1377230552.02.0.907422956718.issue18814@psf.upfronthosting.co.za> Message-ID: <1411466383.8.0.914030075142.issue18814@psf.upfronthosting.co.za> Nick Coghlan added the comment: Updated issue title to reflect current proposal. ---------- title: Add tools for "cleaning" surrogate escaped strings -> Add codecs.convert_surrogateescape to "clean" surrogate escaped strings _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 12:00:24 2014 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 23 Sep 2014 10:00:24 +0000 Subject: [issue9951] introduce bytes.hex method (also for bytearray and memoryview) In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za> Message-ID: <1411466424.53.0.808720964145.issue9951@psf.upfronthosting.co.za> Nick Coghlan added the comment: Updated issue title to indicate proposal also covers bytearray and memoryview. ---------- title: introduce bytes.hex method -> introduce bytes.hex method (also for bytearray and memoryview) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 12:01:34 2014 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 23 Sep 2014 10:01:34 +0000 Subject: [issue22264] Add wsgiref.util.dump_wsgistr & load_wsgistr In-Reply-To: <1408884341.89.0.273491669506.issue22264@psf.upfronthosting.co.za> Message-ID: <1411466494.79.0.834314071024.issue22264@psf.upfronthosting.co.za> Nick Coghlan added the comment: Updated issue title to reflect current proposal ---------- title: Add wsgiref.util helpers for dealing with "WSGI strings" -> Add wsgiref.util.dump_wsgistr & load_wsgistr _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 12:11:59 2014 From: report at bugs.python.org (Drekin) Date: Tue, 23 Sep 2014 10:11:59 +0000 Subject: [issue1602] windows console doesn't print or input Unicode In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za> Message-ID: <1411467119.93.0.573373356232.issue1602@psf.upfronthosting.co.za> Drekin added the comment: Nick Coghlan: Ok, done. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 12:21:44 2014 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 23 Sep 2014 10:21:44 +0000 Subject: [issue1602] windows console doesn't print or input Unicode In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za> Message-ID: <1411467704.64.0.886267396099.issue1602@psf.upfronthosting.co.za> Nick Coghlan added the comment: Drekin: thanks! That should get processed by the PSF Secretary before too long, and the "*" to indicate you have signed it will appear by your name. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 12:39:50 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 23 Sep 2014 10:39:50 +0000 Subject: [issue18814] Add codecs.convert_surrogateescape to "clean" surrogate escaped strings In-Reply-To: <1411466383.8.0.914030075142.issue18814@psf.upfronthosting.co.za> Message-ID: <54214DF3.8020808@egenix.com> Marc-Andre Lemburg added the comment: Don't like the function name :-) How about codecs.filter_non_utf8_data(), since that's closer to what the function is really doing and doesn't require knowledge about what "surrogateescape" is. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 12:51:12 2014 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 23 Sep 2014 10:51:12 +0000 Subject: [issue18814] Add codecs.convert_surrogateescape to "clean" surrogate escaped strings In-Reply-To: <1377230552.02.0.907422956718.issue18814@psf.upfronthosting.co.za> Message-ID: <1411469472.48.0.611257291181.issue18814@psf.upfronthosting.co.za> Nick Coghlan added the comment: The error handler is called "surrogateescape". That means "convert_surrogateescape" is always only a single step away from thinking "I want to remove the smuggled bytes from a surrogateescape'd string", without needing to assume any knowledge on the part of the user other than the name of the error handler and the fact that it is used to smuggle arbitrary bytes through the Python 3 str type. Getting from "this string was decoded with the surrogateescape handler and may contain smuggled bytes" to "filter_non_utf8_data" as the relevant cleanup function is a much bigger leap that requires more assumed knowledge on the part of the user, and also one that confuses the conceptual purpose of the function (cleaning up the output of the surrogateescape error handler to ensure it is a pure Unicode string) with the internal details of the proposed approach to implementing that cleanup operation (encoding to UTF-8 with surrogateescape, and then decoding again with a different error handler). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 12:57:54 2014 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 23 Sep 2014 10:57:54 +0000 Subject: [issue18814] Add codecs.convert_surrogateescape to "clean" surrogate escaped strings In-Reply-To: <1377230552.02.0.907422956718.issue18814@psf.upfronthosting.co.za> Message-ID: <1411469874.84.0.592893563163.issue18814@psf.upfronthosting.co.za> Nick Coghlan added the comment: The function definition again, this time with a draft docstring: def convert_surrogateescape(data, errors='replace'): """Convert escaped raw bytes by applying a different error handler Uses the "replace" error handler by default, but any input error handler may be specified. """ return data.encode('utf-8', 'surrogateescape').decode('utf-8', errors) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 13:00:44 2014 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 23 Sep 2014 11:00:44 +0000 Subject: [issue18814] Add codecs.convert_surrogateescape to "clean" surrogate escaped strings In-Reply-To: <1377230552.02.0.907422956718.issue18814@psf.upfronthosting.co.za> Message-ID: <1411470044.07.0.398731960244.issue18814@psf.upfronthosting.co.za> Nick Coghlan added the comment: Note I would also be OK with "convert_surrogates", as that's the term that appears in the relevant error message: >>> b'\xe9'.decode('ascii', 'surrogateescape').encode() Traceback (most recent call last): File "", line 1, in UnicodeEncodeError: 'utf-8' codec can't encode character '\udce9' in position 0: surrogates not allowed ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 13:04:47 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 23 Sep 2014 11:04:47 +0000 Subject: [issue18814] Add codecs.convert_surrogateescape to "clean" surrogate escaped strings In-Reply-To: <1411469874.84.0.592893563163.issue18814@psf.upfronthosting.co.za> Message-ID: <542153CB.9060409@free.fr> Antoine Pitrou added the comment: Le 23/09/2014 12:57, Nick Coghlan a ?crit : > The function definition again, this time with a draft docstring: > > def convert_surrogateescape(data, errors='replace'): > """Convert escaped raw bytes by applying a different error handler > > Uses the "replace" error handler by default, but any input > error handler may be specified. > """ > return data.encode('utf-8', 'surrogateescape').decode('utf-8', errors) 'utf-8' is hardcoded? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 13:12:04 2014 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 23 Sep 2014 11:12:04 +0000 Subject: [issue18814] Add codecs.convert_surrogateescape to "clean" surrogate escaped strings In-Reply-To: <1377230552.02.0.907422956718.issue18814@psf.upfronthosting.co.za> Message-ID: <1411470724.13.0.309067671367.issue18814@psf.upfronthosting.co.za> Nick Coghlan added the comment: Draft docstring for that version def convert_surrogates(data, errors='replace'): """Convert escaped surrogates by applying a different error handler Uses the "replace" error handler by default, but any input error handler may be specified. """ return data.encode('utf-8', 'surrogateescape').decode('utf-8', errors) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 13:13:12 2014 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 23 Sep 2014 11:13:12 +0000 Subject: [issue18814] Add codecs.convert_surrogateescape to "clean" surrogate escaped strings In-Reply-To: <1377230552.02.0.907422956718.issue18814@psf.upfronthosting.co.za> Message-ID: <1411470792.88.0.916078346668.issue18814@psf.upfronthosting.co.za> Nick Coghlan added the comment: Antoine: what would be the use case for using a different encoding for the temporary bytes object? It's discarded anyway, so the encoding used isn't externally visible. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 13:23:47 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 23 Sep 2014 11:23:47 +0000 Subject: [issue18814] Add codecs.convert_surrogateescape to "clean" surrogate escaped strings In-Reply-To: <1377230552.02.0.907422956718.issue18814@psf.upfronthosting.co.za> Message-ID: <1411471427.31.0.791719184051.issue18814@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The encoding used impacts the result: >>> s = 'abc\udcc3\udca9' >>> s.encode('ascii', 'surrogateescape').decode('ascii', 'replace') 'abc??' >>> s.encode('utf-8', 'surrogateescape').decode('utf-8', 'replace') 'abc?' The original string ('abc\udcc3\udca9') was obtained by decoding a valid utf-8 string with the 'ascii' codec and the 'surrogateescape' error handler. If anything, the default encoding should probably be sys.getfilesystemencoding(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 13:26:14 2014 From: report at bugs.python.org (Stefan Champailler) Date: Tue, 23 Sep 2014 11:26:14 +0000 Subject: [issue1602] windows console doesn't print or input Unicode In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za> Message-ID: <1411471574.18.0.191862508848.issue1602@psf.upfronthosting.co.za> Stefan Champailler added the comment: Dear Drekin, > The crash you see is maybe not a crash at all. First it has nothing > to do with printing, the problem is reading of your input line. I guessed that, but thanks for pointing out. > So maybe Python REPL then thinks the input just ended and so standardly exits the interpreter. Yes. I have showed that because the line of code seemed perfectly valid and innocuous (I moved to Python3 because I *need* good unicode/encodings support). The answer from the REPL is, to me, very suprising. I would have expected a badly displayed character at least and a syntax error at worst. I consider myself quite aware of unicode issues but without any output from the repl, I'd have very hard times figuring out what went wrong, hence my bug report. So even though this might not qualify as the worse bug in Python, I'd say it is actually quite misleading. But see no complaint here, I'm very happy with Python in general. It's just that I thought I had to tell it to the dev team. > Why are you using chcp 65001? I thought it'd help me with printing unicode (I tried CP437 but problem is the EURO sign is not there, and I *do* need eurosign :-)). But I'll readily admit I didn't read all the stuff about encoing issues on Windows console before trying. >try my package `win_unicode_console`, which tries to solve the issues. I'll certainly do that. Thank you for your answer Stefan ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 13:44:35 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 23 Sep 2014 11:44:35 +0000 Subject: [issue22385] Define a binary output formatting mini-language for *.hex() In-Reply-To: <1410393301.25.0.193851592698.issue22385@psf.upfronthosting.co.za> Message-ID: <1411472675.4.0.793398434151.issue22385@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 13:44:44 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 23 Sep 2014 11:44:44 +0000 Subject: [issue9951] introduce bytes.hex method (also for bytearray and memoryview) In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za> Message-ID: <1411472684.96.0.90918851446.issue9951@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 14:06:37 2014 From: report at bugs.python.org (karl) Date: Tue, 23 Sep 2014 12:06:37 +0000 Subject: [issue5550] [urllib.request]: Comparison of HTTP headers should be insensitive to the case In-Reply-To: <1237870141.83.0.616869799184.issue5550@psf.upfronthosting.co.za> Message-ID: <1411473997.03.0.478543549018.issue5550@psf.upfronthosting.co.za> karl added the comment: Ok this is an attempt at solving the issue with lowercase. I find my get_header a bit complicated, but if you have a better idea. :) I'll modify the patches. I have try to run the tests on the mac here but I have an issue currently. ? ./python.exe -V Python 3.5.0a0 Traceback (most recent call last): File "./Tools/scripts/patchcheck.py", line 6, in import subprocess File "/Users/karl/code/cpython/Lib/subprocess.py", line 353, in import signal ImportError: No module named 'signal' make: *** [patchcheck] Error 1 ---------- Added file: http://bugs.python.org/file36695/issue-5550-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 14:22:22 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 23 Sep 2014 12:22:22 +0000 Subject: [issue22469] Allow the "backslashreplace" error handler support decoding Message-ID: <1411474942.45.0.419383976358.issue22469@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch allows the "backslashreplace" error handler to be used not only in encoding, but in decoding and translating. ---------- components: Extension Modules files: backslashreplace_decode.patch keywords: patch messages: 227349 nosy: doerwalter, lemburg, ncoghlan, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Allow the "backslashreplace" error handler support decoding type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file36696/backslashreplace_decode.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 14:26:23 2014 From: report at bugs.python.org (Erik Cederstrand) Date: Tue, 23 Sep 2014 12:26:23 +0000 Subject: [issue12006] strptime should implement %V or %u directive from libc In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za> Message-ID: <1411475183.19.0.337220774047.issue12006@psf.upfronthosting.co.za> Erik Cederstrand added the comment: Well, it's an ambiguous situation, as established earlier. I'm not sure what the policy is wrt. foot-shooting, but I'd opt to fail if %G, %V and %u are not used together. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 14:26:46 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 23 Sep 2014 12:26:46 +0000 Subject: [issue22469] Allow the "backslashreplace" error handler support decoding In-Reply-To: <1411474942.45.0.419383976358.issue22469@psf.upfronthosting.co.za> Message-ID: <1411475206.72.0.939595602658.issue22469@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Oh sorry, there is already opened issue22469. ---------- resolution: -> duplicate stage: patch review -> resolved status: open -> closed superseder: -> Allow the "backslashreplace" error handler support decoding _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 14:27:37 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 23 Sep 2014 12:27:37 +0000 Subject: [issue22286] Allow backslashreplace error handler to be used on input In-Reply-To: <1409136620.65.0.397738586583.issue22286@psf.upfronthosting.co.za> Message-ID: <1411475257.36.0.72509518754.issue22286@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch. ---------- components: +Extension Modules keywords: +patch nosy: +serhiy.storchaka stage: needs patch -> patch review Added file: http://bugs.python.org/file36697/backslashreplace_decode.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 14:28:37 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 23 Sep 2014 12:28:37 +0000 Subject: [issue22469] Allow the "backslashreplace" error handler support decoding In-Reply-To: <1411474942.45.0.419383976358.issue22469@psf.upfronthosting.co.za> Message-ID: <1411475317.98.0.86098946787.issue22469@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- superseder: Allow the "backslashreplace" error handler support decoding -> Allow backslashreplace error handler to be used on input _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 14:46:53 2014 From: report at bugs.python.org (karl) Date: Tue, 23 Sep 2014 12:46:53 +0000 Subject: [issue5550] [urllib.request]: Comparison of HTTP headers should be insensitive to the case In-Reply-To: <1237870141.83.0.616869799184.issue5550@psf.upfronthosting.co.za> Message-ID: <1411476413.92.0.68518976413.issue5550@psf.upfronthosting.co.za> Changes by karl : Removed file: http://bugs.python.org/file36695/issue-5550-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 14:47:41 2014 From: report at bugs.python.org (karl) Date: Tue, 23 Sep 2014 12:47:41 +0000 Subject: [issue5550] [urllib.request]: Comparison of HTTP headers should be insensitive to the case In-Reply-To: <1237870141.83.0.616869799184.issue5550@psf.upfronthosting.co.za> Message-ID: <1411476461.52.0.0141485048765.issue5550@psf.upfronthosting.co.za> karl added the comment: And I had to do a typo in patch3. Submitting patch4. Sorry about that. ---------- Added file: http://bugs.python.org/file36698/issue-5550-4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 14:54:40 2014 From: report at bugs.python.org (Mark Hammond) Date: Tue, 23 Sep 2014 12:54:40 +0000 Subject: [issue1602] windows console doesn't print or input Unicode In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za> Message-ID: <1411476880.91.0.155291928404.issue1602@psf.upfronthosting.co.za> Mark Hammond added the comment: > The crash you see is maybe not a crash at all. I'd call it a "crash" - the repl shouldn't exit. But it's not necessarily part of *this* bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 15:25:57 2014 From: report at bugs.python.org (David Edelsohn) Date: Tue, 23 Sep 2014 13:25:57 +0000 Subject: [issue22396] AIX posix_fadvise and posix_fallocate In-Reply-To: <1410546003.27.0.984640019214.issue22396@psf.upfronthosting.co.za> Message-ID: <1411478757.07.0.220721634559.issue22396@psf.upfronthosting.co.za> David Edelsohn added the comment: Attached is a revised patch that disables posix_fadvise() and posix_fallocate() when building on 32 bit AIX with _LARGE_FILES defined. ---------- Added file: http://bugs.python.org/file36699/22396_aix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 15:32:57 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 23 Sep 2014 13:32:57 +0000 Subject: [issue22396] AIX posix_fadvise and posix_fallocate In-Reply-To: <1410546003.27.0.984640019214.issue22396@psf.upfronthosting.co.za> Message-ID: <1411479177.58.0.220430355627.issue22396@psf.upfronthosting.co.za> STINNER Victor added the comment: > Attached is a revised patch that disables posix_fadvise() and posix_fallocate() when building on 32 bit AIX with _LARGE_FILES defined. Good. You should add a reference to this issue, something like "Issue #22396: ...". To avoid code duplication, you may write something like: /* Issue #22396: AIX currently does not support a 32-bit call to posix_fallocate() if _LARGE_FILES is defined. */ #if defined(HAVE_POSIX_FALLOCATE) && !(defined(_AIX) && defined(_LARGE_FILES) && !defined(__64BIT__)) # undef HAVE_POSIX_FALLOCATE #endif or "#define BROKEN_POSIX_FALLOCATE". Which Python versions should be patched? 3.4 and 3.5? Python 2.7 doesn't have the function (introduced in Python 3.3). For Python 3.4, it means that between two Python minor versions, the function disappears on AIX 32-bit :-/ Is it a problem since the function didn't work on this platform? (always fail with EINVAL) I suggest to patch 3.4 and 3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 15:44:07 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 23 Sep 2014 13:44:07 +0000 Subject: [issue22396] AIX posix_fadvise and posix_fallocate In-Reply-To: <1410546003.27.0.984640019214.issue22396@psf.upfronthosting.co.za> Message-ID: <1411479847.87.0.738904048728.issue22396@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think that some time AIX bug will be fixed. May be it would be better to introduce special macros, and set it in the configure script (similar to HAVE_GLIBC_MEMMOVE_BUG or HAVE_IPA_PURE_CONST_BUG). Or may be just udefine HAVE_POSIX_FADVISE at such circumstances. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 15:48:31 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 23 Sep 2014 13:48:31 +0000 Subject: [issue22396] AIX posix_fadvise and posix_fallocate In-Reply-To: <1410546003.27.0.984640019214.issue22396@psf.upfronthosting.co.za> Message-ID: <1411480111.87.0.139560064171.issue22396@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Or can we simply keep the function and skip the test? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 15:56:42 2014 From: report at bugs.python.org (David Edelsohn) Date: Tue, 23 Sep 2014 13:56:42 +0000 Subject: [issue22396] AIX posix_fadvise and posix_fallocate In-Reply-To: <1410546003.27.0.984640019214.issue22396@psf.upfronthosting.co.za> Message-ID: <1411480602.12.0.814784699989.issue22396@psf.upfronthosting.co.za> David Edelsohn added the comment: The declaration of the two system calls should be fixed in the AIX header, but the clueless response to the AIX problem report is underwhelming. I don't understand the "keep the function and skip the test" suggestion. I thought that was my first patch -- catch the exception of invalid argument and allow it to fail on AIX. If AIX eventually is fixed, the test will pass, no harm, no foul. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 16:26:15 2014 From: report at bugs.python.org (Fumihiro Bessho) Date: Tue, 23 Sep 2014 14:26:15 +0000 Subject: [issue1446619] extended slice behavior inconsistent with docs Message-ID: <1411482375.14.0.56127920348.issue1446619@psf.upfronthosting.co.za> Fumihiro Bessho added the comment: I also wondered the same thing today and found this issue. I've added my comment on the patch to make the change more precise. Can anyone move it ahead and update the document? ---------- nosy: +bessho _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 16:34:06 2014 From: report at bugs.python.org (karl) Date: Tue, 23 Sep 2014 14:34:06 +0000 Subject: [issue17322] urllib.request add_header() currently allows trailing spaces (and other weird stuff) In-Reply-To: <1362086834.26.0.0452612015515.issue17322@psf.upfronthosting.co.za> Message-ID: <1411482846.9.0.173575741981.issue17322@psf.upfronthosting.co.za> karl added the comment: Just a follow up for giving the stable version of the now new RFC version for HTTP 1.1 HTTP header field names parsing http://tools.ietf.org/html/rfc7230#section-3.2.4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 16:50:13 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 23 Sep 2014 14:50:13 +0000 Subject: [issue18814] Add codecs.convert_surrogateescape to "clean" surrogate escaped strings In-Reply-To: <1411470724.13.0.309067671367.issue18814@psf.upfronthosting.co.za> Message-ID: <542188A1.80307@egenix.com> Marc-Andre Lemburg added the comment: On 23.09.2014 13:12, Nick Coghlan wrote: > > Nick Coghlan added the comment: > > Draft docstring for that version > > def convert_surrogates(data, errors='replace'): > """Convert escaped surrogates by applying a different error handler > > Uses the "replace" error handler by default, but any input > error handler may be specified. > """ > return data.encode('utf-8', 'surrogateescape').decode('utf-8', errors) Nick, the doc string is not correct. It is not working on escaped surrogates. Instead it is working on lone surrogates that were used to encode undecodable bytes from some input data. The longer story goes like this: The "surrogateescape" error handler in the .decode() call that lead up to the data you want this function to take as input, will convert undecodable data to lone low surrogates. The function then reverts these bytes back into UTF-8 (which may well not be the original encoding, as Antoine has already pointed out, but that's not really important for the use case), recreating the unencodable bytes and then decodes the result again using the UTF-8 codec using a new error handler. So in summary, the function is supposed to retroactively apply a different error handler to the input data, undoing the effects of the "surrogateescapes" error handler. The name still doesn't match this functionality. BTW: There's a catch in the approach. The encoding used to decode the original data may well be 'ascii'. Now, if the original input data was in fact UTF-8, the input decoding would have mapped the UTF-8 code points to lone surrogates. The above function would then turn these back into UTF-8, redecode and get a completely different string back (since the error handlers would not trigger). I'm not sure whether adding such a small function with so many unclear implications is a good idea. Either it should be made more specific, e.g. be reserved for use on data from input streams with known encoding, or be put into the documentation as example for people to use and adapt as necessary. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 16:55:41 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 23 Sep 2014 14:55:41 +0000 Subject: [issue19746] No introspective way to detect ModuleImportFailure in unittest In-Reply-To: <1385262963.63.0.210713286499.issue19746@psf.upfronthosting.co.za> Message-ID: <1411484141.59.0.494155513791.issue19746@psf.upfronthosting.co.za> R. David Murray added the comment: Oh, ok, if the existing glue does it that way, then it seems fine. I thought when I read the code that it was holding a reference to the traceback until it raised the error in the synthetic test. Or do you mean that when exceptions are raised by tests it is the string that is captured not the exception? That would make sense. So, yeah, I guess capturing the string makes sense, to be consistent with the rest of the reporting. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 17:06:57 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 23 Sep 2014 15:06:57 +0000 Subject: [issue18814] Add codecs.convert_surrogateescape to "clean" surrogate escaped strings In-Reply-To: <1377230552.02.0.907422956718.issue18814@psf.upfronthosting.co.za> Message-ID: <1411484817.56.0.935915060414.issue18814@psf.upfronthosting.co.za> R. David Murray added the comment: And indeed my use case for this has instances of both cases: originally decoded using ASCII and the non-ascii bytes must end up as replaced characters, and originally decoded using utf-8. I'm also not sure that it is worth adding this. If you know what you are doing the solution is obvious, and if you don't know what you are doing you shouldn't be using surrogateescape in the first place :) Now, if there were or there is intended to be a more efficient C level implementation, that answer might be different. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 17:15:19 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 23 Sep 2014 15:15:19 +0000 Subject: [issue18814] Add codecs.convert_surrogateescape to "clean" surrogate escaped strings In-Reply-To: <1377230552.02.0.907422956718.issue18814@psf.upfronthosting.co.za> Message-ID: <1411485319.42.0.0391564295455.issue18814@psf.upfronthosting.co.za> R. David Murray added the comment: Oh, wait, I forgot that the context for this was dealing with unix filenames and/or stdio. So, a function that just uses the fsencoding to do the replace might indeed be appropriate, but in that case should probably live in the os module. os.convert_surrogates? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 17:22:40 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 23 Sep 2014 15:22:40 +0000 Subject: [issue22467] Lib/http/server.py, inconsistent header casing In-Reply-To: <1411449615.3.0.851782925938.issue22467@psf.upfronthosting.co.za> Message-ID: <1411485760.96.0.747027915023.issue22467@psf.upfronthosting.co.za> R. David Murray added the comment: It also has a leading underscore, which means it is a "private" interface and you use it at your own risk. To the extent that there is an actionable issue here, it is a duplicate of issue 12455. email.message already provides case insensitive header retrieval, by the way. ---------- nosy: +r.david.murray resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> urllib2 forces title() on header names, breaking some requests _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 17:32:36 2014 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 23 Sep 2014 15:32:36 +0000 Subject: [issue18814] Add a convert_surrogates function to "clean" surrogate escaped strings In-Reply-To: <1377230552.02.0.907422956718.issue18814@psf.upfronthosting.co.za> Message-ID: <1411486356.01.0.767469246346.issue18814@psf.upfronthosting.co.za> Nick Coghlan added the comment: As RDM noted, avoiding the use of surrogateescape isn't feasible when we do it by default on all OS interfaces (including the standard streams when we detect 'ascii' as the filesystem encoding in 3.5+). This *needs* to be a case that folks can handle without needing to spend years learning about encodings and error handlers first. That means being able to tell them "use this documented function to remove the surrogates" rather than "use this magic incantation that you don't understand, and that other people may not be able to read". I know more about Unicode encodings than the average programmer at this point, yet I still needed to be schooled by true experts in this thread to learn how to solve the problem properly. Look at this as an opportunity to encapsulate that knowledge in executable form, as while the code is short, it is conceptually *very* dense. If there's a dedicated function, then replacing the encode/decode dance with a faster pure C alternative also becomes a future possibility (with only a recipe, there's no opportunity to ever optimise it). With the additional clarification, it is also clear to me that Antoine is correct that the encoding needs to be configurable and should default to the appropriate setting to remove the surrogates from OS provided data. With that change: def convert_surrogates(data, encoding=None, errors='replace'): """Convert escaped surrogates by applying a different error handler If no encoding is given, defaults to sys.getfilesystemencoding() Uses the "replace" error handler by default, but any input error handler may be specified. """ if encoding is None: encoding = sys.getfilesystemencoding() return data.encode(encoding, 'surrogateescape').decode(encoding, errors) Since it's primarily intended for cleaning OS provided data, then I agree os.convert_surrogates() could be a good choice. It would be appropriate to reference it from os.fsdecode() as a way to clean escaped data when the original binary data was no longer available to be decoded again with a different error handler. ---------- title: Add codecs.convert_surrogateescape to "clean" surrogate escaped strings -> Add a convert_surrogates function to "clean" surrogate escaped strings _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 17:34:11 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 23 Sep 2014 15:34:11 +0000 Subject: [issue18814] Add codecs.convert_surrogateescape to "clean" surrogate escaped strings In-Reply-To: <1411471427.31.0.791719184051.issue18814@psf.upfronthosting.co.za> Message-ID: <2696044.LvdtvKWgeT@raxxla> Serhiy Storchaka added the comment: Good catch Antoine! Here is a sample of more complicated implementation. ---------- title: Add a convert_surrogates function to "clean" surrogate escaped strings -> Add codecs.convert_surrogateescape to "clean" surrogate escaped strings Added file: http://bugs.python.org/file36700/convert_surrogates.py _______________________________________ Python tracker _______________________________________ -------------- next part -------------- import codecs import re def convert_surrogates(data, errors='strict'): handler = None p = re.compile('[\ud800-\uefff]+') pos = 0 res = [] while True: m = p.search(data, pos) if m: if handler is None: handler = codecs.lookup_error(errors) res.append(data[pos: m.start()]) repl, pos = handler(UnicodeTranslateError(data, m.start(), m.end(), 'lone surrogates')) res.append(repl) elif pos: res.append(data[pos:]) return ''.join(res) else: return data def convert_surrogateescape(data, errors='strict'): handler = None p = re.compile('[\ud800-\uefff]+') pos = 0 res = [] while True: m = p.search(data, pos) if m: if handler is None: handler = codecs.lookup_error(errors) start = m.start() res.append(data[pos: start]) try: baddata = data[start: m.end()].encode('ascii', 'surrogateescape') except UnicodeEncodeError as err: raise UnicodeTranslateError(data, err.start + start,err.end + start, r'surrogates not in range \ud880-\ud8ff') from None try: repl, pos = handler(UnicodeDecodeError('unicode', baddata, 0, len(baddata), 'lone surrogates')) except UnicodeDecodeError as err: raise UnicodeTranslateError(data, err.start + start, err.end + start, err.reason) from None pos += start res.append(repl) elif pos: res.append(data[pos:]) return ''.join(res) else: return data From report at bugs.python.org Tue Sep 23 17:46:19 2014 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 23 Sep 2014 15:46:19 +0000 Subject: [issue18814] Add codecs.convert_surrogateescape to "clean" surrogate escaped strings In-Reply-To: <1377230552.02.0.907422956718.issue18814@psf.upfronthosting.co.za> Message-ID: <1411487179.98.0.857019027639.issue18814@psf.upfronthosting.co.za> Nick Coghlan added the comment: Ah, Serhiy's approach of avoiding the encode/decode dance entirely is an even better idea - replacing the lone surrogates directly with the output of the alternative error handler avoids any need to worry about the original encoding. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 19:35:51 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 23 Sep 2014 17:35:51 +0000 Subject: [issue22470] Possible integer overflow in error handlers Message-ID: <1411493751.43.0.689535434801.issue22470@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: There are potential integer overflows in error handlers. Here is simple patch which fixes them. ---------- assignee: serhiy.storchaka components: Extension Modules files: codecs_error_hadlers_overflow.patch keywords: patch messages: 227370 nosy: serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Possible integer overflow in error handlers type: behavior versions: Python 2.7, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file36701/codecs_error_hadlers_overflow.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 19:36:22 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 23 Sep 2014 17:36:22 +0000 Subject: [issue22286] Allow backslashreplace error handler to be used on input In-Reply-To: <1409136620.65.0.397738586583.issue22286@psf.upfronthosting.co.za> Message-ID: <1411493782.19.0.828595304308.issue22286@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +Possible integer overflow in error handlers _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 20:00:40 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 23 Sep 2014 18:00:40 +0000 Subject: [issue22455] idna/punycode give wrong results on narrow builds In-Reply-To: <1411337375.42.0.97875155095.issue22455@psf.upfronthosting.co.za> Message-ID: <1411495240.95.0.210916814143.issue22455@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 20:21:16 2014 From: report at bugs.python.org (Ned Deily) Date: Tue, 23 Sep 2014 18:21:16 +0000 Subject: [issue22466] problem with installing python 2.7.8 In-Reply-To: <1411436875.43.0.487980102228.issue22466@psf.upfronthosting.co.za> Message-ID: <1411496476.08.0.42402340325.issue22466@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +steve.dower, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 20:22:37 2014 From: report at bugs.python.org (Ned Deily) Date: Tue, 23 Sep 2014 18:22:37 +0000 Subject: [issue22468] Tarfile using fstat on GZip file object In-Reply-To: <1411462192.65.0.458428981621.issue22468@psf.upfronthosting.co.za> Message-ID: <1411496557.74.0.993034586481.issue22468@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +lars.gustaebel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 20:26:09 2014 From: report at bugs.python.org (Steve Dower) Date: Tue, 23 Sep 2014 18:26:09 +0000 Subject: [issue22466] problem with installing python 2.7.8 In-Reply-To: <1411436875.43.0.487980102228.issue22466@psf.upfronthosting.co.za> Message-ID: <1411496769.98.0.391277720005.issue22466@psf.upfronthosting.co.za> Steve Dower added the comment: Can you try running this command and then post the log file after installation fails: > msiexec /l*vx log.txt /i "" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 20:41:04 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 23 Sep 2014 18:41:04 +0000 Subject: [issue21866] zipfile.ZipFile.close() doesn't respect allowZip64 In-Reply-To: <1403675769.56.0.836465783864.issue21866@psf.upfronthosting.co.za> Message-ID: <20140923184045.50566.79745@mail.hg.python.org> Roundup Robot added the comment: New changeset 8a010ca89094 by Serhiy Storchaka in branch '2.7': Issue #21866: ZipFile.close() no longer writes ZIP64 central directory https://hg.python.org/cpython/rev/8a010ca89094 New changeset 8f25d118ce38 by Serhiy Storchaka in branch '3.4': Issue #21866: ZipFile.close() no longer writes ZIP64 central directory https://hg.python.org/cpython/rev/8f25d118ce38 New changeset d361d2176121 by Serhiy Storchaka in branch 'default': Issue #21866: ZipFile.close() no longer writes ZIP64 central directory https://hg.python.org/cpython/rev/d361d2176121 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 20:47:58 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 23 Sep 2014 18:47:58 +0000 Subject: [issue1602] windows console doesn't print or input Unicode In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za> Message-ID: <1411498078.65.0.304387237607.issue1602@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Stefan, the Idle Shell handles the BMP subset of Unicode quite well. >>> print('?') ? >>> It is superior to the Windows console in other ways too. For instance, cut and paste work normally as for other Windows windows. (cp65001 is know to be buggy and essentially useless. Check the results in any search engine.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 21:04:01 2014 From: report at bugs.python.org (Drekin) Date: Tue, 23 Sep 2014 19:04:01 +0000 Subject: [issue1602] windows console doesn't print or input Unicode In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za> Message-ID: <1411499041.67.0.168242209102.issue1602@psf.upfronthosting.co.za> Drekin added the comment: Idle shell handles Unicode characters well, but one cannot enter them using deadkey combinations. See http://bugs.python.org/issue22408. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 21:29:58 2014 From: report at bugs.python.org (DS6) Date: Tue, 23 Sep 2014 19:29:58 +0000 Subject: [issue22467] Lib/http/server.py, inconsistent header casing In-Reply-To: <1411449615.3.0.851782925938.issue22467@psf.upfronthosting.co.za> Message-ID: <1411500598.93.0.661669128362.issue22467@psf.upfronthosting.co.za> DS6 added the comment: Whoa, I thought " - no selection - " would not change the set values, but I guess I was wrong. I have no idea what I'm doing, sorry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 21:31:40 2014 From: report at bugs.python.org (DS6) Date: Tue, 23 Sep 2014 19:31:40 +0000 Subject: [issue22467] Lib/http/server.py, inconsistent header casing In-Reply-To: <1411449615.3.0.851782925938.issue22467@psf.upfronthosting.co.za> Message-ID: <1411500700.69.0.538402243219.issue22467@psf.upfronthosting.co.za> DS6 added the comment: Yeah, I was aware it's used for getting the request headers. It's strange that it's not used for setting reply headers, though the casing really doesn't cause any problems for the current implementation and really only affects fringe cases like mine and that fellow in issue #12455. I suppose it would simply be wiser to rewrite my own code a bit instead of relying on private fields, since I am actually extending with my own classes instead of wholly relying on the std libs. I appreciate the post, David, I was not aware this issue had been brought up before; I did actually search for related issues but I guess I didn't see that one. Whoa, I thought " - no selection - " would not change the set values, but I guess I was wrong. ...And apparently duplicate messages are pruned. I have no idea what I'm doing, sorry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 21:34:36 2014 From: report at bugs.python.org (DS6) Date: Tue, 23 Sep 2014 19:34:36 +0000 Subject: [issue22467] Lib/http/server.py, inconsistent header casing In-Reply-To: <1411449615.3.0.851782925938.issue22467@psf.upfronthosting.co.za> Message-ID: <1411500876.3.0.845899559323.issue22467@psf.upfronthosting.co.za> DS6 added the comment: Oh... It showed that the message had been created but it really hadn't, because I had the Status field set to " - no selection - " so now I've posted two (three) times. Good lord I am sickeningly bad at this. I'll just stop posting now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 21:39:40 2014 From: report at bugs.python.org (Todd Thomas) Date: Tue, 23 Sep 2014 19:39:40 +0000 Subject: [issue22471] Python build problems via Homebrew on Mac OS X when GNU core/find utils are default Message-ID: <1411501180.24.0.340452667993.issue22471@psf.upfronthosting.co.za> New submission from Todd Thomas: Installing Python via Homebrew on Mac OS X has build issues if the GNU core/find utils are set as defaults on the system. OS X is very common, on it Homebrew is very common, via Homebrew GNU utilities are among the first installations; EG: http://goo.gl/OodjHI GNU core/find utils are likely the most common tools use on POSIX systems but Mac wants to keep rolling with UNIX tools. The Makefile is flexible. If it discovers the rm program in: /usr/local/opt/coreutils/libexec/gnubin/rm (where Homebrew would install it) the build 'could' break. Testing is ad hoc but seen by many and confirmed as "likely" by ned_deily; he adds: "that particular problem is simple to fix: just change the Makefile to /usr/bin/rm." This is the work-around for now. Props to ned_deily; this is an old/annoying problem, now solved. ---------- assignee: ronaldoussoren components: Macintosh messages: 227379 nosy: ronaldoussoren, todd_dsm priority: normal severity: normal status: open title: Python build problems via Homebrew on Mac OS X when GNU core/find utils are default type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 21:43:41 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 23 Sep 2014 19:43:41 +0000 Subject: [issue22408] Tkinter doesn't handle Unicode key events on Windows In-Reply-To: <1410709495.77.0.324762298735.issue22408@psf.upfronthosting.co.za> Message-ID: <1411501421.31.0.53210635461.issue22408@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The term 'dead key' is new to me. I found this: https://en.wikipedia.org/wiki/Dead_key . 'AltGr' is also new: https://en.wikipedia.org/wiki/AltGr_key . It apparently is a 'modifier' key, not a 'dead key'. Standard non-Mac US keyboards apparently have neither, so I cannot experiment or test. Drekin, does your last comment mean that the title should be modified? ---------- nosy: +serhiy.storchaka, terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 21:45:17 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 23 Sep 2014 19:45:17 +0000 Subject: [issue20912] [zipfile.py]: Make zip directory attributes more friendly for MS-Windows In-Reply-To: <1394729062.0.0.517393567539.issue20912@psf.upfronthosting.co.za> Message-ID: <20140923194513.112519.50020@mail.hg.python.org> Roundup Robot added the comment: New changeset c6b884483cd6 by Serhiy Storchaka in branch '2.7': Issue #20912: Now directories added to ZIP file have correct Unix and MS-DOS https://hg.python.org/cpython/rev/c6b884483cd6 New changeset b06e25a357de by Serhiy Storchaka in branch '3.4': Issue #20912: Now directories added to ZIP file have correct Unix and MS-DOS https://hg.python.org/cpython/rev/b06e25a357de New changeset 051105a95461 by Serhiy Storchaka in branch 'default': Issue #20912: Now directories added to ZIP file have correct Unix and MS-DOS https://hg.python.org/cpython/rev/051105a95461 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 21:46:37 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 23 Sep 2014 19:46:37 +0000 Subject: [issue22467] Lib/http/server.py, inconsistent header casing In-Reply-To: <1411449615.3.0.851782925938.issue22467@psf.upfronthosting.co.za> Message-ID: <1411501597.1.0.671719823307.issue22467@psf.upfronthosting.co.za> R. David Murray added the comment: Don't worry about it :) The roundup UI isn't terrible, but it is far from perfect. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 21:54:50 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 23 Sep 2014 19:54:50 +0000 Subject: [issue22471] Python build problems via Homebrew on Mac OS X when GNU core/find utils are default In-Reply-To: <1411501180.24.0.340452667993.issue22471@psf.upfronthosting.co.za> Message-ID: <20140923195446.44074.30809@mail.hg.python.org> Roundup Robot added the comment: New changeset 5444c2e22ff8 by Ned Deily in branch '2.7': Issue #22471: Avoid Python Launcher.app install problems by removing https://hg.python.org/cpython/rev/5444c2e22ff8 New changeset ff2cb4dc36e7 by Ned Deily in branch '3.4': Issue #22471: Avoid Python Launcher.app install problems by removing https://hg.python.org/cpython/rev/ff2cb4dc36e7 New changeset 9c9980c3c38c by Ned Deily in branch 'default': Issue #22471: Avoid Python Launcher.app install problems by removing https://hg.python.org/cpython/rev/9c9980c3c38c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 21:57:16 2014 From: report at bugs.python.org (Ned Deily) Date: Tue, 23 Sep 2014 19:57:16 +0000 Subject: [issue22471] Python build problems via Homebrew on Mac OS X when GNU core/find utils are default In-Reply-To: <1411501180.24.0.340452667993.issue22471@psf.upfronthosting.co.za> Message-ID: <1411502236.85.0.0929133013173.issue22471@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the report! On further inspection, the whole rm thing isn't needed anymore with Python no longer maintained in svn. Fixed for release in 2.7.9, 3.4.3, and 3.5.0. ---------- assignee: ronaldoussoren -> ned.deily components: +Build nosy: +ned.deily resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 22:17:34 2014 From: report at bugs.python.org (Ned Deily) Date: Tue, 23 Sep 2014 20:17:34 +0000 Subject: [issue22408] Tkinter doesn't handle Unicode key events on Windows In-Reply-To: <1410709495.77.0.324762298735.issue22408@psf.upfronthosting.co.za> Message-ID: <1411503454.57.0.578092976062.issue22408@psf.upfronthosting.co.za> Ned Deily added the comment: Just to avoid any confusion, Apple-supplied Mac keyboards don't have an "AltGr" key. It is found on certain PC keyboard layouts and, as such, could be used on any platform (Windows, OS X, or other Unix). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 22:26:03 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 23 Sep 2014 20:26:03 +0000 Subject: [issue22362] Warn about octal escapes > 0o377 in re In-Reply-To: <1410174440.93.0.911211496637.issue22362@psf.upfronthosting.co.za> Message-ID: <20140923202556.50562.42928@mail.hg.python.org> Roundup Robot added the comment: New changeset 3b32f495fb38 by Serhiy Storchaka in branch 'default': Issue #22362: Forbidden ambiguous octal escapes out of range 0-0o377 in https://hg.python.org/cpython/rev/3b32f495fb38 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 22:28:00 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 23 Sep 2014 20:28:00 +0000 Subject: [issue22362] Warn about octal escapes > 0o377 in re In-Reply-To: <1410174440.93.0.911211496637.issue22362@psf.upfronthosting.co.za> Message-ID: <1411504080.14.0.973192476776.issue22362@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks Antoine and Victor for the review. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 22:28:13 2014 From: report at bugs.python.org (Drekin) Date: Tue, 23 Sep 2014 20:28:13 +0000 Subject: [issue22408] Tkinter doesn't handle Unicode dead key combinations on Windows In-Reply-To: <1410709495.77.0.324762298735.issue22408@psf.upfronthosting.co.za> Message-ID: <1411504093.69.0.0913032404447.issue22408@psf.upfronthosting.co.za> Drekin added the comment: By modifier I mean a key like Shift, Ctrl, Alt, AltGr; or the corresponding modifier state. A combination modifier + base key produces either special action or a character or a dead key. A dead key affects the next character rather than producing a character itself. Dead keys can be even chained, i.e. a sequence [previous dead key, modifier + base key] can produce another dead key. (Aside: This feature has been present on Windows for long time, but is used very rarely and applications are buggy. I spent some time designing my Unicode keyboard layout using chained dead keys to produce various mathematical symbols. Then I found out than some applications have problems with the feature ? including Firefox. It's basically because they try to implement the interpretation of keyboard layout by themselves rather then using standard Windows implementation through API.) For example standard Czech keyboard use the AltGr key and the corresponing state to produce characters like $, #, &, @, {, }, [, ], because the top row is used for common diacritical combinations and its Shift state for numbers. I understand that English doesn't need many characters and so the layout usually doesn't need AltGr or dead keys. But I think even English keyboard should be able to type characters like English quotes, N-dash, or ellipsis: ?, ?, ?, ?. I have also changed the title. ---------- title: Tkinter doesn't handle Unicode key events on Windows -> Tkinter doesn't handle Unicode dead key combinations on Windows _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 22:30:03 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 23 Sep 2014 20:30:03 +0000 Subject: [issue20912] [zipfile.py]: Make zip directory attributes more friendly for MS-Windows In-Reply-To: <1394729062.0.0.517393567539.issue20912@psf.upfronthosting.co.za> Message-ID: <1411504203.53.0.851449319137.issue20912@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 22:31:16 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 23 Sep 2014 20:31:16 +0000 Subject: [issue21866] zipfile.ZipFile.close() doesn't respect allowZip64 In-Reply-To: <1403675769.56.0.836465783864.issue21866@psf.upfronthosting.co.za> Message-ID: <1411504276.44.0.364888969423.issue21866@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 22:34:45 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 23 Sep 2014 20:34:45 +0000 Subject: [issue22472] OSErrors should use str and not repr on paths Message-ID: <1411504485.58.0.497867466453.issue22472@psf.upfronthosting.co.za> New submission from R. David Murray: >>> open(r'c:\bad\path') Traceback (most recent call last): File "", line 1, in FileNotFoundError: [Errno 2] No such file or directory: 'c:\\bad\\path' ---------- components: Windows messages: 227389 nosy: r.david.murray priority: normal severity: normal stage: needs patch status: open title: OSErrors should use str and not repr on paths versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 22:38:12 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 23 Sep 2014 20:38:12 +0000 Subject: [issue22133] IDLE: Set correct WM_CLASS on X11 In-Reply-To: <1407162622.12.0.711549475862.issue22133@psf.upfronthosting.co.za> Message-ID: <1411504692.6.0.419253306176.issue22133@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch which sets WM_CLASS of all long-lived toplevel windows. ---------- Added file: http://bugs.python.org/file36702/idle_wm_class.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 22:43:39 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 23 Sep 2014 20:43:39 +0000 Subject: [issue22472] OSErrors should use str and not repr on paths In-Reply-To: <1411504485.58.0.497867466453.issue22472@psf.upfronthosting.co.za> Message-ID: <1411505019.81.0.333815900527.issue22472@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: File names can contain special characters such as spaces or even newlines. str() can be ambiguous. I prefer always use repr() for file names or other user data. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 22:45:26 2014 From: report at bugs.python.org (Ned Deily) Date: Tue, 23 Sep 2014 20:45:26 +0000 Subject: [issue22408] Tkinter doesn't handle Unicode dead key combinations on Windows In-Reply-To: <1410709495.77.0.324762298735.issue22408@psf.upfronthosting.co.za> Message-ID: <1411505126.05.0.396490965044.issue22408@psf.upfronthosting.co.za> Ned Deily added the comment: I guess it still comes down to whether this is an issue in tkinter or in Tk itself. Almost all character processing and event generation is done in Tk. One way to isolate the issue would be to use text widgets in the Tk wish shell and its demo programs. They should be available in the ActiveState ActiveTcl distribution. (I'm assuming that the Python Windows installer does not include wish but I don't know that for a fact.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 22:47:58 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 23 Sep 2014 20:47:58 +0000 Subject: [issue6639] turtle: _tkinter.TclError: invalid command name ".10170160" In-Reply-To: <1249344565.24.0.634557720335.issue6639@psf.upfronthosting.co.za> Message-ID: <1411505278.53.0.0901220523544.issue6639@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Any feedback? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 23:01:02 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 23 Sep 2014 21:01:02 +0000 Subject: [issue22427] TemporaryDirectory attempts to clean up twice In-Reply-To: <1410931119.87.0.05617613507.issue22427@psf.upfronthosting.co.za> Message-ID: <1411506062.65.0.494158679399.issue22427@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 23 23:55:54 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 23 Sep 2014 21:55:54 +0000 Subject: [issue22472] OSErrors should use str and not repr on paths In-Reply-To: <1411504485.58.0.497867466453.issue22472@psf.upfronthosting.co.za> Message-ID: <1411509354.34.0.480427672014.issue22472@psf.upfronthosting.co.za> R. David Murray added the comment: I realized that after I hit submit. However, this is a real problem on windows: I can't pass the error message back to the UI (in this case the log file) without first munging it, because the string is not a correct representation of the filename and the user will think they've entered the filename wrong to begin with (this is what really happened and what resulting this bug getting filed). On windows, if I understand correctly, we don't normally have the problem of non-unicode filenames, so could we use str on windows only? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 00:09:12 2014 From: report at bugs.python.org (Stefan Behnel) Date: Tue, 23 Sep 2014 22:09:12 +0000 Subject: [issue22464] Speed up fractions implementation In-Reply-To: <1411407434.75.0.285038516488.issue22464@psf.upfronthosting.co.za> Message-ID: <1411510152.62.0.28596088578.issue22464@psf.upfronthosting.co.za> Stefan Behnel added the comment: This simple Cython variant of gcd() is substantially faster for me (you may consider it pseudo-code for a C implementation): def _gcd(a, b): # Try doing all computation in C space. If the numbers are too large # at the beginning, retry until they are small enough. cdef long long ai, bi while b: try: ai, bi = a, b except OverflowError: pass else: # switch to C loop while bi: ai, bi = bi, ai%bi return ai a, b = b, a%b return a It tries to drop the two numbers into C long-long-ints as soon as possible, and only runs the calculation in Python space until they are small enough to fit. In most cases, this will be either right from the start or fairly quickly after only a few iterations. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 00:31:27 2014 From: report at bugs.python.org (Paul Moore) Date: Tue, 23 Sep 2014 22:31:27 +0000 Subject: [issue7511] msvc9compiler.py: ValueError when trying to compile with VC Express In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za> Message-ID: <1411511487.1.0.424662641511.issue7511@psf.upfronthosting.co.za> Paul Moore added the comment: >From the comments here, there seems to be a belief that this is somehow related to VC Express only. I have hit this error when using the MS SDK (both 7.0 on Python 2.7, and 7.1 on Python 3.3 and 3.4) with DISTUTILS_USE_SDK set. Unless I have somehow misconfigured my installation, this bug prevents me from having any means of building Python extensions using free tools for 64-bit Windows. It is possible I have misconfigured something, as I am working from various notes on the web, plus trial and error, because there is no official documentation I have found on how to set up the SDK for use with distutils in this manner. ---------- nosy: +pmoore _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 01:46:15 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 23 Sep 2014 23:46:15 +0000 Subject: [issue22473] The gloss on asyncio "future with run_forever" example is confusing Message-ID: <1411515975.42.0.282827755318.issue22473@psf.upfronthosting.co.za> New submission from R. David Murray: In https://docs.python.org/3/library/asyncio-task.html#example-future-with-run-forever we have the sentence In this example, the future is responsible to display the result and to stop the loop. We could dune up the English by rewriting it: In this example, the future is responsible for displaying the result and stopping the loop. But that isn't quite true. It is the callback associated with the future that is displaying the result and stopping the loop. So, perhaps the correct gloss is: In this example, the got_result callback is responsible for displaying the result and stopping the loop. ---------- assignee: docs at python components: Documentation messages: 227398 nosy: docs at python, r.david.murray priority: normal severity: normal status: open title: The gloss on asyncio "future with run_forever" example is confusing type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 01:50:39 2014 From: report at bugs.python.org (Steve Dower) Date: Tue, 23 Sep 2014 23:50:39 +0000 Subject: [issue22466] problem with installing python 2.7.8 In-Reply-To: <1411436875.43.0.487980102228.issue22466@psf.upfronthosting.co.za> Message-ID: <1411516239.56.0.195519327581.issue22466@psf.upfronthosting.co.za> Steve Dower added the comment: You almost certainly have a corrupted download. I'd try downloading the installer again, perhaps with a different browser? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 02:02:23 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 24 Sep 2014 00:02:23 +0000 Subject: [issue22474] No explanation of how a task gets destroyed in asyncio 'task' documentation Message-ID: <1411516943.46.0.304192335953.issue22474@psf.upfronthosting.co.za> New submission from R. David Murray: In https://docs.python.org/3/library/asyncio-task.html#task, there is a note about a warning being logged if a pending task is destroyed. The section does not explain or link to an explanation of how a task might get destroyed. Nor does it define pending, but that seems reasonably clear from context (ie: the future has not completed). The example linked to does not show how the pending task got destroyed, it only shows an example of the resulting logging, with not enough information to really understand what the final line of the error message is reporting (is kill_me an asyncio API, or the name of the task, or the future it is wrapping?) ---------- assignee: docs at python components: Documentation messages: 227400 nosy: docs at python, r.david.murray priority: normal severity: normal status: open title: No explanation of how a task gets destroyed in asyncio 'task' documentation type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 02:51:49 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 24 Sep 2014 00:51:49 +0000 Subject: [issue22475] asyncio task get_stack documentation seems to contradict itself Message-ID: <1411519909.22.0.512722932689.issue22475@psf.upfronthosting.co.za> New submission from R. David Murray: The get_stack method docs say: "If the coroutine is active, returns the stack where it was suspended." I presume this means something more like "if the coroutine is not done...", since in English you can't be both active *and* suspended. Or does it mean "last suspended"? Then it talks about limit and how stacks limit returns newest frames while with tracebacks it is oldest frames...but the last sentence says that for suspended coroutines only one frame is returned. So there is a definite lack of clarity here: can we get multiple frames if the coroutine is not suspended (in which case that first sentence seems likely to be the 'last suspended' interpretation), or for non-tracebacks can we only ever get one frame, in which case why talk about limit returning the newest frames for stacks? ---------- assignee: docs at python components: Documentation messages: 227401 nosy: docs at python, r.david.murray priority: normal severity: normal status: open title: asyncio task get_stack documentation seems to contradict itself type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 02:55:39 2014 From: report at bugs.python.org (Khalid) Date: Wed, 24 Sep 2014 00:55:39 +0000 Subject: [issue22466] problem with installing python 2.7.8 In-Reply-To: <1411516239.56.0.195519327581.issue22466@psf.upfronthosting.co.za> Message-ID: Khalid added the comment: I tried downloading installer by firefox,chrome & explorer with latest update but still the same problem. I'm getting mad about why I can't get an error log On Wed, Sep 24, 2014 at 2:50 AM, Steve Dower wrote: > > Steve Dower added the comment: > > You almost certainly have a corrupted download. I'd try downloading the > installer again, perhaps with a different browser? > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 03:00:45 2014 From: report at bugs.python.org (paul j3) Date: Wed, 24 Sep 2014 01:00:45 +0000 Subject: [issue22433] Argparse considers unknown optional arguments with spaces as a known positional argument In-Reply-To: <1410969476.15.0.703805216421.issue22433@psf.upfronthosting.co.za> Message-ID: <1411520445.82.0.338165418842.issue22433@psf.upfronthosting.co.za> paul j3 added the comment: I've added a patch with tests that I think handles this case, without messing with existing test cases. It adds a new 'space' test right before the existing one, one that explicitly handles an '=' arg_string. If the space is in the 1st part, it is marked as a positional (as it does in the existing code). But if the space is in the argument portion has no such effect; the arg_string will be handled as an unknown optional. if '=' in arg_string: option_prefix, explicit_arg = arg_string.split('=', 1) if ' ' in option_prefix: return None else: return None, arg_string, None The new testcase is in the TestParseKnownArgs class (near the end of test_argparse.py), and tests the different ways in which an arg_string can be allocated to a positional or unknown. The underlying idea is that elsewhere in '_parse_optional()', an arg_string with '=' is handled just like a two part optional. It first tries an exact match, and then tries an abbreviation match. In that spirit, this space test also focuses on the flag part of the arg_string, not the argument part. Much as I like this solution, I still worry about backward compatibility. As discussed in 'http://bugs.python.org/issue9334', 'argparse does not accept options taking arguments beginning with dash (regression from optparse)', compatibility in this _parse_optional() function is a serious issue. There the proposed patch adds a switch to the API. But an API change is itself messy, and not to be taken lightly if it isn't needed. This patch has some comments that should be stripped out before it is actually applied. There is a quite a backlog argparse issues, so I don't expect quick action here. ---------- Added file: http://bugs.python.org/file36704/patch_1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 03:21:51 2014 From: report at bugs.python.org (Khalid) Date: Wed, 24 Sep 2014 01:21:51 +0000 Subject: [issue22466] problem with installing python 2.7.8 In-Reply-To: Message-ID: Khalid added the comment: I found a fix & this is the source http://www.youtube.com/watch?v=KikshWVWhzg but the question is did I make a security vulnerability?? On Wed, Sep 24, 2014 at 3:55 AM, Khalid wrote: > > Khalid added the comment: > > I tried downloading installer by firefox,chrome & explorer with latest > update but still the same problem. I'm getting mad about why I can't get an > error log > > On Wed, Sep 24, 2014 at 2:50 AM, Steve Dower > wrote: > > > > > Steve Dower added the comment: > > > > You almost certainly have a corrupted download. I'd try downloading the > > installer again, perhaps with a different browser? > > > > ---------- > > > > _______________________________________ > > Python tracker > > > > _______________________________________ > > > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 03:34:04 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 24 Sep 2014 01:34:04 +0000 Subject: [issue22476] asyncio task chapter confusion about 'task', 'future', and 'schedule' Message-ID: <1411522444.59.0.775206973129.issue22476@psf.upfronthosting.co.za> New submission from R. David Murray: Sorry for creating all these doc issues, but I'm reading these docs for the first time, and I figure it is good to capture my confusion now in the hopes that they can be clarified for other people's first readthroughs. In the task chapter, we have Futures introduced. (As an aside, it is interesting that the link to the concurrent.futures.Future docs start by saying "you should never instantiate this class directly", but the asyncio examples show direct instantiation of a future, but this difference is not mentioned in the asyncio docs when discussing the differences between them). We then see an example that appears to include scheduling a future via asyncio.async, because there is a specific mention of how we can attach a callback after it is scheduled but before the event loop is started. Then tasks are introduced with the text: Schedule the execution of a coroutine: wrap it in a future. A task is a subclass of Future. Now, having read a bit more elsewhere in the docs, I see that a Future is scheduled by its creation, and the call to async on the future in the previous example is a NOOP. But that is *not* the implication of the text (see below as well). So, there are several points of dissonance here. One is that the implication is we pass Task a coroutine and it *wraps* it in a Future. But a Task *is* a Future. So do we have a Future using another Future to wrap a coroutine, or what? Another point of dissonance is that this phrasing implies that the *act* of wrapping the coroutine in a Future is what schedules it, yet when we introduced Future we apparently had to schedule it explicitly. So I think there needs to be a mention of scheduling in the Future section. But this then brings up the question of what exactly it is that Task does that differs from what a regular Future does, a question that is only partially answered by the documentation, because what 'scheduled' means for a regular Future isn't spelled out in the Future section. Which I think means that what we really need is an overview document that puts all these concepts together into a conceptual framework, so that the documentation of the individual pieces makes sense. As a followon point, the gloss on example of parallel execution of tasks says "A task is automatically scheduled for execution when it is created. The event loop stops when all tasks are done." This reads very strangely to me. The first sentence seems to be pointing out the difference between this example and the previous one with Future where we had to explicitly schedule it (by calling async which creates a task...). But it seems that that isn't true...so why is that sentence there? The second sentence presumably refers to the fact that run_until_complete runs the event loop until all scheduled tasks are complete..because they are wrapped in 'wait'. But wait is not cross referenced or mentioned in the gloss, so I had to think about it carefully and look up wait to conclude that that was what it meant. Of course, I could be more confused than necessary because I started reading with the 'task' chapter, but I don't see an overview chapter in the doc tree. ---------- assignee: docs at python components: Documentation messages: 227405 nosy: docs at python, r.david.murray priority: normal severity: normal status: open title: asyncio task chapter confusion about 'task', 'future', and 'schedule' type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 08:29:23 2014 From: report at bugs.python.org (Stefan Behnel) Date: Wed, 24 Sep 2014 06:29:23 +0000 Subject: [issue22464] Speed up fractions implementation In-Reply-To: <1411407434.75.0.285038516488.issue22464@psf.upfronthosting.co.za> Message-ID: <1411540163.53.0.77588125386.issue22464@psf.upfronthosting.co.za> Stefan Behnel added the comment: BTW, the last two patches (int4 and redundant_property) are ready to be applied. Anyone? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 08:40:46 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 24 Sep 2014 06:40:46 +0000 Subject: [issue22464] Speed up fractions implementation In-Reply-To: <1411407434.75.0.285038516488.issue22464@psf.upfronthosting.co.za> Message-ID: <20140924064042.42127.21209@mail.hg.python.org> Roundup Robot added the comment: New changeset 646bc7d3544b by Georg Brandl in branch 'default': #22464: Speed up common Fraction operations by special-casing several https://hg.python.org/cpython/rev/646bc7d3544b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 08:41:11 2014 From: report at bugs.python.org (Georg Brandl) Date: Wed, 24 Sep 2014 06:41:11 +0000 Subject: [issue22464] Speed up fractions implementation In-Reply-To: <1411407434.75.0.285038516488.issue22464@psf.upfronthosting.co.za> Message-ID: <1411540871.24.0.0187309736315.issue22464@psf.upfronthosting.co.za> Georg Brandl added the comment: Left this open in case you have additional patches coming. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 09:17:46 2014 From: report at bugs.python.org (Erik Cederstrand) Date: Wed, 24 Sep 2014 07:17:46 +0000 Subject: [issue12006] strptime should implement %V or %u directive from libc In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za> Message-ID: <1411543066.71.0.67432007195.issue12006@psf.upfronthosting.co.za> Erik Cederstrand added the comment: I don't have the repo handy to make a patch against 3.5, but would an addition like this do? in Lib/_strptime.py: + elif iso_week != -1 and iso_year == -1: + raise ValueError("'%Y' directive is ambiguous in combination with '%V'. Use '%G' instead.") + elif julian == -1 and iso_week != -1 and iso_weekday != -1: + year, julian = _calc_julian_from_V(iso_year, iso_week, iso_weekday) In Lib/test/test_strptime.py: def test_ValueError(self): + # Make sure ValueError is raised when match fails or format is bad + self.assertRaises(ValueError, _strptime._strptime, data_string="1905 52", + format="%Y %V") ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 09:25:02 2014 From: report at bugs.python.org (Brian Gladman) Date: Wed, 24 Sep 2014 07:25:02 +0000 Subject: [issue22477] GCD in Fractions Message-ID: <1411543502.18.0.966419857361.issue22477@psf.upfronthosting.co.za> New submission from Brian Gladman: There is a discussion of this issue on comp.lang.python The function known as 'the greatest common divisor' has a number of well defined mathematical properties for both positive and negative integers (see, for example, Elementary Number Theory by Kenneth Rosen). In particular gcd(a, b) = gcd(|a|, |b|). But the Python version of this function in the fractions module doesn't conform to these properties since it returns a negative value when its second parameter is negative. This behaviour is documented but I think it is undesirable to provide a function that has the well known and widely understood name 'gcd', but one that doesn't match the behaviour normally associated with this function. I hence believe that consideration should be given to changing the behaviour of the Python greatest common divisor function to match the mathematical properties expected of this function. If necessary a local function in the fractions module could maintain the current behaviour. ---------- components: Library (Lib) messages: 227410 nosy: brg at gladman.plus.com priority: normal severity: normal status: open title: GCD in Fractions type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 09:26:54 2014 From: report at bugs.python.org (karl) Date: Wed, 24 Sep 2014 07:26:54 +0000 Subject: [issue5550] [urllib.request]: Comparison of HTTP headers should be insensitive to the case In-Reply-To: <1237870141.83.0.616869799184.issue5550@psf.upfronthosting.co.za> Message-ID: <1411543614.82.0.332610682822.issue5550@psf.upfronthosting.co.za> karl added the comment: Ok my tests are ok. ? ./python.exe -m unittest -v Lib/test/test_urllib2net.py test_close (Lib.test.test_urllib2net.CloseSocketTest) ... ok test_custom_headers (Lib.test.test_urllib2net.OtherNetworkTests) ... FAIL test_file (Lib.test.test_urllib2net.OtherNetworkTests) ... test_ftp (Lib.test.test_urllib2net.OtherNetworkTests) ... skipped "Resource 'ftp://gatekeeper.research.compaq.com/pub/DEC/SRC/research-reports/00README-Legal-Rules-Regs' is not available" test_headers_case_sensitivity (Lib.test.test_urllib2net.OtherNetworkTests) ... ok test_redirect_url_withfrag (Lib.test.test_urllib2net.OtherNetworkTests) ... ok test_sites_no_connection_close (Lib.test.test_urllib2net.OtherNetworkTests) ... ok test_urlwithfrag (Lib.test.test_urllib2net.OtherNetworkTests) ... ok test_ftp_basic (Lib.test.test_urllib2net.TimeoutTest) ... ok test_ftp_default_timeout (Lib.test.test_urllib2net.TimeoutTest) ... ok test_ftp_no_timeout (Lib.test.test_urllib2net.TimeoutTest) ... ok test_ftp_timeout (Lib.test.test_urllib2net.TimeoutTest) ... ok test_http_basic (Lib.test.test_urllib2net.TimeoutTest) ... ok test_http_default_timeout (Lib.test.test_urllib2net.TimeoutTest) ... ok test_http_no_timeout (Lib.test.test_urllib2net.TimeoutTest) ... ok test_http_timeout (Lib.test.test_urllib2net.TimeoutTest) ... ok I wonder if test_custom_headers fails because of my modifications. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 09:29:26 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 24 Sep 2014 07:29:26 +0000 Subject: [issue22477] GCD in Fractions In-Reply-To: <1411543502.18.0.966419857361.issue22477@psf.upfronthosting.co.za> Message-ID: <1411543766.46.0.590550111052.issue22477@psf.upfronthosting.co.za> STINNER Victor added the comment: See also issue #22464. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 09:35:03 2014 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 24 Sep 2014 07:35:03 +0000 Subject: [issue22477] GCD in Fractions In-Reply-To: <1411543502.18.0.966419857361.issue22477@psf.upfronthosting.co.za> Message-ID: <1411544103.8.0.289890325905.issue22477@psf.upfronthosting.co.za> Mark Dickinson added the comment: +1 from me. ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 09:43:03 2014 From: report at bugs.python.org (Drekin) Date: Wed, 24 Sep 2014 07:43:03 +0000 Subject: [issue22408] Tkinter doesn't handle Unicode dead key combinations on Windows In-Reply-To: <1410709495.77.0.324762298735.issue22408@psf.upfronthosting.co.za> Message-ID: <1411544583.03.0.651538004749.issue22408@psf.upfronthosting.co.za> Drekin added the comment: I installed wish and tried the demos shipped with Python. The behavior occurs during the demo "basic editable text". So it's an issue of Tk itself. Actually the same behavior occurs even in the wish shell. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 09:43:44 2014 From: report at bugs.python.org (James Spurin) Date: Wed, 24 Sep 2014 07:43:44 +0000 Subject: [issue17835] test_io broken on PPC64 Linux In-Reply-To: <1366830173.09.0.170493348126.issue17835@psf.upfronthosting.co.za> Message-ID: <1411544624.62.0.271885454519.issue17835@psf.upfronthosting.co.za> James Spurin added the comment: I encountered similar issues to those discussed in this issue whilst compiling 3.4.1 on 'Red Hat Enterprise Linux Server release 6.5 (Santiago)' In particular, the following tests were failing - [root at lonlx90800 ~]# /local/0/python-3.4.1/bin/python3 /local/0/python-3.4.1/lib/python3.4/test/test_asyncio/test_subprocess.py F.......F....... ====================================================================== FAIL: test_broken_pipe (__main__.SubprocessFastWatcherTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/local/0/python-3.4.1/lib/python3.4/test/test_asyncio/test_subprocess.py", line 129, in test_broken_pipe self.loop.run_until_complete(proc.communicate(large_data)) AssertionError: BrokenPipeError not raised ====================================================================== FAIL: test_broken_pipe (__main__.SubprocessSafeWatcherTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/local/0/python-3.4.1/lib/python3.4/test/test_asyncio/test_subprocess.py", line 129, in test_broken_pipe self.loop.run_until_complete(proc.communicate(large_data)) AssertionError: BrokenPipeError not raised In this case, the issues are being caused by the following kernel parameters that we have for our default build - ######################### ## TIBCO network tuning # ######################### net.core.rmem_default = 33554432 net.core.wmem_default = 33554432 net.core.rmem_max = 33554432 net.core.wmem_max = 33554432 Toggling the support.PIPE_MAX_SIZE to +32MB or temporarily removing these parameters mitigates the issue. Is there a better way of calculating support.PIPE_MAX_SIZE so it is reflective of the actual OS value? ---------- nosy: +spurin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 09:49:29 2014 From: report at bugs.python.org (karl) Date: Wed, 24 Sep 2014 07:49:29 +0000 Subject: [issue22478] tests for urllib2net are in bad shapes Message-ID: <1411544969.4.0.411539289792.issue22478@psf.upfronthosting.co.za> New submission from karl: ? ./python.exe -V Python 3.4.2rc1+ ? hg tip changeset: 92532:6dcc96fa3970 tag: tip parent: 92530:ad45c2707006 parent: 92531:8eb4eec8626c user: Benjamin Peterson date: Mon Sep 22 22:44:21 2014 -0400 summary: merge 3.4 (#22459) When working on issue #5550, I realized that some tests are currently failing. Here the log of running: ? ./python.exe -m unittest -v Lib/test/test_urllib2net.py test_close (Lib.test.test_urllib2net.CloseSocketTest) ... ok test_custom_headers (Lib.test.test_urllib2net.OtherNetworkTests) ... FAIL test_file (Lib.test.test_urllib2net.OtherNetworkTests) ... test_ftp (Lib.test.test_urllib2net.OtherNetworkTests) ... skipped "Resource 'ftp://gatekeeper.research.compaq.com/pub/DEC/SRC/research-reports/00README-Legal-Rules-Regs' is not available" test_redirect_url_withfrag (Lib.test.test_urllib2net.OtherNetworkTests) ... ok test_sites_no_connection_close (Lib.test.test_urllib2net.OtherNetworkTests) ... ok test_urlwithfrag (Lib.test.test_urllib2net.OtherNetworkTests) ... ok test_ftp_basic (Lib.test.test_urllib2net.TimeoutTest) ... ok test_ftp_default_timeout (Lib.test.test_urllib2net.TimeoutTest) ... ok test_ftp_no_timeout (Lib.test.test_urllib2net.TimeoutTest) ... ok test_ftp_timeout (Lib.test.test_urllib2net.TimeoutTest) ... ok test_http_basic (Lib.test.test_urllib2net.TimeoutTest) ... ok test_http_default_timeout (Lib.test.test_urllib2net.TimeoutTest) ... ok test_http_no_timeout (Lib.test.test_urllib2net.TimeoutTest) ... ok test_http_timeout (Lib.test.test_urllib2net.TimeoutTest) ... ok ====================================================================== ERROR: test_file (Lib.test.test_urllib2net.OtherNetworkTests) (url='file:/Users/karl/code/cpython/%40test_61795_tmp') ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/karl/code/cpython/Lib/test/test_urllib2net.py", line 243, in _test_urls f = urlopen(url, req, TIMEOUT) File "/Users/karl/code/cpython/Lib/test/test_urllib2net.py", line 33, in wrapped return _retry_thrice(func, exc, *args, **kwargs) File "/Users/karl/code/cpython/Lib/test/test_urllib2net.py", line 23, in _retry_thrice return func(*args, **kwargs) File "/Users/karl/code/cpython/Lib/urllib/request.py", line 447, in open req = Request(fullurl, data) File "/Users/karl/code/cpython/Lib/urllib/request.py", line 267, in __init__ origin_req_host = request_host(self) File "/Users/karl/code/cpython/Lib/urllib/request.py", line 250, in request_host host = _cut_port_re.sub("", host, 1) TypeError: expected string or buffer ====================================================================== ERROR: test_file (Lib.test.test_urllib2net.OtherNetworkTests) (url=('file:///nonsensename/etc/passwd', None, )) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/karl/code/cpython/Lib/test/test_urllib2net.py", line 243, in _test_urls f = urlopen(url, req, TIMEOUT) File "/Users/karl/code/cpython/Lib/test/test_urllib2net.py", line 33, in wrapped return _retry_thrice(func, exc, *args, **kwargs) File "/Users/karl/code/cpython/Lib/test/test_urllib2net.py", line 23, in _retry_thrice return func(*args, **kwargs) File "/Users/karl/code/cpython/Lib/urllib/request.py", line 447, in open req = Request(fullurl, data) File "/Users/karl/code/cpython/Lib/urllib/request.py", line 267, in __init__ origin_req_host = request_host(self) File "/Users/karl/code/cpython/Lib/urllib/request.py", line 250, in request_host host = _cut_port_re.sub("", host, 1) TypeError: expected string or buffer ====================================================================== FAIL: test_custom_headers (Lib.test.test_urllib2net.OtherNetworkTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/karl/code/cpython/Lib/test/test_urllib2net.py", line 186, in test_custom_headers self.assertEqual(request.get_header('User-agent'), 'Test-Agent') AssertionError: 'Python-urllib/3.4' != 'Test-Agent' - Python-urllib/3.4 + Test-Agent ---------------------------------------------------------------------- Ran 16 tests in 124.879s FAILED (failures=1, errors=2, skipped=1) ---------- components: Tests messages: 227417 nosy: karlcow priority: normal severity: normal status: open title: tests for urllib2net are in bad shapes versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 09:52:18 2014 From: report at bugs.python.org (karl) Date: Wed, 24 Sep 2014 07:52:18 +0000 Subject: [issue5550] [urllib.request]: Comparison of HTTP headers should be insensitive to the case In-Reply-To: <1237870141.83.0.616869799184.issue5550@psf.upfronthosting.co.za> Message-ID: <1411545138.45.0.895800552252.issue5550@psf.upfronthosting.co.za> karl added the comment: Opened issue #22478 for the tests failing. Not related to my modification. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 09:58:12 2014 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 24 Sep 2014 07:58:12 +0000 Subject: [issue22477] GCD in Fractions In-Reply-To: <1411543502.18.0.966419857361.issue22477@psf.upfronthosting.co.za> Message-ID: <1411545492.67.0.747248935813.issue22477@psf.upfronthosting.co.za> Mark Dickinson added the comment: The current `gcd` definition is almost accidental, in that it just happens to be what's convenient for use in normalisation in the Fraction type. If people are using it as a standalone implementation of gcd, independent of the fractions module, then defining the result to be always nonnegative is probably a little less surprising than the current behaviour. BTW, I don't think there's a universally agreed definition for the extension of the gcd to negative numbers (and I certainly wouldn't take Rosen's book as authoritative: did you notice the bit where he talks about 35-bit machines being common?), so I don't regard the fraction module definition as wrong, per se. But I do agree that the behaviour you propose would be less surprising. One other thought: if we're really intending for gcd to be used independently of the fractions module, perhaps it should be exposed as math.gcd. (That would also give the opportunity for an optimised C version.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 10:22:07 2014 From: report at bugs.python.org (karl) Date: Wed, 24 Sep 2014 08:22:07 +0000 Subject: [issue22478] tests for urllib2net are in bad shapes In-Reply-To: <1411544969.4.0.411539289792.issue22478@psf.upfronthosting.co.za> Message-ID: <1411546927.8.0.816080375663.issue22478@psf.upfronthosting.co.za> karl added the comment: ok let's see ? ./python.exe -m unittest -v Lib.test.test_urllib2net.OtherNetworkTests.test_custom_headers test_custom_headers (Lib.test.test_urllib2net.OtherNetworkTests) ... FAIL ====================================================================== FAIL: test_custom_headers (Lib.test.test_urllib2net.OtherNetworkTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/karl/code/cpython/Lib/test/test_urllib2net.py", line 186, in test_custom_headers self.assertEqual(request.get_header('User-agent'), 'Test-Agent') AssertionError: 'Python-urllib/3.4' != 'Test-Agent' - Python-urllib/3.4 + Test-Agent ---------------------------------------------------------------------- Ran 1 test in 0.551s FAILED (failures=1) ? ./python.exe Python 3.4.2rc1+ (3.4:8eb4eec8626c+, Sep 23 2014, 21:53:11) [GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.51)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import urllib.request >>> url = 'http://127.0.0.1/' >>> opener = urllib.request.build_opener() >>> request = urllib.request.Request(url) >>> request.header_items() [] >>> request.headers {} >>> request.add_header('User-Agent', 'Test-Agent') >>> request.headers {'User-agent': 'Test-Agent'} >>> request.header_items() [('User-agent', 'Test-Agent')] >>> opener.open(request) >>> request.get_header('User-agent'), 'Test-Agent' ('Test-Agent', 'Test-Agent') >>> request.header_items() [('User-agent', 'Test-Agent'), ('Host', '127.0.0.1')] >>> request.headers {'User-agent': 'Test-Agent'} OK so far so good. And my server recorded 127.0.0.1 - - [24/Sep/2014:17:07:41 +0900] "GET / HTTP/1.1" 200 9897 "-" "Test-Agent" Let's do it the way, the test has been designed. ? ./python.exe Python 3.4.2rc1+ (3.4:8eb4eec8626c+, Sep 23 2014, 21:53:11) [GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.51)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import urllib.request >>> url = 'http://127.0.0.1/' >>> opener = urllib.request.build_opener() >>> request = urllib.request.Request(url) >>> request.header_items() [] >>> opener.open(request) >>> request.header_items() [('User-agent', 'Python-urllib/3.4'), ('Host', '127.0.0.1')] >>> request.has_header('User-agent') True >>> request.add_header('User-Agent', 'Test-Agent') >>> opener.open(request) >>> request.get_header('User-agent'), 'Test-Agent' ('Python-urllib/3.4', 'Test-Agent') >>> request.add_header('Foo', 'bar') >>> request.header_items() [('User-agent', 'Test-Agent'), ('Host', '127.0.0.1'), ('Foo', 'bar')] >>> opener.open(request) >>> request.header_items() [('User-agent', 'Test-Agent'), ('Host', '127.0.0.1'), ('Foo', 'bar')] >>> request.get_header('User-agent'), 'Test-Agent' ('Python-urllib/3.4', 'Test-Agent') >>> request.headers {'User-agent': 'Test-Agent', 'Foo': 'bar'} And the server recorded. 127.0.0.1 - - [24/Sep/2014:17:12:52 +0900] "GET / HTTP/1.1" 200 9897 "-" "Python-urllib/3.4" 127.0.0.1 - - [24/Sep/2014:17:12:52 +0900] "GET / HTTP/1.1" 200 9897 "-" "Python-urllib/3.4" 127.0.0.1 - - [24/Sep/2014:17:14:15 +0900] "GET / HTTP/1.1" 200 9897 "-" "Python-urllib/3.4" So it seems that User-Agent is immutable once it has been set the first time. Not in the same dictionary. >>> request.unredirected_hdrs {'User-agent': 'Python-urllib/3.4', 'Host': '127.0.0.1'} ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 10:33:53 2014 From: report at bugs.python.org (karl) Date: Wed, 24 Sep 2014 08:33:53 +0000 Subject: [issue22478] tests for urllib2net are in bad shapes In-Reply-To: <1411544969.4.0.411539289792.issue22478@psf.upfronthosting.co.za> Message-ID: <1411547633.83.0.465406904057.issue22478@psf.upfronthosting.co.za> karl added the comment: Ah! the User-Agent (or anything which is in unredirected_hdrs) will not be updated if it has already been set once. https://hg.python.org/cpython/file/064f6baeb6bd/Lib/urllib/request.py#l1154 >>> headers = dict(request.unredirected_hdrs) >>> headers {'User-agent': 'Python-urllib/3.4', 'Host': '127.0.0.1'} >>> request.headers {'User-agent': 'Test-Agent', 'Foo': 'cool'} >>> headers.update(dict((k, v) for k, v in request.headers.items() if k not in headers)) >>> headers {'User-agent': 'Python-urllib/3.4', 'Host': '127.0.0.1', 'Foo': 'cool'} ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 10:34:13 2014 From: report at bugs.python.org (Ned Deily) Date: Wed, 24 Sep 2014 08:34:13 +0000 Subject: [issue22408] Tkinter doesn't handle Unicode dead key combinations on Windows In-Reply-To: <1410709495.77.0.324762298735.issue22408@psf.upfronthosting.co.za> Message-ID: <1411547653.86.0.44797365973.issue22408@psf.upfronthosting.co.za> Ned Deily added the comment: OK, then if you want to pursue the issue, I'd suggest asking on one of the Tcl/Tk forums (perhaps comp.lang.tcl) or Stackoverflow and/or checking the Tk issue tracker (https://core.tcl.tk/tk/reportlist). Good luck! ---------- resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 10:44:05 2014 From: report at bugs.python.org (Ned Deily) Date: Wed, 24 Sep 2014 08:44:05 +0000 Subject: [issue22478] tests for urllib2net are in bad shapes In-Reply-To: <1411544969.4.0.411539289792.issue22478@psf.upfronthosting.co.za> Message-ID: <1411548245.15.0.031260297639.issue22478@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 10:46:04 2014 From: report at bugs.python.org (gladman) Date: Wed, 24 Sep 2014 08:46:04 +0000 Subject: [issue22477] GCD in Fractions In-Reply-To: <1411545492.67.0.747248935813.issue22477@psf.upfronthosting.co.za> Message-ID: <542284CC.8070202@gladman.plus.com> gladman added the comment: On 24/09/2014 08:58, Mark Dickinson wrote: > > Mark Dickinson added the comment: > > The current `gcd` definition is almost accidental, in that it just happens to be what's convenient for use in normalisation in the Fraction type. If people are using it as a standalone implementation of gcd, independent of the fractions module, then defining the result to be always nonnegative is probably a little less surprising than the current behaviour. > > BTW, I don't think there's a universally agreed definition for the extension of the gcd to negative numbers (and I certainly wouldn't take Rosen's book as authoritative: did you notice the bit where he talks about 35-bit machines being common?), so I don't regard the fraction module definition as wrong, per se. But I do agree that the behaviour you propose would be less surprising. I only quoted Rosen because I had it immediately to hand. I will willingly supply more references if you need them. Sadly even some maths books don't cover this at all but then go on to rely on the co-prime test gcd(a, b) == 1 even when a and/or b can be negative. So I would agree that it is easy to conclude that the gcd is not defined for negative numbers. But, of those maths texts that explicitly cover the behaviour of the gcd for negative numbers, I do not know of any that do not define gcd(a, b) to be gcd(|a|, |b|). > One other thought: if we're really intending for gcd to be used independently of the fractions module, perhaps it should be exposed as math.gcd. (That would also give the opportunity for an optimised C version.) To me it makes more sense to put this in math as this is where I would expect to find it. But a comment on comp.lang.python was not in favour of this. ---------- nosy: +gladman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 10:50:30 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 24 Sep 2014 08:50:30 +0000 Subject: [issue22476] asyncio task chapter confusion about 'task', 'future', and 'schedule' In-Reply-To: <1411522444.59.0.775206973129.issue22476@psf.upfronthosting.co.za> Message-ID: <1411548630.65.0.335123105542.issue22476@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 10:50:39 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 24 Sep 2014 08:50:39 +0000 Subject: [issue22475] asyncio task get_stack documentation seems to contradict itself In-Reply-To: <1411519909.22.0.512722932689.issue22475@psf.upfronthosting.co.za> Message-ID: <1411548639.92.0.694947088768.issue22475@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 10:50:50 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 24 Sep 2014 08:50:50 +0000 Subject: [issue22474] No explanation of how a task gets destroyed in asyncio 'task' documentation In-Reply-To: <1411516943.46.0.304192335953.issue22474@psf.upfronthosting.co.za> Message-ID: <1411548650.83.0.396486000102.issue22474@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 10:50:59 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 24 Sep 2014 08:50:59 +0000 Subject: [issue22473] The gloss on asyncio "future with run_forever" example is confusing In-Reply-To: <1411515975.42.0.282827755318.issue22473@psf.upfronthosting.co.za> Message-ID: <1411548659.98.0.730626545518.issue22473@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 10:56:05 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 24 Sep 2014 08:56:05 +0000 Subject: [issue18629] future division breaks timedelta division by integer In-Reply-To: <1375456931.04.0.558889166858.issue18629@psf.upfronthosting.co.za> Message-ID: <1411548965.85.0.873081527211.issue18629@psf.upfronthosting.co.za> Antoine Pitrou added the comment: It's not a duplicate. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 10:57:41 2014 From: report at bugs.python.org (Berker Peksag) Date: Wed, 24 Sep 2014 08:57:41 +0000 Subject: [issue18993] There is an overshadowed and invalid test in testmock.py In-Reply-To: <1378796103.81.0.419617172609.issue18993@psf.upfronthosting.co.za> Message-ID: <1411549061.98.0.793733211378.issue18993@psf.upfronthosting.co.za> Berker Peksag added the comment: This has been fixed in https://hg.python.org/cpython/rev/c8c11082bd0c. ---------- nosy: +berker.peksag resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 10:59:40 2014 From: report at bugs.python.org (Quentin Pradet) Date: Wed, 24 Sep 2014 08:59:40 +0000 Subject: =?utf-8?q?=5Bissue21049=5D_Warning_at_interpreter_exit_triggers_flood_of_?= =?utf-8?b?4oCcSW1wb3J0V2FybmluZzogc3lzLm1ldGFfcGF0aCBpcyBlbXB0eeKAnQ==?= In-Reply-To: <1395642335.41.0.483787590936.issue21049@psf.upfronthosting.co.za> Message-ID: <1411549180.07.0.779690486864.issue21049@psf.upfronthosting.co.za> Quentin Pradet added the comment: I've also been affected by this when testing integration with a third-party library (NLTK). NLTK does need to be fixed, but the ResourceWarning already say so. The new one-liner doesn't seem contrived to me. ---------- nosy: +Quentin.Pradet _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 11:13:41 2014 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 24 Sep 2014 09:13:41 +0000 Subject: [issue22477] GCD in Fractions In-Reply-To: <1411543502.18.0.966419857361.issue22477@psf.upfronthosting.co.za> Message-ID: <1411550021.38.0.048529086143.issue22477@psf.upfronthosting.co.za> Mark Dickinson added the comment: > I will willingly supply more references if you need them. I don't. :-) I've taught more elementary number classes and reviewed more elementary number theory texts (including Rosen's) than I care to remember, and I have plenty of my own references. I stand by my assertion that the fractions module gcd is not wrong: it returns 'a' greatest common divisor for arbitrary integer inputs. A bit more: the concept of greatest common divisor is slightly ambiguous: you can define the notion of "a greatest common divisor" for an arbitrary commutative ring-with-a-1 R: c is a greatest common divisor of a and b if c is a common divisor (i.e. c divides a and c divides b, where "x divides y" is synonymous with "y is a multiple of x"), and any other common divisor divides c. No ordering is necessary: "greatest" here is with respect to the divisibility lattice rather than with respect to any kind of total ordering. One advantage of this definition is that it makes it clear that 0 is a greatest common divisor of 0 and 0. If further R is an integral domain, then it follows immediately from the definition that any two greatest common divisors of a and b (if they exist) are associates: a is a unit times b. In the particular case where R is the usual ring of rational integers, that means that "the" greatest common divisor of two numbers a and b is only really defined up to +/-; that is, the sign of the result is unimportant. (An alternative viewpoint is to think of the gcd, when it exists, as a principal ideal rather than an element of the ring.) See https://proofwiki.org/wiki/Definition:Greatest_Common_Divisor/Integral_Domain for more along these lines. So you're using one definition, I'm using another. Like I said, there's no universal agreement. ;-). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 11:21:10 2014 From: report at bugs.python.org (Bekket McClane) Date: Wed, 24 Sep 2014 09:21:10 +0000 Subject: [issue22479] strange behavior of importing random module Message-ID: <1411550470.24.0.951916107217.issue22479@psf.upfronthosting.co.za> New submission from Bekket McClane: When I import the random module using "import random" in the command line, it worked fine. But if I import it in the file, the program will throw a strange error, but sometimes it just exit right away after the import statement with no error. Moreover, if I execute the python command line again and "import random" after that, the command line python exit right away too(with exit code 0). Only if I restarted the whole terminal program did the strange behavior gone ---------- components: Library (Lib) files: Screenshot from 2014-09-24 17:04:58.png messages: 227428 nosy: Bekket.McClane priority: normal severity: normal status: open title: strange behavior of importing random module type: crash versions: Python 2.7 Added file: http://bugs.python.org/file36705/Screenshot from 2014-09-24 17:04:58.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 11:39:38 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 24 Sep 2014 09:39:38 +0000 Subject: [issue22478] tests for urllib2net are in bad shapes In-Reply-To: <1411544969.4.0.411539289792.issue22478@psf.upfronthosting.co.za> Message-ID: <1411551578.41.0.656766912174.issue22478@psf.upfronthosting.co.za> Senthil Kumaran added the comment: I suspect that you have your interpreters confused. (For e.g, I see 3.4 run against the trunk and the error messages are leading me to believe that 2.7 version in run on 3 code). Or your local copy is not in right shape. I tested it on 3.4 and cpython default and everything was OK. [localhost 3.4]$ ./python.exe -m unittest -v Lib/test/test_urllib2net.py ... Ran 15 tests in 36.672s OK [localhost 3.4]$ hg log -r 3.4 changeset: 92551:bce1594023f9 branch: 3.4 parent: 92548:381d6362c7bc parent: 92546:ff2cb4dc36e7 user: Serhiy Storchaka date: Tue Sep 23 23:23:41 2014 +0300 description: Merge heads [localhost cpython]$ ./python.exe -m unittest -v Lib/test/test_urllib2net.py ... Ran 15 tests in 32.779s OK [localhost cpython]$ hg log -r tip changeset: 92555:064f6baeb6bd tag: tip user: Georg Brandl date: Wed Sep 24 09:08:12 2014 +0200 files: Python/importlib.h description: Update importlib.h frozen bytecode (changed due to commit c0ca9d32aed4). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 11:41:11 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 24 Sep 2014 09:41:11 +0000 Subject: [issue22478] tests for urllib2net are in bad shapes In-Reply-To: <1411544969.4.0.411539289792.issue22478@psf.upfronthosting.co.za> Message-ID: <1411551671.24.0.572008810086.issue22478@psf.upfronthosting.co.za> Senthil Kumaran added the comment: The buildbots are not showing this error too. I suggest you reset your local copy with the pristine one from remote, do a make distclean; ./configure; make and then run the tests. ---------- assignee: -> orsenthil resolution: -> works for me stage: -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 11:42:00 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 24 Sep 2014 09:42:00 +0000 Subject: [issue22479] strange behavior of importing random module In-Reply-To: <1411550470.24.0.951916107217.issue22479@psf.upfronthosting.co.za> Message-ID: <1411551720.1.0.956961903069.issue22479@psf.upfronthosting.co.za> STINNER Victor added the comment: It's not a bug in Python. The problem is that your project contains a file called "random.py" which is used instead of the random from the standard library. Rename the file (and remove random.pyc). ---------- nosy: +haypo resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 11:44:11 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 24 Sep 2014 09:44:11 +0000 Subject: [issue21860] Correct FileIO docstrings In-Reply-To: <1403610592.56.0.388497950887.issue21860@psf.upfronthosting.co.za> Message-ID: <20140924094404.99099.35827@mail.hg.python.org> Roundup Robot added the comment: New changeset 2058d94f32dd by Berker Peksag in branch '3.4': Issue #21860: Correct docstrings of FileIO.seek() and FileIO.truncate() methods. https://hg.python.org/cpython/rev/2058d94f32dd New changeset de645efe6a9b by Berker Peksag in branch 'default': Issue #21860: Correct docstrings of FileIO.seek() and FileIO.truncate() methods. https://hg.python.org/cpython/rev/de645efe6a9b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 11:45:36 2014 From: report at bugs.python.org (Berker Peksag) Date: Wed, 24 Sep 2014 09:45:36 +0000 Subject: [issue21860] Correct FileIO docstrings In-Reply-To: <1403610592.56.0.388497950887.issue21860@psf.upfronthosting.co.za> Message-ID: <1411551936.78.0.823747007553.issue21860@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch, Terry. ---------- assignee: haypo -> berker.peksag nosy: +berker.peksag resolution: -> fixed stage: commit review -> resolved status: open -> closed versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 11:54:27 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 24 Sep 2014 09:54:27 +0000 Subject: [issue21860] Correct FileIO docstrings In-Reply-To: <1403610592.56.0.388497950887.issue21860@psf.upfronthosting.co.za> Message-ID: <20140924095421.82039.91609@mail.hg.python.org> Roundup Robot added the comment: New changeset be2746c565c2 by Berker Peksag in branch '2.7': Issue #21860: Correct docstrings of FileIO.seek() and FileIO.truncate() methods. https://hg.python.org/cpython/rev/be2746c565c2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 12:31:21 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 24 Sep 2014 10:31:21 +0000 Subject: [issue22427] TemporaryDirectory attempts to clean up twice In-Reply-To: <1410931119.87.0.05617613507.issue22427@psf.upfronthosting.co.za> Message-ID: <20140924103059.42149.13000@mail.hg.python.org> Roundup Robot added the comment: New changeset 7ea2153eae87 by Serhiy Storchaka in branch '3.4': Issue #22427: TemporaryDirectory no longer attempts to clean up twice when https://hg.python.org/cpython/rev/7ea2153eae87 New changeset e9d4288c32de by Serhiy Storchaka in branch 'default': Issue #22427: TemporaryDirectory no longer attempts to clean up twice when https://hg.python.org/cpython/rev/e9d4288c32de ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 12:33:25 2014 From: report at bugs.python.org (gladman) Date: Wed, 24 Sep 2014 10:33:25 +0000 Subject: [issue22477] GCD in Fractions In-Reply-To: <1411550021.38.0.048529086143.issue22477@psf.upfronthosting.co.za> Message-ID: <54229DF5.7060300@gladman.plus.com> gladman added the comment: On 24/09/2014 10:13, Mark Dickinson wrote: > > Mark Dickinson added the comment: > >> I will willingly supply more references if you need them. > > I don't. :-) I've taught more elementary number classes and reviewed more elementary number theory texts (including Rosen's) than I care to remember, and I have plenty of my own references. I stand by my assertion that the fractions module gcd is not wrong: it returns 'a' greatest common divisor for arbitrary integer inputs. Well we will just have to agree to disagree on this :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 12:35:20 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 24 Sep 2014 10:35:20 +0000 Subject: [issue22219] python -mzipfile fails to add empty folders to created zip In-Reply-To: <1408298025.49.0.964091160745.issue22219@psf.upfronthosting.co.za> Message-ID: <1411554920.92.0.0451124082333.issue22219@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Hmm, looks as I forgot to attach a patch. ---------- keywords: +patch Added file: http://bugs.python.org/file36706/zipfile_add_dirs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 12:37:25 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 24 Sep 2014 10:37:25 +0000 Subject: [issue22427] TemporaryDirectory attempts to clean up twice In-Reply-To: <1410931119.87.0.05617613507.issue22427@psf.upfronthosting.co.za> Message-ID: <1411555045.23.0.375082299131.issue22427@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Committed without this test. Thank you Victor and Yury for your comments. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 12:54:52 2014 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 24 Sep 2014 10:54:52 +0000 Subject: [issue22477] GCD in Fractions In-Reply-To: <1411543502.18.0.966419857361.issue22477@psf.upfronthosting.co.za> Message-ID: <1411556092.66.0.222659989308.issue22477@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Well we will just have to agree to disagree on this :-) Sure. In the mean time, would you be interested in writing a patch targeting Python 3.5? (Irrespective of the arguments about the definition, I don't think this is a change that could be applied in a 3.4 bugfix release.) ---------- type: behavior -> enhancement versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 13:22:12 2014 From: report at bugs.python.org (chrysn) Date: Wed, 24 Sep 2014 11:22:12 +0000 Subject: [issue22480] SystemExit out of run_until_complete causes AttributeError when using python3 -m Message-ID: <1411557732.26.0.928658035687.issue22480@psf.upfronthosting.co.za> New submission from chrysn: the attached test.py snipplet, which runs an asyncio main loop to the completion of a coroutine raising SystemExit, runs cleanly when invoked using `python3 test.py`, but shows a logging error from the Task.__del__ method when invoked using `python3 -m test`. the error message (attached as test.err) indicates that the builtins module has already been emptied by the time the Task's destructor is run. i could reproduce the problem with an easier test case without asyncio (destructoretest.py), but then again, there the issue is slightly more obvious (one could argue a "don't do that, then"), and it occurs no matter how the program is run. i'm leaving this initially assigned to asyncio, because (to the best of my knowledge) test.py does not do bad things by itself, and the behavior is inconsistent only there. ---------- components: asyncio messages: 227440 nosy: chrysn, gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: SystemExit out of run_until_complete causes AttributeError when using python3 -m versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 13:22:41 2014 From: report at bugs.python.org (chrysn) Date: Wed, 24 Sep 2014 11:22:41 +0000 Subject: [issue22480] SystemExit out of run_until_complete causes AttributeError when using python3 -m In-Reply-To: <1411557732.26.0.928658035687.issue22480@psf.upfronthosting.co.za> Message-ID: <1411557761.61.0.924570813763.issue22480@psf.upfronthosting.co.za> Changes by chrysn : Added file: http://bugs.python.org/file36707/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 13:23:08 2014 From: report at bugs.python.org (chrysn) Date: Wed, 24 Sep 2014 11:23:08 +0000 Subject: [issue22480] SystemExit out of run_until_complete causes AttributeError when using python3 -m In-Reply-To: <1411557732.26.0.928658035687.issue22480@psf.upfronthosting.co.za> Message-ID: <1411557788.58.0.639498656546.issue22480@psf.upfronthosting.co.za> Changes by chrysn : Added file: http://bugs.python.org/file36708/test.err _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 13:23:29 2014 From: report at bugs.python.org (chrysn) Date: Wed, 24 Sep 2014 11:23:29 +0000 Subject: [issue22480] SystemExit out of run_until_complete causes AttributeError when using python3 -m In-Reply-To: <1411557732.26.0.928658035687.issue22480@psf.upfronthosting.co.za> Message-ID: <1411557809.29.0.586388438994.issue22480@psf.upfronthosting.co.za> Changes by chrysn : Added file: http://bugs.python.org/file36709/destructortest.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 13:31:17 2014 From: report at bugs.python.org (Stefan Champailler) Date: Wed, 24 Sep 2014 11:31:17 +0000 Subject: [issue1602] windows console doesn't print or input Unicode In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za> Message-ID: <1411558277.15.0.56836757798.issue1602@psf.upfronthosting.co.za> Stefan Champailler added the comment: Thank you all for your quick and good answers. This level of responsiveness is truly amazing. I've played a bit with IPython and it works just fine. I can type the eurosign drectly with "Alt Gr - E" (so I didn't enter a unicode code). So the bug is basically solved for me. But the python-repl behaviour still looks strange to me. So here's a successful IPython session : C:\PORT-STCA2\pl-PRIVATE\horse>chcp 65001 Active code page: 65001 C:\PORT-STCA2\pl-PRIVATE\horse>ipython Python 3.4.1 (v3.4.1:c0e311e010fc, May 18 2014, 10:38:22) [MSC v.1600 32 bit (Intel)] Type "copyright", "credits" or "license" for more information. IPython 2.2.0 -- An enhanced Interactive Python. ? -> Introduction and overview of IPython's features. %quickref -> Quick reference. help -> Python's own help system. object? -> Details about 'object', use 'object??' for extra details. In [1]: print('?') ? In [2]: ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 13:38:54 2014 From: report at bugs.python.org (gladman) Date: Wed, 24 Sep 2014 11:38:54 +0000 Subject: [issue22477] GCD in Fractions In-Reply-To: <1411556092.66.0.222659989308.issue22477@psf.upfronthosting.co.za> Message-ID: <5422AD4E.5010103@gladman.plus.com> gladman added the comment: On 24/09/2014 11:54, Mark Dickinson wrote: > > Mark Dickinson added the comment: > >> Well we will just have to agree to disagree on this :-) > > Sure. In the mean time, would you be interested in writing a patch targeting Python 3.5? (Irrespective of the arguments about the definition, I don't think this is a change that could be applied in a 3.4 bugfix release.) Yes, I am very willing to contribute. But I have never contributed to Python before and I almost certainly have a lot to learn in any attempt to do this. In particular, I need advice on where any gcd should go (fractions or math or ...). And if it goes in math and/or we want to speed it up, I would have to learn how to integrate Python and C code (I have done almost none of this before). So I would much appreciate further discusssion of this possible change and how best to implement it (if there is a consensus to do so). Of course, there is the very simple change of adding abs(x) to the return value for the current gcd and adjusting its single use in fractions accordingly. But since there is already concern about the impact of the gcd on the performance of fractions, it deserves more careful consideration than this approach would involve. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 13:41:03 2014 From: report at bugs.python.org (Stefan Behnel) Date: Wed, 24 Sep 2014 11:41:03 +0000 Subject: [issue22477] GCD in Fractions In-Reply-To: <1411543502.18.0.966419857361.issue22477@psf.upfronthosting.co.za> Message-ID: <1411558863.94.0.757378602381.issue22477@psf.upfronthosting.co.za> Stefan Behnel added the comment: I suggest adding a new implementation instead of replacing the current function in the fractions module. As Mark noted, the current gcd() is more of a sideeffect of the fractions module, but there's no real need to change that. It works perfectly ok for a) the Fraction type and b) positive input values. Even if there's no other module namespace for this functionality that is more suitable than fractions, it could still be added under a different name, say, absgcd() or whatever. Something that makes it clear(er) how negative input is handled. The mere name "gcd" isn't very telling on that front. ---------- nosy: +scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 13:43:39 2014 From: report at bugs.python.org (Akira Li) Date: Wed, 24 Sep 2014 11:43:39 +0000 Subject: [issue22477] GCD in Fractions In-Reply-To: <1411543502.18.0.966419857361.issue22477@psf.upfronthosting.co.za> Message-ID: <1411559019.22.0.206084672255.issue22477@psf.upfronthosting.co.za> Akira Li added the comment: Whether or not gcd(a, b) == gcd(|a|, |b|) depends on the definition if we believe to Stepanov of C++ STL fame who mentions in his lecture [1] [1] http://www.stepanovpapers.com/gcd.pdf that the current implementation that uses two operation __bool__ and __mod__: def gcd(a, b): while b: a, b = b, a%b return a can be applied to Euclidean ring elements (not just positive or negative integers). Despite Knuth?s objection to gcd(1, -1) = -1, adding `if a < 0: a = -a` at the end changes the requirements for the type. Here's the definition from the lecture [1]: Greatest common divisor is a common divisor that is divisible by any other common divisor. I have no opinion on whether or not fractions.gcd() should be changed. I thought that I should mention that different definitions exist. ---------- nosy: +akira _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 00:40:48 2014 From: report at bugs.python.org (Khalid) Date: Tue, 23 Sep 2014 22:40:48 +0000 Subject: [issue22466] problem with installing python 2.7.8 In-Reply-To: <1411496769.98.0.391277720005.issue22466@psf.upfronthosting.co.za> Message-ID: Khalid added the comment: I tried but I got this error "this installation package could not be opened. verify that the package exists & that you can access it, or contact the application vendor to verify that this is a valid windows installer package" (screen shot in the attachment) by the way I'm admin! On Tue, Sep 23, 2014 at 9:26 PM, Steve Dower wrote: > > Steve Dower added the comment: > > Can you try running this command and then post the log file after > installation fails: > > > msiexec /l*vx log.txt /i "" > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- Added file: http://bugs.python.org/file36703/Capture2.JPG _______________________________________ Python tracker _______________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: Capture2.JPG Type: image/jpeg Size: 38067 bytes Desc: not available URL: From report at bugs.python.org Wed Sep 24 14:03:57 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 24 Sep 2014 12:03:57 +0000 Subject: [issue16056] shadowed test names in std lib regression tests In-Reply-To: <1348691657.67.0.693161474206.issue16056@psf.upfronthosting.co.za> Message-ID: <20140924120353.99089.92206@mail.hg.python.org> Roundup Robot added the comment: New changeset 6d44906344f4 by Berker Peksag in branch '3.4': Issue #16056: Rename test method in test_statistics to avoid conflict. https://hg.python.org/cpython/rev/6d44906344f4 New changeset c49d7f4d1c04 by Berker Peksag in branch 'default': Issue #16056: Rename test method in test_statistics to avoid conflict. https://hg.python.org/cpython/rev/c49d7f4d1c04 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 14:05:39 2014 From: report at bugs.python.org (Steven D'Aprano) Date: Wed, 24 Sep 2014 12:05:39 +0000 Subject: [issue22477] GCD in Fractions In-Reply-To: <1411543502.18.0.966419857361.issue22477@psf.upfronthosting.co.za> Message-ID: <1411560339.61.0.210568703633.issue22477@psf.upfronthosting.co.za> Steven D'Aprano added the comment: I would be a lot more cautious about changing the gcd function. As Mark says, there is *not* a single well-defined meaning of the gcd for negative arguments. Even Wolfram can't decide which to use: Mathworld gives one interpretation, Mathematica the opposite. See my comments here: https://mail.python.org/pipermail/python-list/2014-September/678681.html Given that there is no one definitive definition of gcd, this is not a bug fix, it is a backward-incompatible functional change. That means it ought to go through a deprecation period before changing it: - deprecate negative arguments in 3.5; - raise a warning in 3.6; - change the behaviour in 3.7. *Maybe* we could skip the silent deprecation period and jump straight to the warning. But I don't see any justification for fast-tracking this, and certainly not for jumping straight to the change of behaviour. Somebody is using this function and expects it to do what it currently does, and changing it will break their code for precious little benefit. Another objection: this suggested change will add yet another backwards incompatibility between Python 2.7 and 3.x. There ought to be a good reason for that, not just to save a single call to abs() after gcd. I am -1 on making this change. ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 14:13:45 2014 From: report at bugs.python.org (Steven D'Aprano) Date: Wed, 24 Sep 2014 12:13:45 +0000 Subject: [issue22477] GCD in Fractions In-Reply-To: <1411543502.18.0.966419857361.issue22477@psf.upfronthosting.co.za> Message-ID: <1411560825.66.0.28277541428.issue22477@psf.upfronthosting.co.za> Steven D'Aprano added the comment: If we are considering adding a new gcd elsewhere (say, in the math module), then it should accept any arbitrary number of arguments, not just two. (At least one argument though.) Also, Mathematica supports the GCD of rational numbers, not just integers. Should we do the same? Would it be too confusing to have fractions.gcd and fractions.Fraction.gcd both exist but behave differently? I fear so. I wish we had a mathlib.py standard module for pure Python implementations... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 14:32:50 2014 From: report at bugs.python.org (Berker Peksag) Date: Wed, 24 Sep 2014 12:32:50 +0000 Subject: [issue16056] shadowed test names in std lib regression tests In-Reply-To: <1348691657.67.0.693161474206.issue16056@psf.upfronthosting.co.za> Message-ID: <1411561970.76.0.167944727857.issue16056@psf.upfronthosting.co.za> Berker Peksag added the comment: - issue 16079 opened for "make patchcheck" integration - issue 19119 opened for test_heapq - issue 19113 opened for test_functions And here's a patch for 2.7. ---------- nosy: +berker.peksag stage: needs patch -> patch review versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3 Added file: http://bugs.python.org/file36710/issue16056_27.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 15:21:53 2014 From: report at bugs.python.org (Steven D'Aprano) Date: Wed, 24 Sep 2014 13:21:53 +0000 Subject: [issue22479] strange behavior of importing random module In-Reply-To: <1411550470.24.0.951916107217.issue22479@psf.upfronthosting.co.za> Message-ID: <1411564913.24.0.0164170801351.issue22479@psf.upfronthosting.co.za> Steven D'Aprano added the comment: For future reference, we *strongly* recommend that instead of taking a screen shot and posting it as an attachment, you copy and paste the text directly. Don't retype it, any decent terminal application will allow you to select and copy the text, then paste it elsewhere. ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 16:14:54 2014 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 24 Sep 2014 14:14:54 +0000 Subject: [issue1602] windows console doesn't print or input Unicode In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za> Message-ID: <1411568094.57.0.612145676567.issue1602@psf.upfronthosting.co.za> Nick Coghlan added the comment: Aye, IPython has the advantage of running in a fully initialised browser, with the backend in a fully initialised Python environment. CPython's setting up the standard streams for the default REPL at a much lower level, and there are quite a few problems with the way we're currently doing it. I think Drekin's pointed the way towards substantially improving the situation for 3.5, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 16:20:48 2014 From: report at bugs.python.org (=?utf-8?b?0JLQu9Cw0LTQuNC80LjRgCDQotGL0YDQuNC9?=) Date: Wed, 24 Sep 2014 14:20:48 +0000 Subject: [issue22481] Lists within tuples mutability issue Message-ID: <1411568448.91.0.544050885168.issue22481@psf.upfronthosting.co.za> New submission from ???????? ?????: This behavior seems to be very strange. >>> l = [1, 2, 3] >>> t = ('a', l) >>> t ('a', [1, 2, 3]) >>> t[1] += [4] Traceback (most recent call last): File "", line 1, in TypeError: 'tuple' object does not support item assignment >>> t ('a', [1, 2, 3, 4]) ---------- messages: 227451 nosy: ????????.????? priority: normal severity: normal status: open title: Lists within tuples mutability issue type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 16:22:16 2014 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 24 Sep 2014 14:22:16 +0000 Subject: [issue22481] Lists within tuples mutability issue In-Reply-To: <1411568448.91.0.544050885168.issue22481@psf.upfronthosting.co.za> Message-ID: <1411568536.96.0.450298562671.issue22481@psf.upfronthosting.co.za> Ezio Melotti added the comment: See https://docs.python.org/3/faq/programming.html#why-does-a-tuple-i-item-raise-an-exception-when-the-addition-works ---------- nosy: +ezio.melotti resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 16:27:09 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 24 Sep 2014 14:27:09 +0000 Subject: [issue22476] asyncio task chapter confusion about 'task', 'future', and 'schedule' In-Reply-To: <1411522444.59.0.775206973129.issue22476@psf.upfronthosting.co.za> Message-ID: <1411568829.4.0.584415736052.issue22476@psf.upfronthosting.co.za> STINNER Victor added the comment: I know that the "18.5.3. Tasks and coroutines" section of the documentation is probably the worst section :-( Feel free to suggest changes with a patch! I started to enhance the documentation of the Task class, but there is still a lot of work to enhance the whole section. > "We then see an example that appears to include scheduling a future via asyncio.async, because there is a specific mention of how we can attach a callback after it is scheduled but before the event loop is started." I guess that you are talking about this example? https://docs.python.org/dev/library/asyncio-task.html#example-future-with-run-until-complete You cannot "schedule" a Future object. A Future object doesn't contain code. It only schedules callbacks when set_result() or set_exception() is called. In this example, a call to the slow_operation coroutine function is scheduled: "slow_operation(future)" creates a coroutine object which is wrapped into a Task object. A coroutine is disconnected from the event loop. The role of the task is to schedule the execution of a coroutine object. It becomes more complex when you know that the Task class inherits from the Future class :-/ > "I see that a Future is scheduled by its creation" Again, this is wrong. You cannot "schedule a future". You can schedule a coroutine object by creating a task wrapping it. > As a followon point, the gloss on example of parallel execution of tasks says "A task is automatically scheduled for execution when it is created. The event loop stops when all tasks are done." This reads very strangely to me. The first sentence seems to be pointing out the difference between this example and the previous one with Future where we had to explicitly schedule it (by calling async which creates a task...). But it seems that that isn't true...so why is that sentence there? The second sentence presumably refers to the fact that run_until_complete runs the event loop until all scheduled tasks are complete..because they are wrapped in 'wait'. But wait is not cross referenced or mentioned in the gloss, so I had to think about it carefully and look up wait to conclude that that was what it meant. Hum, I summarized too many information in "The event loop stops when all tasks are done." In fact, the example stops when run_until_complete() finished its job. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 16:28:04 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 24 Sep 2014 14:28:04 +0000 Subject: [issue22475] asyncio task get_stack documentation seems to contradict itself In-Reply-To: <1411519909.22.0.512722932689.issue22475@psf.upfronthosting.co.za> Message-ID: <1411568884.87.0.941032550766.issue22475@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- components: +asyncio _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 16:28:20 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 24 Sep 2014 14:28:20 +0000 Subject: [issue22474] No explanation of how a task gets destroyed in asyncio 'task' documentation In-Reply-To: <1411516943.46.0.304192335953.issue22474@psf.upfronthosting.co.za> Message-ID: <1411568900.13.0.0874827866144.issue22474@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- components: +asyncio _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 16:34:24 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 24 Sep 2014 14:34:24 +0000 Subject: [issue22474] No explanation of how a task gets destroyed in asyncio 'task' documentation In-Reply-To: <1411516943.46.0.304192335953.issue22474@psf.upfronthosting.co.za> Message-ID: <1411569264.2.0.783244376509.issue22474@psf.upfronthosting.co.za> STINNER Victor added the comment: "destroyed" means "collected by the garbage collector", when the last reference the task objected was cleared. To be honest, I have no idea who keeps a reference to tasks nor how the "pending task destroyed" bug occurs. "pending" means that the execution of the coroutine object didn't finish. In fact, it's related to Task.done(): a task is pending is task.done() is False. There is a corner case: if task.cancel() was called but the coroutine object was not executed yet to handle the CancelledError, the task is still "pending". Maybe "pending" is not the best word, and "not done" is better. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 16:36:41 2014 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 24 Sep 2014 14:36:41 +0000 Subject: [issue22472] OSErrors should use str and not repr on paths In-Reply-To: <1411504485.58.0.497867466453.issue22472@psf.upfronthosting.co.za> Message-ID: <1411569401.9.0.0955179790397.issue22472@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 16:39:36 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 24 Sep 2014 14:39:36 +0000 Subject: [issue22473] The gloss on asyncio "future with run_forever" example is confusing In-Reply-To: <1411515975.42.0.282827755318.issue22473@psf.upfronthosting.co.za> Message-ID: <1411569576.95.0.192479972417.issue22473@psf.upfronthosting.co.za> STINNER Victor added the comment: "But that isn't quite true. It is the callback associated with the future that is displaying the result and stopping the loop." I wrote this example to show that setting the result of a future can schedule a callback. I mean something like: "In this example, the future is used to link slow_operation() to got_result(): when slow_operation() is done, got_result() is called with the result." The main idea behind Future is to chain callbacks and the link is done externally. It's different from this design: def slow_operation(done_callback): ... done_callback() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 16:42:21 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 24 Sep 2014 14:42:21 +0000 Subject: [issue22473] The gloss on asyncio "future with run_forever" example is confusing In-Reply-To: <1411515975.42.0.282827755318.issue22473@psf.upfronthosting.co.za> Message-ID: <1411569741.45.0.864287526467.issue22473@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- components: +asyncio _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 16:43:42 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 24 Sep 2014 14:43:42 +0000 Subject: [issue22427] TemporaryDirectory attempts to clean up twice In-Reply-To: <1411555045.23.0.375082299131.issue22427@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Cool, the final code is simpler than before! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 16:47:24 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 24 Sep 2014 14:47:24 +0000 Subject: [issue22480] SystemExit out of run_until_complete causes AttributeError when using python3 -m In-Reply-To: <1411557732.26.0.928658035687.issue22480@psf.upfronthosting.co.za> Message-ID: <1411570044.93.0.845281022238.issue22480@psf.upfronthosting.co.za> STINNER Victor added the comment: Running "python test.py" and "python -m test" changes how the code is loaded. With "python test.py", test.py becomes the "__main__" module, whereas "python -m test" uses the "test" module. At Python exit, the __main__ module and other modules are destroyed differently. Anyway, this issue is another example of the issue #22428 and so I close it as duplicate. ---------- resolution: -> duplicate superseder: -> asyncio: KeyboardInterrupt inside a coroutine causes AttributeError versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 16:47:40 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 24 Sep 2014 14:47:40 +0000 Subject: [issue22428] asyncio: KeyboardInterrupt inside a coroutine causes AttributeError In-Reply-To: <1410939370.36.0.183370883396.issue22428@psf.upfronthosting.co.za> Message-ID: <1411570060.0.0.742722585737.issue22428@psf.upfronthosting.co.za> STINNER Victor added the comment: The issue #22480 has been marked as a duplicate of this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 16:50:01 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 24 Sep 2014 14:50:01 +0000 Subject: [issue22476] asyncio task chapter confusion about 'task', 'future', and 'schedule' In-Reply-To: <1411522444.59.0.775206973129.issue22476@psf.upfronthosting.co.za> Message-ID: <1411570201.8.0.289785253057.issue22476@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- components: +asyncio _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 16:50:38 2014 From: report at bugs.python.org (Brett Cannon) Date: Wed, 24 Sep 2014 14:50:38 +0000 Subject: [issue21052] Consider dropping ImportWarning for empty sys.path_hooks and sys.meta_path In-Reply-To: <1395681608.6.0.965988272103.issue21052@psf.upfronthosting.co.za> Message-ID: <1411570238.48.0.40999582466.issue21052@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 16:54:30 2014 From: report at bugs.python.org (Steve Dower) Date: Wed, 24 Sep 2014 14:54:30 +0000 Subject: [issue22466] problem with installing python 2.7.8 In-Reply-To: <1411436875.43.0.487980102228.issue22466@psf.upfronthosting.co.za> Message-ID: <1411570470.93.0.478739159397.issue22466@psf.upfronthosting.co.za> Steve Dower added the comment: Ah, okay, so this is due to the embedded DLL in the installer that we extract and use to validate the install path (if you select a path that already exists, you get a prompt warning you). I don't know why your %TEMP% directory was not read/write/execute, but since it works fine for most people I suspect a configuration issue on your machine. I have seen in the past some "security" policies that will break installers, though typically launching the installer from an elevated command prompt (one that says "Administrator: Command Prompt" in the title) typically avoids these issues. Glad you found a workaround at least. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 17:59:18 2014 From: report at bugs.python.org (Dom Zippilli) Date: Wed, 24 Sep 2014 15:59:18 +0000 Subject: [issue22482] logging: fileConfig doesn't support formatter styles Message-ID: <1411574358.31.0.567150146561.issue22482@psf.upfronthosting.co.za> New submission from Dom Zippilli: In the logging module's config.py, see the _create_formatters(cp) method used by the fileConfig() method. Note that it pulls "format" and "datefmt" and submits these in the formatter constructor: f = c(fs, dfs) However, the Formatter constructor has a third argument for formatting style: def __init__(self, fmt=None, datefmt=None, style='%') Since the argument is not passed, ConfigParser-format logging configs must use %-style logging format masks. We'd prefer to use curlies. Note that the code for the dictionary configurator does this correctly: fmt = config.get('format', None) dfmt = config.get('datefmt', None) style = config.get('style', '%') result = logging.Formatter(fmt, dfmt, style) ---------- messages: 227460 nosy: domzippilli priority: normal severity: normal status: open title: logging: fileConfig doesn't support formatter styles type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 18:12:48 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 24 Sep 2014 16:12:48 +0000 Subject: [issue22483] Copyright infringement on PyPI Message-ID: <1411575168.32.0.637271338488.issue22483@psf.upfronthosting.co.za> New submission from Stefan Krah: The following URL contains copyrighted verbatim text from bytereef.org: https://pypi.python.org/pypi/m3-cdecimal I'm not surprised, since the ongoing Walmartization of Open Source has little regard for authors. ---------- messages: 227461 nosy: skrah priority: normal severity: normal status: open title: Copyright infringement on PyPI _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 18:15:05 2014 From: report at bugs.python.org (Alex Gaynor) Date: Wed, 24 Sep 2014 16:15:05 +0000 Subject: [issue22483] Copyright infringement on PyPI In-Reply-To: <1411575168.32.0.637271338488.issue22483@psf.upfronthosting.co.za> Message-ID: <1411575305.46.0.258784309227.issue22483@psf.upfronthosting.co.za> Alex Gaynor added the comment: This bug tracker isn't really the right place to track this -- that said I don't know where is, so I've added Donald Stufft to the nosy list, hopefully he can help direct this appropriately. What license is the bytereef text available under? The cdecimal source is BSD licensed, so it's perfectly legal to re-upload the package itself. ---------- nosy: +alex, dstufft _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 18:16:06 2014 From: report at bugs.python.org (Berker Peksag) Date: Wed, 24 Sep 2014 16:16:06 +0000 Subject: [issue22482] logging: fileConfig doesn't support formatter styles In-Reply-To: <1411574358.31.0.567150146561.issue22482@psf.upfronthosting.co.za> Message-ID: <1411575366.37.0.51623935639.issue22482@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 18:21:13 2014 From: report at bugs.python.org (Donald Stufft) Date: Wed, 24 Sep 2014 16:21:13 +0000 Subject: [issue22483] Copyright infringement on PyPI In-Reply-To: <1411575168.32.0.637271338488.issue22483@psf.upfronthosting.co.za> Message-ID: <1411575673.37.0.486059332073.issue22483@psf.upfronthosting.co.za> Donald Stufft added the comment: There's a support link on the left hand side of the PyPI page, that'll take you to the support forum where you can issue a support request and it'll get dealt with. Alternatively you can email distutils-sig at python.org, or Richard and Myself (first names @python.org). ---------- resolution: -> third party status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 18:22:04 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 24 Sep 2014 16:22:04 +0000 Subject: [issue22483] Copyright infringement on PyPI In-Reply-To: <1411575168.32.0.637271338488.issue22483@psf.upfronthosting.co.za> Message-ID: <1411575724.59.0.421135050298.issue22483@psf.upfronthosting.co.za> STINNER Victor added the comment: I don't understand the issue. I see two projects: https://pypi.python.org/pypi/cdecimal https://pypi.python.org/pypi/m3-cdecimal The two projects have the same metadata except owner: cdecimal is owned by skrah, m3-cdecimal is owned by prefer. The license and author (Stefan Krah) are not changed in m3-cdecimal. Where is the "copyright infringement"? Is it the description of the package? The description contains a few lines of text (Overview, Testing, Short benchmarks, Documentation and Linux Notes sections). I'm unable to reach http://www.bytereef.org/. It looks like the domain is owned by Stefan Krah. Is it illegal to clone a project on PyPI if the author and license is not changed? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 18:23:43 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 24 Sep 2014 16:23:43 +0000 Subject: [issue22483] Copyright infringement on PyPI In-Reply-To: <1411575168.32.0.637271338488.issue22483@psf.upfronthosting.co.za> Message-ID: <1411575823.79.0.729790568486.issue22483@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, the issue was closed while I was writing my message. I agree with Alex and Donald, it's not the right place to report such issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 18:24:15 2014 From: report at bugs.python.org (Wolfgang Maier) Date: Wed, 24 Sep 2014 16:24:15 +0000 Subject: [issue22477] GCD in Fractions In-Reply-To: <1411543502.18.0.966419857361.issue22477@psf.upfronthosting.co.za> Message-ID: <1411575855.15.0.535929588438.issue22477@psf.upfronthosting.co.za> Wolfgang Maier added the comment: Wouldn't it make more sense to change gcd() in the fractions module to return only positive integers? The current gcd could become _gcd for private use by fractions, and the new wrapper gcd could just be implemented as: def gcd(a,b): return abs(_gcd(a, b)) An aspect that hasn't really been discussed so far on the mailing list is that this is *not* only about whether the gcd of negative integers should be negative or positive, but also about the fact that in the current implementation the result of gcd is dependent on the order of the arguments: >>> gcd(-3,6) == gcd(6,-3) False which I think is clearly unexpected. @Steven: I share your fear of generating backwards incompatibility only partially. Of course, there may be code out there that is relying on the current documented behavior for negative integer input, but probably not in too many places since after all it's a pretty special need and it's easy enough to implement that most people will not even come across the stdlib function before writing their own. Even if your code's affected it is really easily fixed. I do admit though that the proposed change of behavior *could* cause hard-to-track bugs in pieces of code that *do* use fractions.gcd right now. So I do favor your scheme of raising a warning with negative numbers in Python 3.5, then changing the behavior in 3.6. @Steven again: I was playing around with the idea of having a gcd that accepts more than two arguments (and the same for a potential lcm function), then realized that its easily written right now as: >>>reduce(gcd, (3,6,9)) 3 Ironically, though, the proposed new gcd would make this slower than it has to be since it would do the abs() repeatedly, when abs(reduce(_gcd, (3,6,9))) would suffice. So, I guess that's the tradeoff coming with the proposed change: - a more concise implementation of gcd against - broken backwards compatibility and - reduced flexibility by calling abs implicitly instead of just when the user needs it I guess with that I am +0.5 for the change though maybe an extra sentence in the docs about the consequences of the already documented behavior of gcd and that you really *should* call abs() on the result in most situations may be enough. ---------- nosy: +wolma _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 18:24:47 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 24 Sep 2014 16:24:47 +0000 Subject: [issue22483] Copyright infringement on PyPI In-Reply-To: <1411575168.32.0.637271338488.issue22483@psf.upfronthosting.co.za> Message-ID: <1411575887.71.0.276980914477.issue22483@psf.upfronthosting.co.za> Stefan Krah added the comment: I don't see a license on PKG-INFO itself. Furthermore, even if it is legal, it (again) shows an utter disregard for authors and their stated preferences. I'm not surprised though, given that even existing names are reassigned in an autocratic fashion. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 18:25:32 2014 From: report at bugs.python.org (Alex Gaynor) Date: Wed, 24 Sep 2014 16:25:32 +0000 Subject: [issue22483] Copyright infringement on PyPI In-Reply-To: <1411575168.32.0.637271338488.issue22483@psf.upfronthosting.co.za> Message-ID: <1411575932.5.0.429237946775.issue22483@psf.upfronthosting.co.za> Alex Gaynor added the comment: Stefan, this is not the right forum for this issue, please do not reopen it. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 18:26:24 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 24 Sep 2014 16:26:24 +0000 Subject: [issue22483] Copyright infringement on PyPI In-Reply-To: <1411575168.32.0.637271338488.issue22483@psf.upfronthosting.co.za> Message-ID: <1411575984.81.0.176932379682.issue22483@psf.upfronthosting.co.za> Stefan Krah added the comment: Sorry, Donald, the actions on PyPI deserve wider exposure. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 18:35:37 2014 From: report at bugs.python.org (Donald Stufft) Date: Wed, 24 Sep 2014 16:35:37 +0000 Subject: [issue22483] Copyright infringement on PyPI In-Reply-To: <1411575168.32.0.637271338488.issue22483@psf.upfronthosting.co.za> Message-ID: <1411576537.76.0.0123598525275.issue22483@psf.upfronthosting.co.za> Donald Stufft added the comment: This will be my last post on this issue. I've given you the mechanisms for reporting problems with PyPI. PyPI is not run by python-dev nor is the python-dev bug tracker a mouth piece for your frustration with some part of the ecosystem around Python. If you actually care about fixing the issue report it through one of the venues that I've mentioned and Richard or myself (most likely Richard, I rarely deal with the actual administration of things and typically involve mostly with the technology side of things). I'm going to close this, please leave it closed as it has nothing do with CPython. If you want to speak out against something get a blog but a bugtracker is not that. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 18:36:20 2014 From: report at bugs.python.org (Donald Stufft) Date: Wed, 24 Sep 2014 16:36:20 +0000 Subject: [issue22483] Copyright infringement on PyPI In-Reply-To: <1411575168.32.0.637271338488.issue22483@psf.upfronthosting.co.za> Message-ID: <1411576580.91.0.231255056606.issue22483@psf.upfronthosting.co.za> Donald Stufft added the comment: Sorry, Richard or myself (...) will take a look and fix it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 18:51:04 2014 From: report at bugs.python.org (Donald Stufft) Date: Wed, 24 Sep 2014 16:51:04 +0000 Subject: [issue22483] Copyright infringement on PyPI In-Reply-To: <1411575168.32.0.637271338488.issue22483@psf.upfronthosting.co.za> Message-ID: <1411577464.71.0.596492401963.issue22483@psf.upfronthosting.co.za> Donald Stufft added the comment: Since I've been asked, just to clarify, my last post was a continuation of a sentence I mistakenly forgot to write out the whole thing. It should read: "If you actually care about fixing the issue report it through one of the venues that I've mentioned and Richard or myself (most likely Richard, I rarely deal with the actual administration of things and typically involve mostly with the technology side of things) will take a look and fix it." And now I really am done :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 19:09:08 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 24 Sep 2014 17:09:08 +0000 Subject: [issue22483] Copyright infringement on PyPI In-Reply-To: <1411575168.32.0.637271338488.issue22483@psf.upfronthosting.co.za> Message-ID: <1411578548.62.0.940827262322.issue22483@psf.upfronthosting.co.za> Stefan Krah added the comment: Yeah right, obviously I don't *really* care about the issue (ethics in open source software, in case you did not understand). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 19:27:59 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 24 Sep 2014 17:27:59 +0000 Subject: [issue22477] GCD in Fractions In-Reply-To: <1411543502.18.0.966419857361.issue22477@psf.upfronthosting.co.za> Message-ID: <1411579679.04.0.775492532.issue22477@psf.upfronthosting.co.za> Terry J. Reedy added the comment: If nothing else, the doc for fractions.gcd "Return the greatest common divisor" is wrong and should be changed. The negative of the greatest common divisor is the least common divisor in an integer range. The doc should say "Return the greatest common divisor or its negative". Ditto for the docstring. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 19:42:14 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 24 Sep 2014 17:42:14 +0000 Subject: [issue22477] GCD in Fractions In-Reply-To: <1411543502.18.0.966419857361.issue22477@psf.upfronthosting.co.za> Message-ID: <1411580534.8.0.815131329415.issue22477@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Or "Return a greatest magniture common divisor ...", there being two gmcds to choose from. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 19:53:22 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 24 Sep 2014 17:53:22 +0000 Subject: [issue17835] test_io broken on PPC64 Linux In-Reply-To: <1411544624.62.0.271885454519.issue17835@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > In this case, the issues are being caused by the following kernel parameters that we have for our default build - > > ######################### > ## TIBCO network tuning # > ######################### > net.core.rmem_default = 33554432 > net.core.wmem_default = 33554432 > net.core.rmem_max = 33554432 > net.core.wmem_max = 33554432 > > Toggling the support.PIPE_MAX_SIZE to +32MB or temporarily removing these parameters mitigates the issue. Is there a better way of calculating support.PIPE_MAX_SIZE so it is reflective of the actual OS value? What does: >>> import fcntl, os >>> r, w = os.pipe() >>> fcntl.fcntl(w, 1032) return? Note that the kernel buffer sizes above are, well, *really huge*. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 20:01:36 2014 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 24 Sep 2014 18:01:36 +0000 Subject: [issue22477] GCD in Fractions In-Reply-To: <1411543502.18.0.966419857361.issue22477@psf.upfronthosting.co.za> Message-ID: <1411581696.37.0.87660295494.issue22477@psf.upfronthosting.co.za> Mark Dickinson added the comment: > The negative of the greatest common divisor is the least common divisor in an integer range. That depends on your choice of definitions: it's perfectly reasonable to see it as another greatest common divisor, if you interpret "greatest" as being with respect to the divisibility lattice, not the total ordering of Z. That's in some sense the correct interpretation, because it's the one that generalises to other interesting rings: for example, the Gaussian integers have a well-defined and useful notion of greatest common divisor, but aren't ordered, and the ring Z[sqrt 3] similarly has well-defined greatest common divisors (defined up to multiplication by a unit, as usual) *and* a total ordering, but "greatest" *can't* be interpreted in the ordering sense in that case (because there are infinitely many units). Many textbooks will talk about "a greatest common divisor" rather than "the greatest common divisor". In that sense, -3 *is* a greatest common divisor of 6 and -15. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 20:08:56 2014 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 24 Sep 2014 18:08:56 +0000 Subject: [issue22482] logging: fileConfig doesn't support formatter styles In-Reply-To: <1411574358.31.0.567150146561.issue22482@psf.upfronthosting.co.za> Message-ID: <1411582136.78.0.620537314852.issue22482@psf.upfronthosting.co.za> Vinay Sajip added the comment: While fileConfig() is not deprecated, I'm not planning to enhance it, as the newer dictConfig() API offers better functionality overall. With dictConfig(), you do have support for alternative formatting styles. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 20:15:08 2014 From: report at bugs.python.org (Berker Peksag) Date: Wed, 24 Sep 2014 18:15:08 +0000 Subject: [issue22484] Build doc archives for RC versions Message-ID: <1411582508.1.0.277862654649.issue22484@psf.upfronthosting.co.za> New submission from Berker Peksag: The attached patch partly reverts https://hg.python.org/cpython/rev/48033d90c61d#l2.126 since it breaks building doc archives for RC versions: - https://mail.python.org/pipermail/docs/2014-September/020211.html - https://mail.python.org/pipermail/docs/2014-September/020214.html - https://mail.python.org/pipermail/docs/2014-September/020215.html See https://hg.python.org/cpython/rev/ecfb6f8a7bcf for the original changeset. ---------- assignee: docs at python components: Documentation files: autobuild.diff keywords: patch messages: 227479 nosy: benjamin.peterson, berker.peksag, docs at python priority: high severity: normal stage: patch review status: open title: Build doc archives for RC versions type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file36711/autobuild.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 20:18:21 2014 From: report at bugs.python.org (Carol Willing) Date: Wed, 24 Sep 2014 18:18:21 +0000 Subject: [issue22485] Documentation download links (3.4.2 Message-ID: <1411582701.15.0.026465273673.issue22485@psf.upfronthosting.co.za> New submission from Carol Willing: As reported by a couple of users on the python-docs mailing list: Python 3.4.2rc1 docs are giving a 404 Not Found when clicking on the links to download (https://docs.python.org/3.4/download.html). Python 3.5.0a0 links download docs correctly (https://docs.python.org/3.5/download.html). If I option-click on a Mac, I can download Python 3.4.2rc1 docs; however, the direct links 404. ---------- assignee: docs at python components: Documentation messages: 227480 nosy: docs at python, willingc priority: normal severity: normal status: open title: Documentation download links (3.4.2 type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 20:19:54 2014 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 24 Sep 2014 18:19:54 +0000 Subject: [issue22485] Documentation download links (3.4.2 In-Reply-To: <1411582701.15.0.026465273673.issue22485@psf.upfronthosting.co.za> Message-ID: <1411582794.83.0.899843774599.issue22485@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +larry, terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 20:20:00 2014 From: report at bugs.python.org (gladman) Date: Wed, 24 Sep 2014 18:20:00 +0000 Subject: [issue22477] GCD in Fractions In-Reply-To: <1411581696.37.0.87660295494.issue22477@psf.upfronthosting.co.za> Message-ID: <54230B4E.9020002@gladman.plus.com> gladman added the comment: On 24/09/2014 19:01, Mark Dickinson wrote: > > Mark Dickinson added the comment: > >> The negative of the greatest common divisor is the least common divisor in an integer range. > > That depends on your choice of definitions: it's perfectly reasonable to see it as another greatest common divisor, if you interpret "greatest" as being with respect to the divisibility lattice, not the total ordering of Z. That's in some sense the correct interpretation, because it's the one that generalises to other interesting rings: for example, the Gaussian integers have a well-defined and useful notion of greatest common divisor, but aren't ordered, and the ring Z[sqrt 3] similarly has well-defined greatest common divisors (defined up to multiplication by a unit, as usual) *and* a total ordering, but "greatest" *can't* be interpreted in the ordering sense in that case (because there are infinitely many units). > > Many textbooks will talk about "a greatest common divisor" rather than "the greatest common divisor". In that sense, -3 *is* a greatest common divisor of 6 and -15. Then the Python documentation should say 'a greatest ...', not 'the greatest ...' since those who deny that the integer gcd is non-negative can hardly deny that a positive alternative value exists :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 20:21:11 2014 From: report at bugs.python.org (Berker Peksag) Date: Wed, 24 Sep 2014 18:21:11 +0000 Subject: [issue22485] Documentation download links (3.4.2 In-Reply-To: <1411582701.15.0.026465273673.issue22485@psf.upfronthosting.co.za> Message-ID: <1411582871.67.0.837768813589.issue22485@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the report. This is a duplicate of issue 22484. ---------- nosy: +berker.peksag resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Build doc archives for RC versions _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 20:29:31 2014 From: report at bugs.python.org (Carol Willing) Date: Wed, 24 Sep 2014 18:29:31 +0000 Subject: [issue22485] Documentation download links (3.4.2 In-Reply-To: <1411582701.15.0.026465273673.issue22485@psf.upfronthosting.co.za> Message-ID: <1411583371.01.0.567262044414.issue22485@psf.upfronthosting.co.za> Carol Willing added the comment: Thanks Berker. I'm glad it's being addressed and you have submitted a patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 20:33:20 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 24 Sep 2014 18:33:20 +0000 Subject: [issue22484] Build doc archives for RC versions In-Reply-To: <1411582508.1.0.277862654649.issue22484@psf.upfronthosting.co.za> Message-ID: <1411583600.3.0.890716859374.issue22484@psf.upfronthosting.co.za> R. David Murray added the comment: Why would this not also be an issue for alpha/beta? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 21:17:11 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 24 Sep 2014 19:17:11 +0000 Subject: [issue17381] IGNORECASE breaks unicode literal range matching In-Reply-To: <1362689552.47.0.00880933015098.issue17381@psf.upfronthosting.co.za> Message-ID: <1411586231.26.0.841042520415.issue17381@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is other patch for 3.4. It is more than 10 times faster than initial patch in worst case. ---------- Added file: http://bugs.python.org/file36712/re_ignore_case_range-3.4_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 21:55:18 2014 From: report at bugs.python.org (gladman) Date: Wed, 24 Sep 2014 19:55:18 +0000 Subject: [issue22477] GCD in Fractions In-Reply-To: <1411575855.15.0.535929588438.issue22477@psf.upfronthosting.co.za> Message-ID: <542321A6.4070002@gladman.plus.com> gladman added the comment: On 24/09/2014 17:24, Wolfgang Maier wrote: > > Wolfgang Maier added the comment: [snip] > An aspect that hasn't really been discussed so far on the mailing list is that this is *not* only about whether the gcd of negative integers should be negative or positive, but also about the fact that in the current implementation the result of gcd is dependent on the order of the arguments: > >>>> gcd(-3,6) == gcd(6,-3) > False > > which I think is clearly unexpected. Yes, that's another interesting surprise. > Ironically, though, the proposed new gcd would make this slower than it has to be since it would do the abs() repeatedly, when > > abs(reduce(_gcd, (3,6,9))) would suffice. > > So, I guess that's the tradeoff coming with the proposed change: I must admit to being more than a little hazy about what is fast and what isn't in the Python interpreter but wouldn't the use of reduce to repeatedly call _gcd be slower than an alternative that avoids this? Taking on board one of Steven D'Aprano's thoughts about multiple inputs, I had envisaged something like this: def mgcd(a, *r): # multiple gcd for b in r: while b: a, b = b, a % b return abs(a) which gives: >>> mgcd(0) 0 >>> mgcd(7, 0) 7 >>> mgcd(0, 7) 7 >>> mgcd(-3, -7) 1 >>> mgcd(-3, 7) 1 >>> mgcd(7, -3) 1 mgcd(-21, -91, 707) 7 So it has the properties that I believe it should have (yes, I know we don't agree on this). I am not sure I would extend it to rationals, although I don't feel strongly about this. This could be introduced elsewhere without changing what is done in fractions. Having two 'gcd's that return different results in some circumstances might be a source of confusion for some - but not more than already exists about what values the gcd should return :-) PS I just know that I am going to regret posting code 'on the hoof' - it's almost certain to be wrong :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 22:40:35 2014 From: report at bugs.python.org (Stefan Behnel) Date: Wed, 24 Sep 2014 20:40:35 +0000 Subject: [issue22486] Speed up fractions.gcd() Message-ID: <1411591235.17.0.168367966743.issue22486@psf.upfronthosting.co.za> New submission from Stefan Behnel: fractions.gcd() is required for normalising numerator and denominator of the Fraction data type. Some speed improvements were applied to Fraction in issue 22464, now the gcd() function takes up about half of the instantiation time in the benchmark in issue 22458, which makes it quite a heavy part of the overall Fraction computation time. The current implementation is def gcd(a, b): while b: a, b = b, a%b return a Reimplementing it in C would provide for much faster calculations. Here is a Cython version that simply drops the calculation loop into C as soon as the numbers are small enough to fit into a C long long int: def _gcd(a, b): # Try doing all computation in C space. If the numbers are too large # at the beginning, retry until they are small enough. cdef long long ai, bi while b: try: ai, bi = a, b except OverflowError: pass else: # switch to C loop while bi: ai, bi = bi, ai%bi return ai a, b = b, a%b return a It's substantially faster already because the values will either be small enough right from the start or quickly become so after a few iterations with Python objects. Further improvements should be possible with a dedicated PyLong implementation based on Lehmer's GCD algorithm: https://en.wikipedia.org/wiki/Lehmer_GCD_algorithm ---------- components: Library (Lib) messages: 227487 nosy: scoder priority: normal severity: normal status: open title: Speed up fractions.gcd() type: performance versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 22:51:54 2014 From: report at bugs.python.org (Stefan Behnel) Date: Wed, 24 Sep 2014 20:51:54 +0000 Subject: [issue22464] Speed up fractions implementation In-Reply-To: <1411407434.75.0.285038516488.issue22464@psf.upfronthosting.co.za> Message-ID: <1411591914.59.0.150096486767.issue22464@psf.upfronthosting.co.za> Stefan Behnel added the comment: I created issue 22486 about the gcd() performance. I think we can close this ticket - I don't see any more obvious low hanging fruit and future findings can have their own ticket. Out of interest, I modified the fractions module to compile Fraction into an extension type with Cython. For the benchmark, it currently gives me a 10x speedup over the original fractions module in Py3.4. I uploaded my initial attempt to PyPI and it's on github: https://pypi.python.org/pypi/quicktions https://github.com/scoder/quicktions That makes a C implementation of Fraction generally worth considering for CPython. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 23:37:14 2014 From: report at bugs.python.org (Ryan McCampbell) Date: Wed, 24 Sep 2014 21:37:14 +0000 Subject: [issue22487] ABC register doesn't check abstract methods Message-ID: <1411594634.83.0.710173363253.issue22487@psf.upfronthosting.co.za> New submission from Ryan McCampbell: Is there a reason register() doesn't check for abstract methods, like subclassing does? Would it fail for some builtin classes? It seems that this would be a better guarantee that, say, something really is iterable when you check isinstance(Collections.Iterable, o), since someone could have called Collections.Iterable.register(o.__class__) without adding an __iter__ method to their class. ---------- messages: 227489 nosy: rmccampbell7 priority: normal severity: normal status: open title: ABC register doesn't check abstract methods type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 24 23:41:32 2014 From: report at bugs.python.org (Ryan McCampbell) Date: Wed, 24 Sep 2014 21:41:32 +0000 Subject: [issue22487] ABC register doesn't check abstract methods In-Reply-To: <1411594634.83.0.710173363253.issue22487@psf.upfronthosting.co.za> Message-ID: <1411594892.71.0.308129657759.issue22487@psf.upfronthosting.co.za> Ryan McCampbell added the comment: Obviously, I meant isinstance(o, Collections.Iterable). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 00:00:59 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 24 Sep 2014 22:00:59 +0000 Subject: [issue22487] ABC register doesn't check abstract methods In-Reply-To: <1411594634.83.0.710173363253.issue22487@psf.upfronthosting.co.za> Message-ID: <1411596059.3.0.458437795037.issue22487@psf.upfronthosting.co.za> R. David Murray added the comment: Python is a consenting adults language. If you call register, we assume you know what you are doing. The isinstance check, on the other hand, does look in certain cases. So if you define __iter__ you don't have to call register to make isinstance(o, Iterable) be True. ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 00:50:58 2014 From: report at bugs.python.org (Aaron Meurer) Date: Wed, 24 Sep 2014 22:50:58 +0000 Subject: [issue21821] The function cygwinccompiler.is_cygwingcc leads to FileNotFoundError under Windows 7 In-Reply-To: <1403361356.73.0.508496637116.issue21821@psf.upfronthosting.co.za> Message-ID: <1411599058.68.0.824824334523.issue21821@psf.upfronthosting.co.za> Aaron Meurer added the comment: The issue is that that the Anaconda gcc on Windows is a bat file, so it can't find it. Another fix would be to use find_executable. This is because Anaconda has patched find_executalbe (which it also would be good to get backported) diff --git Lib/distutils/spawn.py Lib/distutils/spawn.py index b1c5a44..4703f00 100644 --- Lib/distutils/spawn.py +++ Lib/distutils/spawn.py @@ -156,17 +156,16 @@ def find_executable(executable, path=None): path = os.environ['PATH'] paths = path.split(os.pathsep) - base, ext = os.path.splitext(executable) - - if (sys.platform == 'win32') and (ext != '.exe'): - executable = executable + '.exe' - - if not os.path.isfile(executable): - for p in paths: - f = os.path.join(p, executable) - if os.path.isfile(f): - # the file exists, we have a shot at spawn working - return f - return None - else: - return executable + + for ext in '.exe', '.bat', '': + newexe = executable + ext + + if os.path.isfile(newexe): + return newexe + else: + for p in paths: + f = os.path.join(p, newexe) + if os.path.isfile(f): + # the file exists, we have a shot at spawn working + return f + return None ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 01:24:11 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 24 Sep 2014 23:24:11 +0000 Subject: [issue22488] 3.4 rc2 docs download link broken Message-ID: <1411601051.4.0.512661670113.issue22488@psf.upfronthosting.co.za> New submission from Senthil Kumaran: Reported by John Jeffers on docs mailing list. https://docs.python.org/3.4/download.html (3.4.2rc1) Return Error 404 (Your other pages are fine)! ---------- messages: 227493 nosy: larry, orsenthil priority: normal severity: normal status: open title: 3.4 rc2 docs download link broken _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 01:39:33 2014 From: report at bugs.python.org (Ned Deily) Date: Wed, 24 Sep 2014 23:39:33 +0000 Subject: [issue22488] 3.4 rc2 docs download link broken In-Reply-To: <1411601051.4.0.512661670113.issue22488@psf.upfronthosting.co.za> Message-ID: <1411601973.35.0.555147700637.issue22488@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Build doc archives for RC versions _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 01:43:18 2014 From: report at bugs.python.org (Ned Deily) Date: Wed, 24 Sep 2014 23:43:18 +0000 Subject: [issue22484] Build doc archives for RC versions, docs download broken for 3.4.2rc1 In-Reply-To: <1411582508.1.0.277862654649.issue22484@psf.upfronthosting.co.za> Message-ID: <1411602198.0.0.784169064929.issue22484@psf.upfronthosting.co.za> Ned Deily added the comment: This problem is currently resulting in 404's for 3.4.2rc1 documention downloads, e.g. the links on: https://docs.python.org/3.4/download.html ---------- nosy: +ned.deily priority: high -> critical title: Build doc archives for RC versions -> Build doc archives for RC versions, docs download broken for 3.4.2rc1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 02:23:24 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 25 Sep 2014 00:23:24 +0000 Subject: [issue22484] Build doc archives for RC versions, docs download broken for 3.4.2rc1 In-Reply-To: <1411582508.1.0.277862654649.issue22484@psf.upfronthosting.co.za> Message-ID: <20140925002312.123967.37125@mail.hg.python.org> Roundup Robot added the comment: New changeset 8ce21ffc6df5 by Benjamin Peterson in branch '3.4': allow archives for rc releases to be built (closes #22484) https://hg.python.org/cpython/rev/8ce21ffc6df5 New changeset 7d6297450943 by Benjamin Peterson in branch 'default': merge 3.4 (#22484) https://hg.python.org/cpython/rev/7d6297450943 New changeset 22a46f05ce23 by Benjamin Peterson in branch '2.7': allow archives for rc releases to be built (closes #22484) https://hg.python.org/cpython/rev/22a46f05ce23 ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 03:00:18 2014 From: report at bugs.python.org (Robert Collins) Date: Thu, 25 Sep 2014 01:00:18 +0000 Subject: [issue16662] load_tests not invoked in package/__init__.py In-Reply-To: <1355217291.85.0.41912767842.issue16662@psf.upfronthosting.co.za> Message-ID: <1411606818.27.0.760933186967.issue16662@psf.upfronthosting.co.za> Robert Collins added the comment: Fix up the tests patch - tested on windows 7. ---------- Added file: http://bugs.python.org/file36713/fix-windows-tests.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 03:01:04 2014 From: report at bugs.python.org (Robert Collins) Date: Thu, 25 Sep 2014 01:01:04 +0000 Subject: [issue16662] load_tests not invoked in package/__init__.py In-Reply-To: <1355217291.85.0.41912767842.issue16662@psf.upfronthosting.co.za> Message-ID: <1411606864.92.0.36153510279.issue16662@psf.upfronthosting.co.za> Robert Collins added the comment: bah, wrong extension to trigger review code :) ---------- Added file: http://bugs.python.org/file36714/fix-windows-tests.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 03:01:20 2014 From: report at bugs.python.org (Robert Collins) Date: Thu, 25 Sep 2014 01:01:20 +0000 Subject: [issue16662] load_tests not invoked in package/__init__.py In-Reply-To: <1355217291.85.0.41912767842.issue16662@psf.upfronthosting.co.za> Message-ID: <1411606880.91.0.736221923108.issue16662@psf.upfronthosting.co.za> Changes by Robert Collins : Removed file: http://bugs.python.org/file36713/fix-windows-tests.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 03:04:56 2014 From: report at bugs.python.org (Robert Collins) Date: Thu, 25 Sep 2014 01:04:56 +0000 Subject: [issue22489] .gitignore file Message-ID: <1411607096.09.0.0618020522514.issue22489@psf.upfronthosting.co.za> New submission from Robert Collins: The .gitignore file was missing some build products on windows. The attached patch makes the tree be clean after doing a debug build. ---------- files: windows-git-ignore.diff keywords: patch messages: 227498 nosy: rbcollins priority: normal severity: normal status: open title: .gitignore file Added file: http://bugs.python.org/file36715/windows-git-ignore.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 03:06:11 2014 From: report at bugs.python.org (Robert Collins) Date: Thu, 25 Sep 2014 01:06:11 +0000 Subject: [issue22457] load_tests not invoked in root __init__.py when start=package root In-Reply-To: <1411357674.43.0.0204872118136.issue22457@psf.upfronthosting.co.za> Message-ID: <1411607171.92.0.24901474082.issue22457@psf.upfronthosting.co.za> Robert Collins added the comment: Updated patch - fixes windows tests for this patch. ---------- Added file: http://bugs.python.org/file36716/issue22457.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 03:26:27 2014 From: report at bugs.python.org (Robert Collins) Date: Thu, 25 Sep 2014 01:26:27 +0000 Subject: [issue19746] No introspective way to detect ModuleImportFailure in unittest In-Reply-To: <1385262963.63.0.210713286499.issue19746@psf.upfronthosting.co.za> Message-ID: <1411608387.07.0.973130478505.issue19746@psf.upfronthosting.co.za> Robert Collins added the comment: Right: the existing code stringifies the original exception and creates an exception object and a closure def test_thing(self): raise exception_obj but that has the stringified original exception. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 04:02:14 2014 From: report at bugs.python.org (karl) Date: Thu, 25 Sep 2014 02:02:14 +0000 Subject: [issue5550] [urllib.request]: Comparison of HTTP headers should be insensitive to the case In-Reply-To: <1237870141.83.0.616869799184.issue5550@psf.upfronthosting.co.za> Message-ID: <1411610534.63.0.838690232558.issue5550@psf.upfronthosting.co.za> karl added the comment: OK after fixing my repo (Thanks orsenthil) I got the tests running properly. The inspection order of the two dictionary was not right, so I had to modify a bit the patch. ? ./python.exe -m unittest -v Lib.test.test_urllib2net.OtherNetworkTests.test_headers_case_sensitivity test_headers_case_sensitivity (Lib.test.test_urllib2net.OtherNetworkTests) ... ok ---------------------------------------------------------------------- Ran 1 test in 0.286s OK ? ./python.exe -m unittest -v Lib.test.test_urllib2net.OtherNetworkTests.test_custom_headers test_custom_headers (Lib.test.test_urllib2net.OtherNetworkTests) ... ok ---------------------------------------------------------------------- Ran 1 test in 0.575s OK New patch issue5550-5.patch unlinking issue5550-4.patch ---------- Added file: http://bugs.python.org/file36717/issue5550-5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 04:02:28 2014 From: report at bugs.python.org (karl) Date: Thu, 25 Sep 2014 02:02:28 +0000 Subject: [issue5550] [urllib.request]: Comparison of HTTP headers should be insensitive to the case In-Reply-To: <1237870141.83.0.616869799184.issue5550@psf.upfronthosting.co.za> Message-ID: <1411610548.18.0.153094291238.issue5550@psf.upfronthosting.co.za> Changes by karl : Removed file: http://bugs.python.org/file36698/issue-5550-4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 05:33:19 2014 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 25 Sep 2014 03:33:19 +0000 Subject: [issue21566] make use of the new default socket.listen() backlog argument In-Reply-To: <1400880411.34.0.235990435925.issue21566@psf.upfronthosting.co.za> Message-ID: <1411615999.99.0.354631228254.issue21566@psf.upfronthosting.co.za> Yury Selivanov added the comment: Guys, when you update asyncio code, please make sure you sync your changes with its upstream here: https://code.google.com/p/tulip/ to avoid commits like this 5f001ad90373 The goal is to have single source base for 3.4 and 3.5 in cpython repo and for 3.3 in tulip repo, to simplify syncing updates between them. ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 05:42:00 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 25 Sep 2014 03:42:00 +0000 Subject: [issue21645] asyncio: Race condition in signal handling on FreeBSD In-Reply-To: <1401748554.93.0.147613682728.issue21645@psf.upfronthosting.co.za> Message-ID: <20140925034153.91828.44674@mail.hg.python.org> Roundup Robot added the comment: New changeset fe456770b454 by Yury Selivanov in branch 'default': asyncio: Reverting 69d474dab479 as issue #21645 is now closed and debug is no longer needed https://hg.python.org/cpython/rev/fe456770b454 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 05:59:35 2014 From: report at bugs.python.org (Ned Deily) Date: Thu, 25 Sep 2014 03:59:35 +0000 Subject: [issue22489] .gitignore file In-Reply-To: <1411607096.09.0.0618020522514.issue22489@psf.upfronthosting.co.za> Message-ID: <1411617575.42.0.308741569363.issue22489@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 06:12:40 2014 From: report at bugs.python.org (karl) Date: Thu, 25 Sep 2014 04:12:40 +0000 Subject: [issue15799] httplib client and statusline In-Reply-To: <1346185891.22.0.123491218752.issue15799@psf.upfronthosting.co.za> Message-ID: <1411618360.59.0.56922129773.issue15799@psf.upfronthosting.co.za> karl added the comment: Let's close this. >>> "HTTP/1.1 301 ".split(None, 2) ['HTTP/1.1', '301'] >>> "HTTP/1.1 301 ".split(' ', 2) ['HTTP/1.1', '', ' 301 '] I think it would be nice to have a way to warn without stopping, but the last comment from r.david.murray makes sense too. :) ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 07:30:45 2014 From: report at bugs.python.org (Tim Smith) Date: Thu, 25 Sep 2014 05:30:45 +0000 Subject: [issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew installs fragile Message-ID: <1411623045.52.0.589017779939.issue22490@psf.upfronthosting.co.za> New submission from Tim Smith: Homebrew, the OS X package manager, distributes python3 as a framework build. We like to be able to control the shebang that gets written to scripts installed with pip. [1] The path we prefer for invoking the python3 interpreter is like /usr/local/opt/python3/bin/python3.4, which is symlinked to the framework stub launcher at /usr/local/Cellar/python3/3.4.1_1/Frameworks/Python.framework/Versions/3.4/bin/python3.4. For Python 2.x, we discovered that assigning "/usr/local/opt/python/bin/python2.7" to sys.executable in sitecustomize.py resulted in correct shebangs for scripts installed by pip. The same approach doesn't work with Python 3. A very helpful conversation with Vinay Sajip [2] led us to consider how the python3 stub launcher sets __PYVENV_LAUNCHER__, which distlib uses in preference to sys.executable to discover the intended interpreter when pip writes shebangs. Roughly, __PYVENV_LAUNCHER__ is set from argv[0], so it mimics the invocation of the stub, except that symlinks in the directory component of the path to the identified interpreter are resolved to a "real" path. For us, this means that __PYVENV_LAUNCHER__ (and therefore the shebangs of installed scripts) always points to the Cellar path, not the preferred opt path, even when python is invoked via the opt path. Avoiding this symlink resolution would allow us to control pip's shebang (which sets the shebangs of all pip-installed scripts) by controlling the way we invoke python3 when we use ensurepip during installation. Building python3 with the attached diff removes the symlink resolution. [1] This is important to Homebrew because packages are physically installed to versioned prefixes, like /usr/local/Cellar/python3/3.4.1_1/. References to these real paths are fragile and break when the version number changes or when the revision number ("_1") changes, when can happen when e.g. openssl is released and Python needs to be recompiled against the new library. To avoid this breakage, Homebrew maintains a version-independent symlink to each package, like /usr/local/opt/python3, which points to the .../Cellar/python3/3.4.1_1/ location. [2] https://github.com/pypa/pip/issues/2031 ---------- assignee: ronaldoussoren components: Macintosh files: dont-realpath-venv-dirname.diff keywords: patch messages: 227505 nosy: ned.deily, ronaldoussoren, tdsmith, vinay.sajip priority: normal severity: normal status: open title: Using realpath for __PYVENV_LAUNCHER__ makes Homebrew installs fragile type: behavior versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file36718/dont-realpath-venv-dirname.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 07:55:44 2014 From: report at bugs.python.org (karl) Date: Thu, 25 Sep 2014 05:55:44 +0000 Subject: [issue17319] http.server.BaseHTTPRequestHandler send_response_only doesn't check the type and value of the code. In-Reply-To: <1362024725.4.0.923647295599.issue17319@psf.upfronthosting.co.za> Message-ID: <1411624544.54.0.0883736496666.issue17319@psf.upfronthosting.co.za> karl added the comment: Where this is defined in the new RFC. http://tools.ietf.org/html/rfc7230#section-3.1.2 status-line = HTTP-version SP status-code SP reason-phrase CRLF Things to enforce status-code = 3DIGIT Response status code are now defined in http://tools.ietf.org/html/rfc7231#section-6 with something important. HTTP status codes are extensible. HTTP clients are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, a client MUST understand the class of any status code, as indicated by the first digit, and treat an unrecognized status code as being equivalent to the x00 status code of that class, with the exception that a recipient MUST NOT cache a response with an unrecognized status code. For example, if an unrecognized status code of 471 is received by a client, the client can assume that there was something wrong with its request and treat the response as if it had received a 400 (Bad Request) status code. The response message will usually contain a representation that explains the status. That should help. The full registry of status code is defined here http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml @dmi.baranov In the patch +def _is_valid_status_code(code): + return isinstance(code, int) and 0 <= code <= 999 Maybe there is a missing check where the len(str(code)) == 3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 08:22:43 2014 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 25 Sep 2014 06:22:43 +0000 Subject: [issue22486] Speed up fractions.gcd() In-Reply-To: <1411591235.17.0.168367966743.issue22486@psf.upfronthosting.co.za> Message-ID: <1411626163.51.0.989151010899.issue22486@psf.upfronthosting.co.za> Mark Dickinson added the comment: In case it's useful, see issue #1682 for my earlier Lehmer gcd implementation. At the time, that approach was dropped as being premature optimisation. ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 08:56:27 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 25 Sep 2014 06:56:27 +0000 Subject: [issue22491] Support Unicode line boundaries in regular expression Message-ID: <1411628187.04.0.177569242065.issue22491@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Currently regular expressions support on '\n' as line boundary. To meet Unicode standard requirement RL1.6 [1] all Unicode line separators should be supported: '\n', '\r', '\v', '\f', '\x85', '\u2028', '\u2029' and two-character '\r\n'. Also it is recommended that '.' in "dotall" mode matches '\r\n'. Also strongly recommended to support the '\R' pattern which matches all line separators (equivalent to '(?:\\r\n|(?!\r\n)[\n\v\f\r\x85\u2028\u2029]'). >>> [m.start() for m in re.finditer('$', '\r\n\n\r', re.M)] [1, 2, 4] # should be [0, 2, 3, 4] >>> [m.start() for m in re.finditer('^', '\r\n\n\r', re.M)] [0, 2, 3] # should be [0, 2, 3, 4] >>> [m.group() for m in re.finditer('.', '\r\n\n\r', re.M|re.S)] ['\r', '\n', '\n', '\r'] # should be ['\r\n', '\n', '\r'] >>> [m.group() for m in re.finditer(r'\R', '\r\n\n\r')] [] # should be ['\r\n', '\n', '\r'] [1] http://www.unicode.org/reports/tr18/#RL1.6 ---------- components: Extension Modules, Regular Expressions messages: 227508 nosy: ezio.melotti, mrabarnett, pitrou, serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: Support Unicode line boundaries in regular expression type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 09:02:28 2014 From: report at bugs.python.org (Georg Brandl) Date: Thu, 25 Sep 2014 07:02:28 +0000 Subject: [issue22492] small addition to print() docs: no binary streams. Message-ID: <1411628548.86.0.942026388969.issue22492@psf.upfronthosting.co.za> New submission from Georg Brandl: This is implicit in the "converts arguments to strings", but people might reasonably expect that print(x, file=y) is the same as y.write(x) for strings and bytes. This paragraph makes it clear. ---------- files: print_binary.diff keywords: patch messages: 227509 nosy: georg.brandl priority: normal severity: normal status: open title: small addition to print() docs: no binary streams. Added file: http://bugs.python.org/file36719/print_binary.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 09:04:02 2014 From: report at bugs.python.org (Robert Collins) Date: Thu, 25 Sep 2014 07:04:02 +0000 Subject: [issue22264] Add wsgiref.util.dump_wsgistr & load_wsgistr In-Reply-To: <1408884341.89.0.273491669506.issue22264@psf.upfronthosting.co.za> Message-ID: <1411628642.22.0.712198102165.issue22264@psf.upfronthosting.co.za> Robert Collins added the comment: So this looks like its going to instantly create bugs in programs that use it. HTTP/1.1 headers are one of: latin1 MIME encoded (RFC2047) invalid and working only by accident HTTP/2 doesn't change this. An API that encourages folk to encode into utf8 and then put that in their headers is problematic. Consider: def dump_wsgistr(data, encoding, errors='strict'): data.encode(encoding, errors).decode('iso-8859-1') This takes a string that one wants to put into a header value, encodes it with a *user specified encoding*, then decodes that into iso-8859-1 [at which point it can be encoded back to octets by the wsgi server before putting on the wire]. But this is fundamentally wrong in the common case: either 'data' is itself suitable as a header value (e.g. it is ASCII - recommended per RFC7230 section 3.2.4) or 'data' needs encoding via RFC 2047 encoding not via utf8. There are a few special cases where folk have incorrectly shoved utf8 into header values and we need to make it possible for folk working within WSGI to do that - which is why the API is the way it is - but we shouldn't make it *easier* for them to do the wrong thing. I'd support an API that DTRT here by taking a string, tries US_ASCII, with fallback to MIME encoded with utf8 as the encoding parameter. ---------- nosy: +rbcollins _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 09:25:17 2014 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 25 Sep 2014 07:25:17 +0000 Subject: [issue22264] Add wsgiref.util.dump_wsgistr & load_wsgistr In-Reply-To: <1408884341.89.0.273491669506.issue22264@psf.upfronthosting.co.za> Message-ID: <1411629917.21.0.0849954808304.issue22264@psf.upfronthosting.co.za> Nick Coghlan added the comment: I'm not wedded to the specific algorithm - I definitely don't consider myself an HTTP or WSGI expert. I do like the general idea of treating "wsgistr" as a serialisation format though, as that's effectively what it is at this point. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 09:25:47 2014 From: report at bugs.python.org (theme) Date: Thu, 25 Sep 2014 07:25:47 +0000 Subject: [issue12946] PyModule_GetDict() claims it can never fail, but it can In-Reply-To: <1315585192.34.0.742122652176.issue12946@psf.upfronthosting.co.za> Message-ID: <1411629947.33.0.083158473938.issue12946@psf.upfronthosting.co.za> Changes by theme : ---------- versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 09:33:18 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 25 Sep 2014 07:33:18 +0000 Subject: [issue12946] PyModule_GetDict() claims it can never fail, but it can In-Reply-To: <1315585192.34.0.742122652176.issue12946@psf.upfronthosting.co.za> Message-ID: <1411630398.0.0.71339139477.issue12946@psf.upfronthosting.co.za> STINNER Victor added the comment: > I gave two reasons why this function can fail, and one turns out to be assumed-to-be-dead code. If the call to PyDict_New() is never called, the test can be replaced with an assertion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 09:51:34 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 25 Sep 2014 07:51:34 +0000 Subject: [issue18093] Move main functions to a separate Programs directory In-Reply-To: <1369828290.2.0.750301008205.issue18093@psf.upfronthosting.co.za> Message-ID: <1411631494.98.0.73281150803.issue18093@psf.upfronthosting.co.za> STINNER Victor added the comment: _testembed was moved from Modules to Programs but test_capi was not updated: it still looks for test_embed in Modules. $ ./configure --with-pydebug $ make $ ./python -m test -v test_capi ... test_forced_io_encoding (test.test_capi.EmbeddingTests) ... skipped "'/home/haypo/prog/python/default/Modules/_testembed' doesn't exist" test_subinterps (test.test_capi.EmbeddingTests) ... skipped "'/home/haypo/prog/python/default/Modules/_testembed' doesn't exist" ... ---------- nosy: +haypo resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 10:20:01 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 25 Sep 2014 08:20:01 +0000 Subject: [issue18093] Move main functions to a separate Programs directory In-Reply-To: <1369828290.2.0.750301008205.issue18093@psf.upfronthosting.co.za> Message-ID: <1411633201.31.0.0633605618663.issue18093@psf.upfronthosting.co.za> STINNER Victor added the comment: test_capi.patch fixes test_capi to be able to run _testembed in test_capi. ---------- Added file: http://bugs.python.org/file36720/test_capi.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 10:24:40 2014 From: report at bugs.python.org (Ned Deily) Date: Thu, 25 Sep 2014 08:24:40 +0000 Subject: [issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew installs fragile In-Reply-To: <1411623045.52.0.589017779939.issue22490@psf.upfronthosting.co.za> Message-ID: <1411633480.46.0.244743492883.issue22490@psf.upfronthosting.co.za> Ned Deily added the comment: >From the initial description of the problem, it's not clear to me that there is a problem here needing resolution in the stub launcher. I've asked for clarification on the pip issue tracker. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 11:02:26 2014 From: report at bugs.python.org (James Spurin) Date: Thu, 25 Sep 2014 09:02:26 +0000 Subject: [issue17835] test_io broken on PPC64 Linux In-Reply-To: <1366830173.09.0.170493348126.issue17835@psf.upfronthosting.co.za> Message-ID: <1411635746.76.0.680205288566.issue17835@psf.upfronthosting.co.za> James Spurin added the comment: fcntl doesnt seem to like the parameter you mentioned - # cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.5 (Santiago) # /local/0/opt/python-3.4.1/bin/python Python 3.4.1 (default, Sep 24 2014, 12:23:21) [GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import fcntl, os >>> r, w = os.pipe() >>> fcntl.fcntl(w, 1032) Traceback (most recent call last): File "", line 1, in OSError: [Errno 22] Invalid argument >>> ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 11:02:41 2014 From: report at bugs.python.org (Ned Deily) Date: Thu, 25 Sep 2014 09:02:41 +0000 Subject: [issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew installs fragile In-Reply-To: <1411623045.52.0.589017779939.issue22490@psf.upfronthosting.co.za> Message-ID: <1411635761.81.0.257706299078.issue22490@psf.upfronthosting.co.za> Ned Deily added the comment: Also, the patch causes a test failure with a framework build: ====================================================================== FAIL: test_defaults (test.test_venv.BasicTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/py/dev/3x/root/fwd/Library/Frameworks/pytest_10.9.framework/Versions/3.5/lib/python3.5/test/test_venv.py", line 106, in test_defaults self.assertIn('home = %s' % path, data) AssertionError: 'home = /py/dev/3x/root/fwd/./bin' not found in 'home = /py/dev/3x/root/fwd/bin\ninclude-system-site-packages = false\nversion = 3.5.0\n' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 11:48:40 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 25 Sep 2014 09:48:40 +0000 Subject: [issue18093] Move main functions to a separate Programs directory In-Reply-To: <1369828290.2.0.750301008205.issue18093@psf.upfronthosting.co.za> Message-ID: <20140925094832.84025.75884@mail.hg.python.org> Roundup Robot added the comment: New changeset c87e00a6258d by Nick Coghlan in branch 'default': Issue #18093: fix test_capi test skip due to _testembed move https://hg.python.org/cpython/rev/c87e00a6258d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 11:49:27 2014 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 25 Sep 2014 09:49:27 +0000 Subject: [issue18093] Move main functions to a separate Programs directory In-Reply-To: <1369828290.2.0.750301008205.issue18093@psf.upfronthosting.co.za> Message-ID: <1411638567.63.0.595297465563.issue18093@psf.upfronthosting.co.za> Nick Coghlan added the comment: Thanks for spotting that Victor - should be fixed by that last commit with your change. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 12:28:23 2014 From: report at bugs.python.org (July Tikhonov) Date: Thu, 25 Sep 2014 10:28:23 +0000 Subject: [issue19717] resolve() fails when the path doesn't exist In-Reply-To: <1385142353.37.0.842056066182.issue19717@psf.upfronthosting.co.za> Message-ID: <1411640903.65.0.40267296396.issue19717@psf.upfronthosting.co.za> Changes by July Tikhonov : ---------- nosy: +july _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 12:29:00 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 25 Sep 2014 10:29:00 +0000 Subject: [issue22493] Deprecate the use of flags not at the start of regular expression Message-ID: <1411640940.81.0.804351058131.issue22493@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: The meaning of inline flags not at the start of regular expression is ambiguous. Current re implementation and regex in the V0 mode enlarge the scope to all expression. In V1 mode in regex they affect only the end of the expression. I propose to deprecate (and then forbid in 3.7) the use of inline flags not at the start of regular expression. This will help to change the meaning of inline flags in the middle of the expression in future (in 3.8 or later). ---------- components: Library (Lib), Regular Expressions files: re_deprecate_nonstart_flags.patch keywords: patch messages: 227520 nosy: ezio.melotti, mrabarnett, pitrou, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Deprecate the use of flags not at the start of regular expression type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file36721/re_deprecate_nonstart_flags.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 12:42:32 2014 From: report at bugs.python.org (Sean Dague) Date: Thu, 25 Sep 2014 10:42:32 +0000 Subject: [issue22494] default logging time string is not localized Message-ID: <1411641752.05.0.384907346066.issue22494@psf.upfronthosting.co.za> New submission from Sean Dague: The default time string is not localized for using locale specific formatting, but is instead hardcoded to a ','. https://hg.python.org/cpython/file/c87e00a6258d/Lib/logging/__init__.py#l483 demonstrates this. Instead I think we should set that to the value of: locale.localeconv()['decimal_point'] While this clearly a very minor issue, I stare at enough logging output data that falls back to default formats (due to testing environments) that would love for this to be locale aware. ---------- components: Library (Lib) messages: 227521 nosy: sdague priority: normal severity: normal status: open title: default logging time string is not localized type: behavior versions: 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 Sep 25 12:44:23 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 25 Sep 2014 10:44:23 +0000 Subject: [issue22486] Speed up fractions.gcd() In-Reply-To: <1411591235.17.0.168367966743.issue22486@psf.upfronthosting.co.za> Message-ID: <1411641863.3.0.437342831475.issue22486@psf.upfronthosting.co.za> Antoine Pitrou added the comment: If Python grows an optimized implementation, how about exposing it in the math module? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 13:04:06 2014 From: report at bugs.python.org (Matthew Barnett) Date: Thu, 25 Sep 2014 11:04:06 +0000 Subject: [issue22491] Support Unicode line boundaries in regular expression In-Reply-To: <1411628187.04.0.177569242065.issue22491@psf.upfronthosting.co.za> Message-ID: <1411643046.88.0.348272876559.issue22491@psf.upfronthosting.co.za> Matthew Barnett added the comment: For reference, the regex module normally considers the line ending to be '\n', but it has a WORD flag ('(?w)') that turns on the Unicode definition of a 'word' character as well as Unicode line separator. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 13:06:32 2014 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 25 Sep 2014 11:06:32 +0000 Subject: [issue22486] Speed up fractions.gcd() In-Reply-To: <1411591235.17.0.168367966743.issue22486@psf.upfronthosting.co.za> Message-ID: <1411643192.33.0.944092912356.issue22486@psf.upfronthosting.co.za> Mark Dickinson added the comment: > If Python grows an optimized implementation, how about exposing it in the math module? +1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 13:28:37 2014 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 25 Sep 2014 11:28:37 +0000 Subject: [issue22486] Speed up fractions.gcd() In-Reply-To: <1411591235.17.0.168367966743.issue22486@psf.upfronthosting.co.za> Message-ID: <1411644517.14.0.642607168828.issue22486@psf.upfronthosting.co.za> Stefan Behnel added the comment: That's what the patch does anyway. +1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 13:35:37 2014 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 25 Sep 2014 11:35:37 +0000 Subject: [issue22477] GCD in Fractions In-Reply-To: <1411543502.18.0.966419857361.issue22477@psf.upfronthosting.co.za> Message-ID: <1411644937.46.0.825502498065.issue22477@psf.upfronthosting.co.za> Stefan Behnel added the comment: Also see issue 22486. There is an unmerged C implementation in the old issue 1682 that would go into the math module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 13:45:52 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 25 Sep 2014 11:45:52 +0000 Subject: [issue22486] Speed up fractions.gcd() In-Reply-To: <1411591235.17.0.168367966743.issue22486@psf.upfronthosting.co.za> Message-ID: <1411645552.36.0.968917804805.issue22486@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Hmm... which patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 13:49:27 2014 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 25 Sep 2014 11:49:27 +0000 Subject: [issue22486] Speed up fractions.gcd() In-Reply-To: <1411591235.17.0.168367966743.issue22486@psf.upfronthosting.co.za> Message-ID: <1411645767.28.0.62176014279.issue22486@psf.upfronthosting.co.za> Stefan Behnel added the comment: http://bugs.python.org/file9486/lehmer_gcd.patch (see #1682) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 13:53:29 2014 From: report at bugs.python.org (Wolfgang Maier) Date: Thu, 25 Sep 2014 11:53:29 +0000 Subject: [issue22486] Speed up fractions.gcd() In-Reply-To: <1411591235.17.0.168367966743.issue22486@psf.upfronthosting.co.za> Message-ID: <1411646009.76.0.340759828563.issue22486@psf.upfronthosting.co.za> Changes by Wolfgang Maier : ---------- nosy: +wolma _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 13:53:54 2014 From: report at bugs.python.org (Wolfgang Maier) Date: Thu, 25 Sep 2014 11:53:54 +0000 Subject: [issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up. In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za> Message-ID: <1411646034.28.0.869432146645.issue1682@psf.upfronthosting.co.za> Changes by Wolfgang Maier : ---------- nosy: +wolma _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 14:20:57 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 25 Sep 2014 12:20:57 +0000 Subject: [issue22486] Add math.gcd() In-Reply-To: <1411591235.17.0.168367966743.issue22486@psf.upfronthosting.co.za> Message-ID: <1411647657.67.0.706970180547.issue22486@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is updated Mark's patch from issue1682. It is ported to 3.5, slightly simplified and optimized (I did not touched the main algorithm still), utilized in the fractions module, added tests and documentation. It speeds up Stefan's fractions benchmark about 20%. ---------- components: +Extension Modules nosy: +serhiy.storchaka stage: -> patch review title: Speed up fractions.gcd() -> Add math.gcd() type: performance -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 14:23:04 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 25 Sep 2014 12:23:04 +0000 Subject: [issue22486] Add math.gcd() In-Reply-To: <1411591235.17.0.168367966743.issue22486@psf.upfronthosting.co.za> Message-ID: <1411647784.96.0.301939816871.issue22486@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +patch Added file: http://bugs.python.org/file36722/lehmer_gcd_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 14:27:44 2014 From: report at bugs.python.org (Wolfgang Maier) Date: Thu, 25 Sep 2014 12:27:44 +0000 Subject: [issue22495] merge large parts of test_binop.py and test_fractions.py Message-ID: <1411648064.39.0.863179207441.issue22495@psf.upfronthosting.co.za> New submission from Wolfgang Maier: test_binop.py says that it tests binary operators on subtypes of built-in types, but in fact largely focuses on testing its own class Rat, which simply inherits from object and is, essentially, just a simple implementation of fractions.Fraction. Instead of doing mostly redundant tests here and there it might be better to merge this part (up to line 305) of test_binop.py into test_fractions.py, then maybe add tests of subtypes of built-in types other than just object to test_binop.py. This requires quite a bit of work though for a relatively minor improvement so do you think it's worth the effort ? ---------- components: Tests messages: 227530 nosy: wolma priority: normal severity: normal status: open title: merge large parts of test_binop.py and test_fractions.py type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 14:29:40 2014 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 25 Sep 2014 12:29:40 +0000 Subject: [issue22486] Add math.gcd() In-Reply-To: <1411591235.17.0.168367966743.issue22486@psf.upfronthosting.co.za> Message-ID: <1411648180.94.0.693986002795.issue22486@psf.upfronthosting.co.za> Stefan Behnel added the comment: The problem is that this changes the behaviour of fractions.gcd() w.r.t. negative numbers. It's a public function, so we should keep it for backwards compatibility reasons, *especially* when adding a new function in the math module. ---------- components: -Extension Modules type: enhancement -> performance _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 14:32:36 2014 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 25 Sep 2014 12:32:36 +0000 Subject: [issue22486] Add math.gcd() In-Reply-To: <1411591235.17.0.168367966743.issue22486@psf.upfronthosting.co.za> Message-ID: <1411648356.34.0.430779166433.issue22486@psf.upfronthosting.co.za> Stefan Behnel added the comment: Oh, and thanks for working on it, Serhiy! :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 14:36:23 2014 From: report at bugs.python.org (Wolfgang Maier) Date: Thu, 25 Sep 2014 12:36:23 +0000 Subject: [issue22486] Add math.gcd() In-Reply-To: <1411591235.17.0.168367966743.issue22486@psf.upfronthosting.co.za> Message-ID: <1411648583.41.0.428387060945.issue22486@psf.upfronthosting.co.za> Wolfgang Maier added the comment: see issue22477 for a discussion of whether the behavior of fractions.gcd should be changed or not ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 14:38:48 2014 From: report at bugs.python.org (Wolfgang Maier) Date: Thu, 25 Sep 2014 12:38:48 +0000 Subject: [issue22486] Add math.gcd() In-Reply-To: <1411591235.17.0.168367966743.issue22486@psf.upfronthosting.co.za> Message-ID: <1411648728.23.0.77068786366.issue22486@psf.upfronthosting.co.za> Wolfgang Maier added the comment: sorry, forgot to format the link: issue<22477> ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 14:48:48 2014 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 25 Sep 2014 12:48:48 +0000 Subject: [issue22486] Add math.gcd() In-Reply-To: <1411591235.17.0.168367966743.issue22486@psf.upfronthosting.co.za> Message-ID: <1411649327.99.0.793669577778.issue22486@psf.upfronthosting.co.za> Stefan Behnel added the comment: The thing is, if we add something new in a substantially more exposed place (the math module), then why break legacy code *in addition*? Just leaving it the way it is won't harm anyone, really. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 14:51:00 2014 From: report at bugs.python.org (Wolfgang Maier) Date: Thu, 25 Sep 2014 12:51:00 +0000 Subject: [issue22486] Add math.gcd() In-Reply-To: <1411591235.17.0.168367966743.issue22486@psf.upfronthosting.co.za> Message-ID: <1411649460.44.0.657859734544.issue22486@psf.upfronthosting.co.za> Wolfgang Maier added the comment: I wasn't arguing for or against anything, just providing a link to the relevant discussion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 14:53:53 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 25 Sep 2014 12:53:53 +0000 Subject: [issue22486] Add math.gcd() In-Reply-To: <1411648180.94.0.693986002795.issue22486@psf.upfronthosting.co.za> Message-ID: <2084542.SJV8BrRlYi@raxxla> Serhiy Storchaka added the comment: Well, here is a patch which keeps the same weird behavior of fractions.gcd(). ---------- Added file: http://bugs.python.org/file36723/lehmer_gcd_5.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r e9d4288c32de Doc/library/math.rst --- a/Doc/library/math.rst Wed Sep 24 13:29:27 2014 +0300 +++ b/Doc/library/math.rst Thu Sep 25 15:51:26 2014 +0300 @@ -100,6 +100,14 @@ Number-theoretic and representation func `_\. +.. function:: gcd(a, b) + + Return the greatest common divisor of the integers *a* and *b*. If either + *a* or *b* is nonzero, then the value of ``gcd(a, b)`` is the largest + positive integer that divides both *a* and *b*. ``gcd(0, 0)`` returns + ``0``. + + .. function:: isfinite(x) Return ``True`` if *x* is neither an infinity nor a NaN, and diff -r e9d4288c32de Include/longobject.h --- a/Include/longobject.h Wed Sep 24 13:29:27 2014 +0300 +++ b/Include/longobject.h Thu Sep 25 15:51:26 2014 +0300 @@ -198,6 +198,9 @@ PyAPI_FUNC(int) _PyLong_FormatAdvancedWr PyAPI_FUNC(unsigned long) PyOS_strtoul(const char *, char **, int); PyAPI_FUNC(long) PyOS_strtol(const char *, char **, int); +/* For use by the gcd function in mathmodule.c */ +PyAPI_FUNC(PyObject *) _PyLong_GCD(PyObject *, PyObject *); + #ifdef __cplusplus } #endif diff -r e9d4288c32de Lib/fractions.py --- a/Lib/fractions.py Wed Sep 24 13:29:27 2014 +0300 +++ b/Lib/fractions.py Thu Sep 25 15:51:26 2014 +0300 @@ -20,9 +20,9 @@ def gcd(a, b): Unless b==0, the result will have the same sign as b (so that when b is divided by it, the result comes out positive). """ - while b: - a, b = b, a%b - return a + if (b or a) < 0: + return -math.gcd(a, b) + return math.gcd(a, b) # Constants related to the hash implementation; hash(x) is based # on the reduction of x modulo the prime _PyHASH_MODULUS. @@ -174,9 +174,12 @@ class Fraction(numbers.Rational): if denominator == 0: raise ZeroDivisionError('Fraction(%s, 0)' % numerator) if _normalize: - g = gcd(numerator, denominator) + g = math.gcd(numerator, denominator) numerator //= g denominator //= g + if denominator < 0: + numerator = -numerator + denominator = -denominator self._numerator = numerator self._denominator = denominator return self diff -r e9d4288c32de Lib/test/test_math.py --- a/Lib/test/test_math.py Wed Sep 24 13:29:27 2014 +0300 +++ b/Lib/test/test_math.py Thu Sep 25 15:51:26 2014 +0300 @@ -595,6 +595,24 @@ class MathTests(unittest.TestCase): s = msum(vals) self.assertEqual(msum(vals), math.fsum(vals)) + def testGcd(self): + self.assertEqual(gcd(0, 0), 0) + self.assertEqual(gcd(1, 0), 1) + self.assertEqual(gcd(-1, 0), 1) + self.assertEqual(gcd(0, 1), 1) + self.assertEqual(gcd(0, -1), 1) + self.assertEqual(gcd(7, 1), 1) + self.assertEqual(gcd(7, -1), 1) + self.assertEqual(gcd(-23, 15), 1) + self.assertEqual(gcd(120, 84), 12) + self.assertEqual(gcd(84, -120), 12) + self.assertEqual(gcd(190738355881570558882299312308821696901058000, + 76478560266291874249006856460326062498333440), + 652560) + self.assertEqual(gcd(83763289342793979220453055528167457860243376086879213707165435635135627040075, + 33585776402955145260404154387726204875807368546078094789530226423049489520976), + 286573572687563623189610484223662247799) + def testHypot(self): self.assertRaises(TypeError, math.hypot) self.ftest('hypot(0,0)', math.hypot(0,0), 0) diff -r e9d4288c32de Modules/mathmodule.c --- a/Modules/mathmodule.c Wed Sep 24 13:29:27 2014 +0300 +++ b/Modules/mathmodule.c Thu Sep 25 15:51:26 2014 +0300 @@ -656,6 +656,22 @@ m_log10(double x) } +static PyObject * +math_gcd(PyObject *self, PyObject *args) +{ + PyObject *a, *b; + + if (!PyArg_ParseTuple(args, "O!O!:gcd", &PyLong_Type, &a, &PyLong_Type, &b)) + return NULL; + + return _PyLong_GCD(a, b); +} + +PyDoc_STRVAR(math_gcd_doc, +"gcd(x, y) -> int\n\ +greatest common divisor of x and y"); + + /* Call is_error when errno != 0, and where x is the result libm * returned. is_error will usually set up an exception and return * true (1), but may return false (0) without setting up an exception. @@ -1958,6 +1974,7 @@ static PyMethodDef math_methods[] = { {"frexp", math_frexp, METH_O, math_frexp_doc}, {"fsum", math_fsum, METH_O, math_fsum_doc}, {"gamma", math_gamma, METH_O, math_gamma_doc}, + {"gcd", math_gcd, METH_VARARGS, math_gcd_doc}, {"hypot", math_hypot, METH_VARARGS, math_hypot_doc}, {"isfinite", math_isfinite, METH_O, math_isfinite_doc}, {"isinf", math_isinf, METH_O, math_isinf_doc}, diff -r e9d4288c32de Objects/longobject.c --- a/Objects/longobject.c Wed Sep 24 13:29:27 2014 +0300 +++ b/Objects/longobject.c Thu Sep 25 15:51:26 2014 +0300 @@ -4327,6 +4327,188 @@ long_long(PyObject *v) return v; } +static PyLongObject * +long_gcd(PyLongObject *a, PyLongObject *b) +{ + PyLongObject *c, *d; + stwodigits x, y, q, s, t, c_carry, d_carry; + digit A, B, C, D; + int nbits, k; + Py_ssize_t size_a, size_b; + digit *a_digit, *b_digit, *c_digit, *d_digit, *a_end, *b_end; + + /* Initial reduction: make sure that 0 <= b <= a. */ + a = (PyLongObject *)long_abs(a); + b = (PyLongObject *)long_abs(b); + if (long_compare(a, b) < 0) { + d = a; + a = b; + b = d; + } + /* We now own references to a and b */ + + /* reduce until a fits into 2 digits */ + while ((size_a = Py_SIZE(a)) > 2) { + nbits = bits_in_digit(a->ob_digit[size_a-1]); + /* extract top 2*PyLong_SHIFT bits of a into x, along with + corresponding bits of b into y */ + size_b = Py_SIZE(b); + x = ((a->ob_digit[size_a-1] << (2*PyLong_SHIFT-nbits)) | + (a->ob_digit[size_a-2] << (PyLong_SHIFT-nbits)) | + (a->ob_digit[size_a-3] >> nbits)); + + y = ((size_b >= size_a - 2 ? b->ob_digit[size_a-3] >> nbits : 0) | + (size_b >= size_a - 1 ? b->ob_digit[size_a-2] << (PyLong_SHIFT-nbits) : 0) | + (size_b >= size_a ? b->ob_digit[size_a-1] << (2*PyLong_SHIFT-nbits) : 0)); + + /* inner loop of Lehmer's algorithm; A, B, C, D never grow + larger than PyLong_MASK during the algorithm. */ + A = 1; B = 0; C = 0; D = 1; + for (k=0;; k++) { + if (y-C == 0) + break; + q = (x+(A-1))/(y-C); + s = B+q*D; + t = x-q*y; + if (s > t) + break; + x = y; y = t; + t = A+q*C; A = D; B = C; C = (digit)s; D = (digit)t; + } + + if (k == 0) { + /* no progress; do a Euclidean step */ + if (Py_SIZE(b) == 0) { + Py_DECREF(b); + return a; + } + if (l_divmod(a, b, NULL, &d) < 0) { + Py_DECREF(a); + Py_DECREF(b); + return NULL; + } + Py_DECREF(a); + a = b; + b = d; + continue; + } + + /* + a, b = A*b-B*a, D*a-C*b if k is odd + a, b = A*a-B*b, D*b-C*a if k is even + */ + c = _PyLong_New(size_a); + if (c == NULL) { + Py_DECREF(a); + Py_DECREF(b); + return NULL; + } + + d = _PyLong_New(size_a); + if (d == NULL) { + Py_DECREF(a); + Py_DECREF(b); + Py_DECREF(c); + return NULL; + } + a_end = a->ob_digit + size_a; + b_end = b->ob_digit + size_b; + + /* compute new a and new b in parallel */ + a_digit = a->ob_digit; + b_digit = b->ob_digit; + c_digit = c->ob_digit; + d_digit = d->ob_digit; + c_carry = 0; + d_carry = 0; + if (k&1) { + while (b_digit < b_end) { + c_carry += (A * *b_digit) - (B * *a_digit); + d_carry += (D * *a_digit++) - (C * *b_digit++); + *c_digit++ = (digit)(c_carry & PyLong_MASK); + *d_digit++ = (digit)(d_carry & PyLong_MASK); + c_carry >>= PyLong_SHIFT; + d_carry >>= PyLong_SHIFT; + } + while (a_digit < a_end) { + c_carry -= B * *a_digit; + d_carry += D * *a_digit++; + *c_digit++ = (digit)(c_carry & PyLong_MASK); + *d_digit++ = (digit)(d_carry & PyLong_MASK); + c_carry >>= PyLong_SHIFT; + d_carry >>= PyLong_SHIFT; + } + } + else { + while (b_digit < b_end) { + c_carry += (A * *a_digit) - (B * *b_digit); + d_carry += (D * *b_digit++) - (C * *a_digit++); + *c_digit++ = (digit)(c_carry & PyLong_MASK); + *d_digit++ = (digit)(d_carry & PyLong_MASK); + c_carry >>= PyLong_SHIFT; + d_carry >>= PyLong_SHIFT; + } + while (a_digit < a_end) { + c_carry += A * *a_digit; + d_carry -= C * *a_digit++; + *c_digit++ = (digit)(c_carry & PyLong_MASK); + *d_digit++ = (digit)(d_carry & PyLong_MASK); + c_carry >>= PyLong_SHIFT; + d_carry >>= PyLong_SHIFT; + } + } + assert(c_carry == 0); + assert(d_carry == 0); + + Py_DECREF(a); + Py_DECREF(b); + a = long_normalize(c); + b = long_normalize(d); + } + + /* a fits into a long, so b must too */ + x = PyLong_AsLong((PyObject *)a); + y = PyLong_AsLong((PyObject *)b); + Py_DECREF(a); + Py_DECREF(b); + + /* usual Euclidean algorithm for longs */ + while (y != 0) { + t = y; + y = x % y; + x = t; + } + return (PyLongObject *)PyLong_FromLong(x); +} + +PyObject * +_PyLong_GCD(PyObject *a, PyObject *b) +{ + long x, y, t; + int overflow; + + x = PyLong_AsLongAndOverflow(a, &overflow); + if (!overflow && !(x == -1 && PyErr_Occurred()) && x >= -LONG_MAX) { + y = PyLong_AsLongAndOverflow(b, &overflow); + if (!overflow && !(y == -1 && PyErr_Occurred()) && y >= -LONG_MAX) { + /* Both a and b are small integers; + use the usual gcd algorithm. */ + if (x < 0) + x = -x; + if (y < 0) + y = -y; + while (y != 0) { + t = x % y; + x = y; + y = t; + } + return PyLong_FromLong(x); + } + } + + return (PyObject *)long_gcd((PyLongObject *)a, (PyLongObject *)b); +} + static PyObject * long_float(PyObject *v) { From report at bugs.python.org Thu Sep 25 15:04:09 2014 From: report at bugs.python.org (gladman) Date: Thu, 25 Sep 2014 13:04:09 +0000 Subject: [issue22486] Add math.gcd() In-Reply-To: <1411591235.17.0.168367966743.issue22486@psf.upfronthosting.co.za> Message-ID: <1411650249.37.0.323949442819.issue22486@psf.upfronthosting.co.za> gladman added the comment: I am inclined to think that a maths.gcd() makes sense as this would be where I would go first to find this function. And the prospect of better performance is attractive since the gcd is an important operation in work with number theory algorithms. Would it co-exist with fractions.gcd(), with identical semantics? Or would it co-exist with fractions.gcd(), with the 'less surprising' semantics that are under discussion in the 'GCD in Fractions' thread? Would it take on the suggestion of operating on one or more input parameters? ---------- nosy: +gladman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 16:23:43 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 25 Sep 2014 14:23:43 +0000 Subject: [issue15799] httplib client and statusline In-Reply-To: <1346185891.22.0.123491218752.issue15799@psf.upfronthosting.co.za> Message-ID: <1411655023.7.0.825028695631.issue15799@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 16:55:14 2014 From: report at bugs.python.org (Matthew Barnett) Date: Thu, 25 Sep 2014 14:55:14 +0000 Subject: [issue22477] GCD in Fractions In-Reply-To: <1411543502.18.0.966419857361.issue22477@psf.upfronthosting.co.za> Message-ID: <1411656914.34.0.446760792219.issue22477@psf.upfronthosting.co.za> Matthew Barnett added the comment: After some thought, I've come to the conclusion that the GCD of two integers should be negative only if both of those integers are negative. The basic algorithm is that you find all of the prime factors of the integers and then return the product of the common subset (multiset, actually). For example, to calculate the GCD of 6 and 15: 6 => [2, 3] 15 => [3, 5] The largest common subset is [3]. Therefore the GCD is 3. What about negative integers? Well, what you could do is make one of the factors -1. For example, to calculate the GCD of -6 and 15: -6 => [-1, 2, 3] 15 => [3, 5] The largest common subset is [3]. Therefore the GCD is 3. Another example, to calculate the GCD of -6 and -15: -6 => [-1, 2, 3] -15 => [-1, 3, 5] The largest common subset is [-1, 3]. Therefore the GCD is -3. ---------- nosy: +mrabarnett _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 16:57:34 2014 From: report at bugs.python.org (Mathieu Dupuy) Date: Thu, 25 Sep 2014 14:57:34 +0000 Subject: [issue2202] urllib2 fails against IIS 6.0 (No support for MD5-sess auth) In-Reply-To: <1204223194.19.0.670418970441.issue2202@psf.upfronthosting.co.za> Message-ID: <1411657054.98.0.631267371577.issue2202@psf.upfronthosting.co.za> Mathieu Dupuy added the comment: here is the patch, for the trunk ---------- versions: -Python 3.4 Added file: http://bugs.python.org/file36724/md5-sess_not_implem_cur.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 16:57:54 2014 From: report at bugs.python.org (Mathieu Dupuy) Date: Thu, 25 Sep 2014 14:57:54 +0000 Subject: [issue2202] urllib2 fails against IIS 6.0 (No support for MD5-sess auth) In-Reply-To: <1204223194.19.0.670418970441.issue2202@psf.upfronthosting.co.za> Message-ID: <1411657074.55.0.470580212602.issue2202@psf.upfronthosting.co.za> Mathieu Dupuy added the comment: and here for the 2.7 branch ---------- Added file: http://bugs.python.org/file36725/md5-sess_not_implem_27.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 17:46:33 2014 From: report at bugs.python.org (gladman) Date: Thu, 25 Sep 2014 15:46:33 +0000 Subject: [issue22477] GCD in Fractions In-Reply-To: <1411656914.34.0.446760792219.issue22477@psf.upfronthosting.co.za> Message-ID: <542438DA.30105@gladman.plus.com> gladman added the comment: On 25/09/2014 15:55, Matthew Barnett wrote: > > Matthew Barnett added the comment: > > After some thought, I've come to the conclusion that the GCD of two integers should be negative only if both of those integers are negative. The basic algorithm is that you find all of the prime factors of the integers and then return the product of the common subset (multiset, actually). > > For example, to calculate the GCD of 6 and 15: > > 6 => [2, 3] > 15 => [3, 5] > The largest common subset is [3]. > Therefore the GCD is 3. > > What about negative integers? > > Well, what you could do is make one of the factors -1. > > For example, to calculate the GCD of -6 and 15: > > -6 => [-1, 2, 3] > 15 => [3, 5] > The largest common subset is [3]. > Therefore the GCD is 3. > > Another example, to calculate the GCD of -6 and -15: > > -6 => [-1, 2, 3] > -15 => [-1, 3, 5] > The largest common subset is [-1, 3]. > Therefore the GCD is -3. But should the computation of the GCD of two integers by finding the intersection of their prime factors include -1 or 1 given that neither of these is a prime? :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 17:48:51 2014 From: report at bugs.python.org (Mathieu Dupuy) Date: Thu, 25 Sep 2014 15:48:51 +0000 Subject: [issue22496] urllib2 fails against IIS (urllib2 can't parse 401 reply www-authenticate headers) Message-ID: <1411660131.7.0.581562777837.issue22496@psf.upfronthosting.co.za> New submission from Mathieu Dupuy: When connecting to a IIS server, it replies that: Unauthorized Server: Microsoft-IIS/7.5 WWW-Authenticate: Digest qop="auth",algorithm=MD5-sess,nonce="+Upgraded+v1fe2ba746797cfd974e85f9f6dbdd6e514ec45becd2d8cf0112c764c676ad4a00f98517bb166e467dcad4b942254bd9b71d447e3529c509d2",charset=utf-8,realm="Digest" WWW-Authenticate: Negotiate WWW-Authenticate: NTLM X-Powered-By: ASP.NET Date: Thu, 25 Sep 2014 15:11:03 GMT Connection: close Content-Length: 0 which blew python 2.7 utllib2 like this: File "tut2.py", line 23, in response = opener.open('https://exca010.encara.local.ads/ews/Services.wsdl') File "/usr/lib64/python2.7/urllib2.py", line 410, in open response = meth(req, response) File "/usr/lib64/python2.7/urllib2.py", line 524, in http_response 'http', request, response, code, msg, hdrs) File "/usr/lib64/python2.7/urllib2.py", line 442, in error result = self._call_chain(*args) File "/usr/lib64/python2.7/urllib2.py", line 382, in _call_chain result = func(*args) File "/usr/lib64/python2.7/urllib2.py", line 1090, in http_error_401 host, req, headers) File "/usr/lib64/python2.7/urllib2.py", line 973, in http_error_auth_reqed return self.retry_http_digest_auth(req, authreq) File "/usr/lib64/python2.7/urllib2.py", line 977, in retry_http_digest_auth chal = parse_keqv_list(parse_http_list(challenge)) File "/usr/lib64/python2.7/urllib2.py", line 1259, in parse_keqv_list k, v = elt.split('=', 1) ValueError: need more than 1 value to unpack urllib2 seems to assume that every www-authenticate header value will be a list of equal-signe-separated tuple. On python3, the error is different and trigger this http://bugs.python.org/issue2202 (which is soon-to-be-fixed) ---------- components: Library (Lib) messages: 227543 nosy: deronnax priority: normal severity: normal status: open title: urllib2 fails against IIS (urllib2 can't parse 401 reply www-authenticate headers) type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 17:53:47 2014 From: report at bugs.python.org (Katherine Dykes) Date: Thu, 25 Sep 2014 15:53:47 +0000 Subject: [issue5459] msiexec not creating msvcr90.dll with python -2.6.1.msi In-Reply-To: <1236606031.24.0.862626797597.issue5459@psf.upfronthosting.co.za> Message-ID: <1411660427.83.0.448793112463.issue5459@psf.upfronthosting.co.za> Katherine Dykes added the comment: Installing for a single user does solve the problem but it is not a good fix. We have python based software where this has been an issue and a lot of our windows users install python for all users out of habit. We have to put in the docs to install for a single user, but I'd like to see the issue re-opened. ---------- nosy: +Katherine.Dykes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 18:02:23 2014 From: report at bugs.python.org (Matthew Barnett) Date: Thu, 25 Sep 2014 16:02:23 +0000 Subject: [issue22477] GCD in Fractions In-Reply-To: <1411543502.18.0.966419857361.issue22477@psf.upfronthosting.co.za> Message-ID: <1411660943.78.0.939285955288.issue22477@psf.upfronthosting.co.za> Matthew Barnett added the comment: As it appears that there isn't general agreement on how to calculate the GCD when negative numbers are involved, I needed to look for another way of thinking about it. Splitting off the sign as another factor was what I came up with. Pragmatism beats purity, and all that! :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 18:09:13 2014 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 25 Sep 2014 16:09:13 +0000 Subject: [issue22477] GCD in Fractions In-Reply-To: <1411543502.18.0.966419857361.issue22477@psf.upfronthosting.co.za> Message-ID: <1411661353.22.0.131494634495.issue22477@psf.upfronthosting.co.za> Stefan Behnel added the comment: IMHO, the most straight forward way for a new gcd() function to work would be to always, predictably return a non-negative value and let users handle all cases themselves where a negative sign of any or all input values has a specific meaning to them. That's the path of least surprise, and it's very easy to implement at the C level for PyLong values (as they are internally unsigned anyway). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 18:09:28 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 25 Sep 2014 16:09:28 +0000 Subject: [issue22448] call_at/call_later with Timer cancellation can result in (practically) unbounded memory usage. In-Reply-To: <1411172040.41.0.974691283228.issue22448@psf.upfronthosting.co.za> Message-ID: <20140925160922.91826.70344@mail.hg.python.org> Roundup Robot added the comment: New changeset 2a868c9f8f15 by Yury Selivanov in branch '3.4': asyncio: Improve canceled timer handles cleanup. Closes issue #22448. https://hg.python.org/cpython/rev/2a868c9f8f15 New changeset a6aaacb2b807 by Yury Selivanov in branch 'default': asyncio: Improve canceled timer handles cleanup. Closes issue #22448. https://hg.python.org/cpython/rev/a6aaacb2b807 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 18:25:29 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 25 Sep 2014 16:25:29 +0000 Subject: [issue5459] msiexec not creating msvcr90.dll with python -2.6.1.msi In-Reply-To: <1236606031.24.0.862626797597.issue5459@psf.upfronthosting.co.za> Message-ID: <1411662329.62.0.490272462195.issue5459@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Katherine: Python 2.6 is no longer maintained. If you are talking about a different Python version, please submit a new bug report. Please state 1. what you did 2. what happened 3. what you expected to happen instead (personally, I'm not willing to invest time into 2.7, either, but somebody else might if that's the version you care about) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 18:30:29 2014 From: report at bugs.python.org (Katherine Dykes) Date: Thu, 25 Sep 2014 16:30:29 +0000 Subject: [issue5459] msiexec not creating msvcr90.dll with python -2.6.1.msi In-Reply-To: <1236606031.24.0.862626797597.issue5459@psf.upfronthosting.co.za> Message-ID: <1411662629.78.0.847186547801.issue5459@psf.upfronthosting.co.za> Katherine Dykes added the comment: It is indeed 2.7 with the issues; the software we are building on (OpenMDAO) does not support 3.x - I'll go ahead and submit a new issue for 2.7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 18:36:49 2014 From: report at bugs.python.org (Katherine Dykes) Date: Thu, 25 Sep 2014 16:36:49 +0000 Subject: [issue22497] msiexec not creating msvcr90.dll with python -2.7.6.msi Message-ID: <1411663009.27.0.792160557257.issue22497@psf.upfronthosting.co.za> New submission from Katherine Dykes: This is a new issue meant to resurrect Issue 5459. When Python 2.7.x (and 2.6.x before that) are installed for all users, then 'msvcr90.dll' is not created in the installation directory. It does if you install for a single user. However, many Windows users install Python for all users by default. This causes problems later when trying to install software that combines any sort of C or Fortran code. ---------- components: Windows messages: 227550 nosy: dykesk priority: normal severity: normal status: open title: msiexec not creating msvcr90.dll with python -2.7.6.msi versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 18:44:42 2014 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 25 Sep 2014 16:44:42 +0000 Subject: [issue22477] GCD in Fractions In-Reply-To: <1411543502.18.0.966419857361.issue22477@psf.upfronthosting.co.za> Message-ID: <1411663482.9.0.367326202791.issue22477@psf.upfronthosting.co.za> Mark Dickinson added the comment: > IMHO, the most straight forward way for a new gcd() function to work would > be to always, predictably return a non-negative value. Yes. Any new gcd implementation (in the math module, for example) should definitely return the unique nonnegative gcd of its inputs. In an effort to concentrate the discussion a bit, here's a specific proposal, deliberately limited in scope: 1. Add a new (faster) math.gcd function for Python 3.5, taking two integral arguments, and returning the unique nonnegative greatest common divisor of those arguments. 2. Deprecate fractions.gcd in Python 3.5 (with a message suggesting that math.gcd should be used instead), but don't change its behaviour. (The fractions module would likely be using math.gcd by this point.) 3. Remove fractions.gcd in Python 3.6. I'd suggest that tangents about gcd of more than two arguments, gcd of rational / Decimal / float inputs, etc. be discussed elsewhere. Those are all things that can be added later if there's a real use-case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 18:50:29 2014 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 25 Sep 2014 16:50:29 +0000 Subject: [issue22477] GCD in Fractions In-Reply-To: <1411543502.18.0.966419857361.issue22477@psf.upfronthosting.co.za> Message-ID: <1411663828.99.0.31865864861.issue22477@psf.upfronthosting.co.za> Mark Dickinson added the comment: On second thoughts, I'm withdrawing this part of the proposal: > 3. Remove fractions.gcd in Python 3.6. That just falls under 'gratuitous breakage'. Instead, we should modify the `fractions.gcd` docstring to point users to math.gcd. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 18:52:57 2014 From: report at bugs.python.org (gladman) Date: Thu, 25 Sep 2014 16:52:57 +0000 Subject: [issue22477] GCD in Fractions In-Reply-To: <1411660943.78.0.939285955288.issue22477@psf.upfronthosting.co.za> Message-ID: <5424486A.1060207@gladman.plus.com> gladman added the comment: On 25/09/2014 17:02, Matthew Barnett wrote: > > Matthew Barnett added the comment: > > As it appears that there isn't general agreement on how to calculate the GCD when negative numbers are involved, I needed to look for another way of thinking about it. > > Splitting off the sign as another factor was what I came up with. > > Pragmatism beats purity, and all that! :-) I understand :-) But I think we now know that we are not going to get agreement here on grounds of principles for what the gcd should return for negative integers. First, in order to preserve my sanity, I am going to concede Mark's point that returning a negative value from GCD is not wrong :-) For negative integers we have now amassed quite a few alternatives: 1) return the GCD that is non-negative (my preference) 2) return the GCD that is negative (your suggestion) 3) return the GCD that has the same sign as its first input 4) return the GCD that has the same sign as its second input (as now) and, I suspect, a few more I haven't thought of. I may be wrong here, but I suspect that if we were starting from scratch the first of these would quickly be adopted for several reasons: 1) it yields the least surprising results and the one that most users probably both want and expect. 2) For me, Wolfgang Maier's point about the commutative properties of the gcd is rather important since finding that gcd(a, b) != gcd(b, a) is a real loss, not just an inconvenience. 3) Its supports a common idiom for checking for co-prime numbers by testing if the gcd is equal to 1. But we are not starting from scratch and it is hard to see that it makes much sense to change the GCD in fractions given the backwards compatibilty issues that this might create. So, it would seem that we should eiher do nothing or we should introduce a gcd in, say math, that adopts approach (1) above and document its difference when compared with that in fractions, allowing both to co-exist. We can, hopefully speed it up (see the related threads) and it might over time come to be the gcd that people come to use as the norm (also nothing would stop its internal use in fractions). We might also allow one or more inputs. Last but not least I hope I have not done anyone a disservice in this summary. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 18:56:01 2014 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 25 Sep 2014 16:56:01 +0000 Subject: [issue22486] Add math.gcd() In-Reply-To: <1411591235.17.0.168367966743.issue22486@psf.upfronthosting.co.za> Message-ID: <1411664161.0.0.514431180654.issue22486@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Or would it co-exist with fractions.gcd(), with the 'less surprising' > semantics that are under discussion in the 'GCD in Fractions' thread? Yes, exactly. math.gcd will always give a nonnegative result. The output of fractions.gcd remains unchanged for integer inputs, for backwards compatibility. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 18:57:20 2014 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 25 Sep 2014 16:57:20 +0000 Subject: [issue22486] Add math.gcd() In-Reply-To: <1411591235.17.0.168367966743.issue22486@psf.upfronthosting.co.za> Message-ID: <1411664240.36.0.75845784259.issue22486@psf.upfronthosting.co.za> Mark Dickinson added the comment: Serhiy: thank you! I've been meaning to update that patch for a long time, but hadn't found the courage or time to face the inevitable bitrot. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 19:08:55 2014 From: report at bugs.python.org (gladman) Date: Thu, 25 Sep 2014 17:08:55 +0000 Subject: [issue22477] GCD in Fractions In-Reply-To: <1411663482.9.0.367326202791.issue22477@psf.upfronthosting.co.za> Message-ID: <54244C28.5040509@gladman.plus.com> gladman added the comment: On 25/09/2014 17:44, Mark Dickinson wrote: > > Mark Dickinson added the comment: > >> IMHO, the most straight forward way for a new gcd() function to work would >> be to always, predictably return a non-negative value. > > Yes. Any new gcd implementation (in the math module, for example) should definitely return the unique nonnegative gcd of its inputs. > > In an effort to concentrate the discussion a bit, here's a specific > proposal, deliberately limited in scope: > > 1. Add a new (faster) math.gcd function for Python 3.5, taking two integral arguments, and returning the unique nonnegative greatest common divisor of those arguments. > > 2. Deprecate fractions.gcd in Python 3.5 (with a message suggesting that math.gcd should be used instead), but don't change its behaviour. (The fractions module would likely be using math.gcd by this point.) > > 3. Remove fractions.gcd in Python 3.6. > > I'd suggest that tangents about gcd of more than two arguments, gcd of rational / Decimal / float inputs, etc. be discussed elsewhere. Those are all things that can be added later if there's a real use-case. My summary crossed with this plan from Mark, which I support (minus the bit he subsequently retracted). +1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 19:26:56 2014 From: report at bugs.python.org (James Paget) Date: Thu, 25 Sep 2014 17:26:56 +0000 Subject: [issue22498] frozenset allows modification via -= operator Message-ID: <1411666016.57.0.993512040715.issue22498@psf.upfronthosting.co.za> New submission from James Paget: The operator -= modifies a frozenset (this should not be possible), instead of signaling a TypeError. Contrast with the += operator. >>> f=frozenset([1,2]) >>> f frozenset([1, 2]) >>> f -= frozenset([1]) >>> f frozenset([2]) >>> f -= frozenset([2]) >>> f frozenset([]) >>> f += frozenset([2]) Traceback (most recent call last): File "", line 1, in TypeError: unsupported operand type(s) for +=: 'frozenset' and 'frozenset' >>> ---------- components: Interpreter Core messages: 227557 nosy: James.Paget priority: normal severity: normal status: open title: frozenset allows modification via -= operator type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 19:41:40 2014 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 25 Sep 2014 17:41:40 +0000 Subject: [issue22498] frozenset allows modification via -= operator In-Reply-To: <1411666016.57.0.993512040715.issue22498@psf.upfronthosting.co.za> Message-ID: <1411666900.46.0.418927981054.issue22498@psf.upfronthosting.co.za> Ezio Melotti added the comment: This doesn't modify f, it replaces it with a new frozenset: >>> f = frozenset({1, 2}) >>> f frozenset({1, 2}) >>> id(f) 3071990668 >>> f -= frozenset({1}) >>> f frozenset({2}) >>> id(f) 3066719340 Notice how the two ids are different. In other words, f -= frozenset({1}) is equivalent to f = f - frozenset({1}) You get an error with += because f = f + frozenset({1}) is not a valid operation for (frozen)sets. ---------- nosy: +ezio.melotti resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 19:43:49 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 25 Sep 2014 17:43:49 +0000 Subject: [issue22477] GCD in Fractions In-Reply-To: <1411543502.18.0.966419857361.issue22477@psf.upfronthosting.co.za> Message-ID: <1411667029.32.0.353736607393.issue22477@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I strongly agree with Mark's revised plan: 1. add a fast C-coded math.gcd returning the actual greatest (in normal ordered int sense) common divisor; 2. use this for reduction of fractions in the fractions module to speed up operations on fractions. 3. revised fractions.gcd docstring "Return signed version of math.gcd. ..." I think this would be double win (users get fast, 'proper' gcd; fractions work faster too). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 19:45:49 2014 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 25 Sep 2014 17:45:49 +0000 Subject: [issue22477] GCD in Fractions In-Reply-To: <1411543502.18.0.966419857361.issue22477@psf.upfronthosting.co.za> Message-ID: <1411667149.52.0.280771684608.issue22477@psf.upfronthosting.co.za> Stefan Behnel added the comment: +1 for Mark & Terry, just for the record ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 19:51:41 2014 From: report at bugs.python.org (Akira Li) Date: Thu, 25 Sep 2014 17:51:41 +0000 Subject: [issue22477] GCD in Fractions In-Reply-To: <1411543502.18.0.966419857361.issue22477@psf.upfronthosting.co.za> Message-ID: <1411667501.65.0.579776472069.issue22477@psf.upfronthosting.co.za> Changes by Akira Li <4kir4.1i at gmail.com>: ---------- nosy: -akira _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 19:58:29 2014 From: report at bugs.python.org (Ronald Oussoren) Date: Thu, 25 Sep 2014 17:58:29 +0000 Subject: [issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew installs fragile In-Reply-To: <1411623045.52.0.589017779939.issue22490@psf.upfronthosting.co.za> Message-ID: <1411667909.3.0.75319286515.issue22490@psf.upfronthosting.co.za> Ronald Oussoren added the comment: I'm not convinced that this is a bug in python. __PYVENV_LAUNCHER__ is an implementation detail of CPython used in the implementation of the pyvenv functionality. I consider using this undocumented environment variable in distlib as a bug in distlib, which should be fixed there. It would be nice to know why distlib uses __PYVENV_LAUNCHER__ as that could lead us to a real bug or missing feature. BTW. I haven't read the discussion in [2] yet. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 20:03:17 2014 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 25 Sep 2014 18:03:17 +0000 Subject: [issue15279] Spurious unittest warnings In-Reply-To: <1341674545.77.0.716203051696.issue15279@psf.upfronthosting.co.za> Message-ID: <1411668197.88.0.9490936121.issue15279@psf.upfronthosting.co.za> Ezio Melotti added the comment: Is this still an issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 20:35:00 2014 From: report at bugs.python.org (Matthew Barnett) Date: Thu, 25 Sep 2014 18:35:00 +0000 Subject: [issue22477] GCD in Fractions In-Reply-To: <1411543502.18.0.966419857361.issue22477@psf.upfronthosting.co.za> Message-ID: <1411670100.88.0.697328605959.issue22477@psf.upfronthosting.co.za> Matthew Barnett added the comment: +1 for leaving it to the user to make it negative if so desired. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 20:46:00 2014 From: report at bugs.python.org (Ned Deily) Date: Thu, 25 Sep 2014 18:46:00 +0000 Subject: [issue22494] default logging time string is not localized In-Reply-To: <1411641752.05.0.384907346066.issue22494@psf.upfronthosting.co.za> Message-ID: <1411670760.18.0.654333773911.issue22494@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 20:49:27 2014 From: report at bugs.python.org (Ned Deily) Date: Thu, 25 Sep 2014 18:49:27 +0000 Subject: [issue22496] urllib2 fails against IIS (urllib2 can't parse 401 reply www-authenticate headers) In-Reply-To: <1411660131.7.0.581562777837.issue22496@psf.upfronthosting.co.za> Message-ID: <1411670967.89.0.0920393194791.issue22496@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 20:50:11 2014 From: report at bugs.python.org (Robert Collins) Date: Thu, 25 Sep 2014 18:50:11 +0000 Subject: [issue21472] Fix wsgiref handling of absolute HTTP Request-URI In-Reply-To: <1399807913.92.0.0240575633204.issue21472@psf.upfronthosting.co.za> Message-ID: <1411671011.36.0.462246822035.issue21472@psf.upfronthosting.co.za> Robert Collins added the comment: FWIW we probably need to capture the original unaltered URL somewhere, but also ensure that PATH_INFO is always a relative path. One should be able to implement a proxy in WSGI (because thats just another specialised app), and doing that today requires special handling depending on the WSGI container, which isn't great for consistency. On security; Host header <-> url host mismatches occur when the host to which a request is sent != the url; this is expected only in the case of forward proxies: any other time it would indeed be a smuggling attack, trying to find mismatches between acls and access in servers - this is another reason to consolidate things so that wsgi apps can rely on urls looking consistent. ---------- nosy: +rbcollins _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 20:50:42 2014 From: report at bugs.python.org (Ned Deily) Date: Thu, 25 Sep 2014 18:50:42 +0000 Subject: [issue22497] msiexec not creating msvcr90.dll with python -2.7.6.msi In-Reply-To: <1411663009.27.0.792160557257.issue22497@psf.upfronthosting.co.za> Message-ID: <1411671042.85.0.287265956317.issue22497@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +steve.dower, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 21:08:52 2014 From: report at bugs.python.org (Steve Dower) Date: Thu, 25 Sep 2014 19:08:52 +0000 Subject: [issue22497] msiexec not creating msvcr90.dll with python -2.7.6.msi In-Reply-To: <1411663009.27.0.792160557257.issue22497@psf.upfronthosting.co.za> Message-ID: <1411672132.97.0.953908287475.issue22497@psf.upfronthosting.co.za> Steve Dower added the comment: When you install for all users, the msvcr90.dll is also installed for all users and should appear in your System32/SysWOW64 directory. What sort of problems are you facing? Compiled DLLs/pyds that are loaded into a running Python process should reuse the already loaded DLL (and Python won't have started if it couldn't resolve the CRT DLL). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 21:14:27 2014 From: report at bugs.python.org (gladman) Date: Thu, 25 Sep 2014 19:14:27 +0000 Subject: [issue22477] GCD in Fractions In-Reply-To: <1411663482.9.0.367326202791.issue22477@psf.upfronthosting.co.za> Message-ID: <54246993.30402@gladman.plus.com> gladman added the comment: On 25/09/2014 17:44, Mark Dickinson wrote: > > Mark Dickinson added the comment: > >> IMHO, the most straight forward way for a new gcd() function to work would >> be to always, predictably return a non-negative value. > > Yes. Any new gcd implementation (in the math module, for example) should definitely return the unique nonnegative gcd of its inputs. > > In an effort to concentrate the discussion a bit, here's a specific > proposal, deliberately limited in scope: > > 1. Add a new (faster) math.gcd function for Python 3.5, taking two integral arguments, and returning the unique nonnegative greatest common divisor of those arguments. > > 2. Deprecate fractions.gcd in Python 3.5 (with a message suggesting that math.gcd should be used instead), but don't change its behaviour. (The fractions module would likely be using math.gcd by this point.) > > 3. Remove fractions.gcd in Python 3.6. > > I'd suggest that tangents about gcd of more than two arguments, gcd of rational / Decimal / float inputs, etc. be discussed elsewhere. Those are all things that can be added later if there's a real use-case. I don't know much about performance issues in the Python interpreter but one point I would make here is implementing a multiple integer gcd on top of a two input one will involve calling gcd and abs for each parameter. In contrast a gcd that operates on one or more parameters (e.g of the sort that I posted earlier under the name mgcd) can avoid these extra calls and any consequent overheads and _might_ do so with little additional overhead of its own making (i.e. loops vs calls). I also felt that this could be implemented on top of the work going on on the faster gcd. So, while I don't think we need to consider a rational gcd, it might be worth at least considering how a 'one or more parameter' gcd compares on performance grounds with a two parameter one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 21:30:39 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 25 Sep 2014 19:30:39 +0000 Subject: [issue17835] test_io broken on PPC64 Linux In-Reply-To: <1411635746.76.0.680205288566.issue17835@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: Let's try with this instead: >>> from socket import socket, SO_SNDBUF, SOL_SOCKET >>> s = socket() >>> s.getsockopt(SOL_SOCKET, SO_SNDBUF) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 21:32:04 2014 From: report at bugs.python.org (Berker Peksag) Date: Thu, 25 Sep 2014 19:32:04 +0000 Subject: [issue4888] misplaced (or misleading) assert in ceval.c In-Reply-To: <1231476734.82.0.767072982695.issue4888@psf.upfronthosting.co.za> Message-ID: <1411673524.58.0.950096611255.issue4888@psf.upfronthosting.co.za> Berker Peksag added the comment: This has been fixed as part of issue 16191: https://hg.python.org/cpython/rev/ac30a1b1cf17#l1.2780 ---------- nosy: +berker.peksag resolution: -> out of date stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 21:37:34 2014 From: report at bugs.python.org (Berker Peksag) Date: Thu, 25 Sep 2014 19:37:34 +0000 Subject: [issue19642] shutil to support equivalent of: rm -f /dir/* In-Reply-To: <1384775126.27.0.181995142425.issue19642@psf.upfronthosting.co.za> Message-ID: <1411673854.93.0.0368990382351.issue19642@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 21:52:32 2014 From: report at bugs.python.org (Mathieu Dupuy) Date: Thu, 25 Sep 2014 19:52:32 +0000 Subject: [issue22496] urllib2 fails against IIS (urllib2 can't parse 401 reply www-authenticate headers) In-Reply-To: <1411660131.7.0.581562777837.issue22496@psf.upfronthosting.co.za> Message-ID: <1411674752.78.0.767937003559.issue22496@psf.upfronthosting.co.za> Mathieu Dupuy added the comment: I filled the bug in a hurry. You have to read "when connecting to a IIS for a protected resource and replying with 401 for an authentication challenge, it replies this [...]" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 22:13:12 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 25 Sep 2014 20:13:12 +0000 Subject: [issue22486] Add math.gcd() In-Reply-To: <1411664240.36.0.75845784259.issue22486@psf.upfronthosting.co.za> Message-ID: <4082432.VZ0hddVBaq@raxxla> Serhiy Storchaka added the comment: Now I spent more time on the patch. Changes in updated patch: * Removed code duplication for odd and even k. * Temporary buffers c and d no longer allocated on every iteration. * Long result now compacted. No longer unused allocated size. * Added checks for results of long_abs() (it can fail). * Merged _PyLong_GCD and long_gcd. Fast path for small negative integers no longer need to copy long objects in long_abs(). * Added tests for large negative numbers and for case Py_SIZE(a) - Py_SIZE(b) > 3. ---------- Added file: http://bugs.python.org/file36726/lehmer_gcd_6.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r e9d4288c32de Doc/library/math.rst --- a/Doc/library/math.rst Wed Sep 24 13:29:27 2014 +0300 +++ b/Doc/library/math.rst Thu Sep 25 23:10:36 2014 +0300 @@ -100,6 +100,14 @@ Number-theoretic and representation func `_\. +.. function:: gcd(a, b) + + Return the greatest common divisor of the integers *a* and *b*. If either + *a* or *b* is nonzero, then the value of ``gcd(a, b)`` is the largest + positive integer that divides both *a* and *b*. ``gcd(0, 0)`` returns + ``0``. + + .. function:: isfinite(x) Return ``True`` if *x* is neither an infinity nor a NaN, and diff -r e9d4288c32de Include/longobject.h --- a/Include/longobject.h Wed Sep 24 13:29:27 2014 +0300 +++ b/Include/longobject.h Thu Sep 25 23:10:36 2014 +0300 @@ -198,6 +198,9 @@ PyAPI_FUNC(int) _PyLong_FormatAdvancedWr PyAPI_FUNC(unsigned long) PyOS_strtoul(const char *, char **, int); PyAPI_FUNC(long) PyOS_strtol(const char *, char **, int); +/* For use by the gcd function in mathmodule.c */ +PyAPI_FUNC(PyObject *) _PyLong_GCD(PyObject *, PyObject *); + #ifdef __cplusplus } #endif diff -r e9d4288c32de Lib/fractions.py --- a/Lib/fractions.py Wed Sep 24 13:29:27 2014 +0300 +++ b/Lib/fractions.py Thu Sep 25 23:10:36 2014 +0300 @@ -20,9 +20,9 @@ def gcd(a, b): Unless b==0, the result will have the same sign as b (so that when b is divided by it, the result comes out positive). """ - while b: - a, b = b, a%b - return a + if (b or a) < 0: + return -math.gcd(a, b) + return math.gcd(a, b) # Constants related to the hash implementation; hash(x) is based # on the reduction of x modulo the prime _PyHASH_MODULUS. @@ -174,9 +174,12 @@ class Fraction(numbers.Rational): if denominator == 0: raise ZeroDivisionError('Fraction(%s, 0)' % numerator) if _normalize: - g = gcd(numerator, denominator) + g = math.gcd(numerator, denominator) numerator //= g denominator //= g + if denominator < 0: + numerator = -numerator + denominator = -denominator self._numerator = numerator self._denominator = denominator return self diff -r e9d4288c32de Lib/test/test_math.py --- a/Lib/test/test_math.py Wed Sep 24 13:29:27 2014 +0300 +++ b/Lib/test/test_math.py Thu Sep 25 23:10:36 2014 +0300 @@ -595,6 +595,43 @@ class MathTests(unittest.TestCase): s = msum(vals) self.assertEqual(msum(vals), math.fsum(vals)) + def testGcd(self): + gcd = math.gcd + self.assertEqual(gcd(0, 0), 0) + self.assertEqual(gcd(1, 0), 1) + self.assertEqual(gcd(-1, 0), 1) + self.assertEqual(gcd(0, 1), 1) + self.assertEqual(gcd(0, -1), 1) + self.assertEqual(gcd(7, 1), 1) + self.assertEqual(gcd(7, -1), 1) + self.assertEqual(gcd(-23, 15), 1) + self.assertEqual(gcd(120, 84), 12) + self.assertEqual(gcd(84, -120), 12) + c = 652560 + x = 434610456570399902378880679233098819019853229470286994367836600566 + y = 1064502245825115327754847244914921553977 + a = x * c + b = y * c + self.assertEqual(gcd(a, b), c) + self.assertEqual(gcd(b, a), c) + self.assertEqual(gcd(-a, b), c) + self.assertEqual(gcd(b, -a), c) + self.assertEqual(gcd(a, -b), c) + self.assertEqual(gcd(-b, a), c) + self.assertEqual(gcd(-a, -b), c) + self.assertEqual(gcd(-b, -a), c) + c = 576559230871654959816130551884856912003141446781646602790216406874 + a = x * c + b = y * c + self.assertEqual(gcd(a, b), c) + self.assertEqual(gcd(b, a), c) + self.assertEqual(gcd(-a, b), c) + self.assertEqual(gcd(b, -a), c) + self.assertEqual(gcd(a, -b), c) + self.assertEqual(gcd(-b, a), c) + self.assertEqual(gcd(-a, -b), c) + self.assertEqual(gcd(-b, -a), c) + def testHypot(self): self.assertRaises(TypeError, math.hypot) self.ftest('hypot(0,0)', math.hypot(0,0), 0) diff -r e9d4288c32de Modules/mathmodule.c --- a/Modules/mathmodule.c Wed Sep 24 13:29:27 2014 +0300 +++ b/Modules/mathmodule.c Thu Sep 25 23:10:36 2014 +0300 @@ -656,6 +656,22 @@ m_log10(double x) } +static PyObject * +math_gcd(PyObject *self, PyObject *args) +{ + PyObject *a, *b; + + if (!PyArg_ParseTuple(args, "O!O!:gcd", &PyLong_Type, &a, &PyLong_Type, &b)) + return NULL; + + return _PyLong_GCD(a, b); +} + +PyDoc_STRVAR(math_gcd_doc, +"gcd(x, y) -> int\n\ +greatest common divisor of x and y"); + + /* Call is_error when errno != 0, and where x is the result libm * returned. is_error will usually set up an exception and return * true (1), but may return false (0) without setting up an exception. @@ -1958,6 +1974,7 @@ static PyMethodDef math_methods[] = { {"frexp", math_frexp, METH_O, math_frexp_doc}, {"fsum", math_fsum, METH_O, math_fsum_doc}, {"gamma", math_gamma, METH_O, math_gamma_doc}, + {"gcd", math_gcd, METH_VARARGS, math_gcd_doc}, {"hypot", math_hypot, METH_VARARGS, math_hypot_doc}, {"isfinite", math_isfinite, METH_O, math_isfinite_doc}, {"isinf", math_isinf, METH_O, math_isinf_doc}, diff -r e9d4288c32de Objects/longobject.c --- a/Objects/longobject.c Wed Sep 24 13:29:27 2014 +0300 +++ b/Objects/longobject.c Thu Sep 25 23:10:36 2014 +0300 @@ -4327,6 +4327,198 @@ long_long(PyObject *v) return v; } +PyObject * +_PyLong_GCD(PyObject *aarg, PyObject *barg) +{ + PyLongObject *a, *b, *c = NULL, *d = NULL, *e; + stwodigits x, y, q, s, t, c_carry, d_carry; + stwodigits A, B, C, D, T; + int nbits, k; + Py_ssize_t size_a, size_b, alloc_a, alloc_b; + digit *a_digit, *b_digit, *c_digit, *d_digit, *a_end, *b_end; + + a = (PyLongObject *)aarg; + b = (PyLongObject *)barg; + size_a = Py_SIZE(a); + size_b = Py_SIZE(b); + if (-2 <= size_a && size_a <= 2 && -2 <= size_b && size_b <= 2) { + Py_INCREF(a); + Py_INCREF(b); + goto simple; + } + + /* Initial reduction: make sure that 0 <= b <= a. */ + a = (PyLongObject *)long_abs(a); + if (a == NULL) + return NULL; + b = (PyLongObject *)long_abs(b); + if (b == NULL) { + Py_DECREF(a); + return NULL; + } + if (long_compare(a, b) < 0) { + e = a; + a = b; + b = e; + } + /* We now own references to a and b */ + + alloc_a = Py_SIZE(a); + alloc_b = Py_SIZE(b); + /* reduce until a fits into 2 digits */ + while ((size_a = Py_SIZE(a)) > 2) { + nbits = bits_in_digit(a->ob_digit[size_a-1]); + /* extract top 2*PyLong_SHIFT bits of a into x, along with + corresponding bits of b into y */ + size_b = Py_SIZE(b); + assert(size_b <= size_a); + if (size_b == 0) { + Py_DECREF(b); + Py_XDECREF(c); + Py_XDECREF(d); + if (size_a < alloc_a) { + b = (PyLongObject *)_PyLong_Copy(a); + Py_DECREF(a); + } + else + b = a; + return (PyObject *)b; + } + x = ((a->ob_digit[size_a-1] << (2*PyLong_SHIFT-nbits)) | + (a->ob_digit[size_a-2] << (PyLong_SHIFT-nbits)) | + (a->ob_digit[size_a-3] >> nbits)); + + y = ((size_b >= size_a - 2 ? b->ob_digit[size_a-3] >> nbits : 0) | + (size_b >= size_a - 1 ? b->ob_digit[size_a-2] << (PyLong_SHIFT-nbits) : 0) | + (size_b >= size_a ? b->ob_digit[size_a-1] << (2*PyLong_SHIFT-nbits) : 0)); + + /* inner loop of Lehmer's algorithm; A, B, C, D never grow + larger than PyLong_MASK during the algorithm. */ + A = 1; B = 0; C = 0; D = 1; + for (k=0;; k++) { + if (y-C == 0) + break; + q = (x+(A-1))/(y-C); + s = B+q*D; + t = x-q*y; + if (s > t) + break; + x = y; y = t; + t = A+q*C; A = D; B = C; C = (digit)s; D = (digit)t; + } + + if (k == 0) { + /* no progress; do a Euclidean step */ + if (l_divmod(a, b, NULL, &e) < 0) + goto error; + Py_DECREF(a); + a = b; + b = e; + alloc_a = alloc_b; + alloc_b = Py_SIZE(b); + continue; + } + + /* + a, b = A*b-B*a, D*a-C*b if k is odd + a, b = A*a-B*b, D*b-C*a if k is even + */ + if (c != NULL) + Py_SIZE(c) = size_a; + else if (Py_REFCNT(a) == 1) { + Py_INCREF(a); + c = a; + } + else { + alloc_a = size_a; + c = _PyLong_New(size_a); + if (c == NULL) + goto error; + } + + if (d != NULL) + Py_SIZE(d) = size_a; + else if (Py_REFCNT(b) == 1 && size_a <= alloc_b) { + Py_INCREF(b); + d = b; + Py_SIZE(d) = size_a; + } + else { + alloc_b = size_a; + d = _PyLong_New(size_a); + if (d == NULL) + goto error; + } + a_end = a->ob_digit + size_a; + b_end = b->ob_digit + size_b; + + /* compute new a and new b in parallel */ + a_digit = a->ob_digit; + b_digit = b->ob_digit; + c_digit = c->ob_digit; + d_digit = d->ob_digit; + c_carry = 0; + d_carry = 0; + if (k&1) { + T = -A; A = -B; B = T; + T = -C; C = -D; D = T; + } + while (b_digit < b_end) { + c_carry += (A * *a_digit) - (B * *b_digit); + d_carry += (D * *b_digit++) - (C * *a_digit++); + *c_digit++ = (digit)(c_carry & PyLong_MASK); + *d_digit++ = (digit)(d_carry & PyLong_MASK); + c_carry >>= PyLong_SHIFT; + d_carry >>= PyLong_SHIFT; + } + while (a_digit < a_end) { + c_carry += A * *a_digit; + d_carry -= C * *a_digit++; + *c_digit++ = (digit)(c_carry & PyLong_MASK); + *d_digit++ = (digit)(d_carry & PyLong_MASK); + c_carry >>= PyLong_SHIFT; + d_carry >>= PyLong_SHIFT; + } + assert(c_carry == 0); + assert(d_carry == 0); + + Py_INCREF(c); + Py_INCREF(d); + Py_DECREF(a); + Py_DECREF(b); + a = long_normalize(c); + b = long_normalize(d); + } + Py_XDECREF(c); + Py_XDECREF(d); + +simple: + assert(Py_REFCNT(a) > 0); + assert(Py_REFCNT(b) > 0); + /* a fits into a long, so b must too */ + x = PyLong_AsLong((PyObject *)a); + y = PyLong_AsLong((PyObject *)b); + x = Py_ABS(x); + y = Py_ABS(y); + Py_DECREF(a); + Py_DECREF(b); + + /* usual Euclidean algorithm for longs */ + while (y != 0) { + t = y; + y = x % y; + x = t; + } + return PyLong_FromLong(x); + +error: + Py_DECREF(a); + Py_DECREF(b); + Py_XDECREF(c); + Py_XDECREF(d); + return NULL; +} + static PyObject * long_float(PyObject *v) { From report at bugs.python.org Thu Sep 25 22:16:04 2014 From: report at bugs.python.org (Joshua Moore-Oliva) Date: Thu, 25 Sep 2014 20:16:04 +0000 Subject: [issue22448] call_at/call_later with Timer cancellation can result in (practically) unbounded memory usage. In-Reply-To: <1411172040.41.0.974691283228.issue22448@psf.upfronthosting.co.za> Message-ID: <1411676164.66.0.884701802237.issue22448@psf.upfronthosting.co.za> Joshua Moore-Oliva added the comment: > Hm. That sounds like you won't actually be interoperable with other asyncio-using code. asyncio code can be interoperated with by spinning off an asyncio coroutine that on completion calls a callback that reschedules a non-asyncio coroutine. I assume we shouldn't be spamming an issue with unrelated chatter, I'd be happy to discuss more via email if you would like. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 22:16:59 2014 From: report at bugs.python.org (Joshua Moore-Oliva) Date: Thu, 25 Sep 2014 20:16:59 +0000 Subject: [issue22448] call_at/call_later with Timer cancellation can result in (practically) unbounded memory usage. In-Reply-To: <1411172040.41.0.974691283228.issue22448@psf.upfronthosting.co.za> Message-ID: <1411676219.94.0.0823898794684.issue22448@psf.upfronthosting.co.za> Joshua Moore-Oliva added the comment: Also - should I close this issue now that a patch has been committed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 22:19:08 2014 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 25 Sep 2014 20:19:08 +0000 Subject: [issue22448] call_at/call_later with Timer cancellation can result in (practically) unbounded memory usage. In-Reply-To: <1411172040.41.0.974691283228.issue22448@psf.upfronthosting.co.za> Message-ID: <1411676348.39.0.456730093709.issue22448@psf.upfronthosting.co.za> Yury Selivanov added the comment: Hm, strange, usually roundup robot closes issues. Anyways, closed now. Thanks again, Joshua. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 22:37:19 2014 From: report at bugs.python.org (Robert Collins) Date: Thu, 25 Sep 2014 20:37:19 +0000 Subject: [issue21472] Fix wsgiref handling of absolute HTTP Request-URI In-Reply-To: <1399807913.92.0.0240575633204.issue21472@psf.upfronthosting.co.za> Message-ID: <1411677439.79.0.760812465123.issue21472@psf.upfronthosting.co.za> Robert Collins added the comment: Oh, also - while its tempting to say that it doesn't matter whether we take the urls host portion, or the host header or the server name - it does. Deployments that look like: LB/Firewall <-> backend container -> WSGI app are likely to have assumptions within the WSGI app about what sort of urls they expect to reach them. We can mitigate this by being very explicit about whatever solution we have. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 22:43:09 2014 From: report at bugs.python.org (Robert Collins) Date: Thu, 25 Sep 2014 20:43:09 +0000 Subject: [issue22264] Add wsgiref.util.dump_wsgistr & load_wsgistr In-Reply-To: <1408884341.89.0.273491669506.issue22264@psf.upfronthosting.co.za> Message-ID: <1411677789.51.0.249073235395.issue22264@psf.upfronthosting.co.za> Robert Collins added the comment: So I guess the API concern I have is that there are two cases: - common spec compliant - US-ASCII + RFC2047 - dealing with exceptions - UTF8 or otherwise The former totally makes sense as a codec, though the current email implementation of it isn't quite a codec. The latter almost wants to be a separate API, which I may propose as part of WSGI for HTTP/2; nevertheless in PEP-3333 its integral to the main API because of the bytes-encoded-as-codepoints-00-ff solution. So, perhaps: - a codec or something looking like it that covers the common case this would not permit specifying codecs on decode, for instance [since RFC2047 is self describing]. - documentation for the uncommon case. *Possibly* a helper function. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 23:06:12 2014 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 25 Sep 2014 21:06:12 +0000 Subject: [issue22464] Speed up fractions implementation In-Reply-To: <1411407434.75.0.285038516488.issue22464@psf.upfronthosting.co.za> Message-ID: <1411679172.29.0.618615574108.issue22464@psf.upfronthosting.co.za> Stefan Behnel added the comment: Sorry for reopening this, but I found one more thing. Division is pretty heavy on PyLong objects and there doesn't seem to be an internal optimisation for division by 1 and -1. Since many Fraction input values can already be normalised for some reason, the following change shaves off almost 30% of the calls to PyNumber_InPlaceFloorDivide() in the telco benchmark during Fraction instantiation according to callgrind, thus saving 20% of the CPU instructions that go into tp_new(). Instead of always executing numerator //= g denominator //= g this avoids unnecessary divisions: if g is not 1: if g is -1: numerator = -numerator denominator = -denominator else: numerator //= g denominator //= g Using the "is" operator here is CPythonish, but doing the same with != and == should also be an improvement already, although not as cheap. Now, given that CPython caches small integers internally, I would suggest actually not adding these two special cases to the fractions module but more generally to the division routines in longobject.c. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 23:10:02 2014 From: report at bugs.python.org (Ronald Oussoren) Date: Thu, 25 Sep 2014 21:10:02 +0000 Subject: [issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew installs fragile In-Reply-To: <1411667909.3.0.75319286515.issue22490@psf.upfronthosting.co.za> Message-ID: <0D1E9A90-EFA0-40F6-8B5D-2D861782DC25@mac.com> Ronald Oussoren added the comment: > On 25 sep. 2014, at 19:58, Ronald Oussoren wrote: > > > Ronald Oussoren added the comment: > > I consider using this undocumented environment variable in distlib as a bug in distlib, which should be fixed Speaking of which... That environment variable shouldn't leak into Python code in the first place, launching a regular Python interpreter from a venv could currently result in unwanted behavior. I'll try to provide an example of that. Ronald > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 23:34:31 2014 From: report at bugs.python.org (Henri Salo) Date: Thu, 25 Sep 2014 21:34:31 +0000 Subject: [issue21831] integer overflow in 'buffer' type allows reading memory In-Reply-To: <1403579483.71.0.894080875478.issue21831@psf.upfronthosting.co.za> Message-ID: <1411680871.58.0.0683802809941.issue21831@psf.upfronthosting.co.za> Henri Salo added the comment: CVE-2014-7185 ---------- nosy: +Henri.Salo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 25 23:36:18 2014 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 25 Sep 2014 21:36:18 +0000 Subject: [issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew installs fragile In-Reply-To: <1411623045.52.0.589017779939.issue22490@psf.upfronthosting.co.za> Message-ID: <1411680978.7.0.889546311369.issue22490@psf.upfronthosting.co.za> Vinay Sajip added the comment: > I consider using this undocumented environment variable in distlib > as a bug in distlib, which should be fixed there. Well, let me explain why it's used: when Python >= 3.3 starts up, it looks for a pyvenv.cfg file proximate to sys.executable. If found, that means we're in a venv, and sys.path is set up accordingly. On OS X, the stub launcher is copied/symlinked to the venv when a new venv is created - the real interpreter is not copied. So, shebangs written by distlib into scripts installed into a venv must be of the form #!/path/to/venv/bin/python, and this cannot be obtained from sys.executable because that is pointing to a framework executable. There would be no pyvenv.cfg anywhere near that location. This is why the __PYVENV_LAUNCHER__ variable was created, and distlib uses it because it needs to conform to how venvs work. In this respect distlib is a bit like setuptools - it needs to understand some low-level details which other libraries don't need to worry about. Scripts installed in venvs work as expected (AFAICT) when used with stock Python framework builds on OS X. With HomeBrew, the complication appears to be caused by two levels of symlink: the executable in /usr/local/ points to one in /usr/local/Cellar/..., which in turn points to the framework executable. The failing test (test_defaults) could be fixed by looking for equivalence in the "home =" directories in the test, rather than a string-contains-value test as at present. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 01:38:14 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 25 Sep 2014 23:38:14 +0000 Subject: [issue22417] PEP 476: verify HTTPS certificates by default In-Reply-To: <1410784469.95.0.475937020841.issue22417@psf.upfronthosting.co.za> Message-ID: <1411688294.8.0.953892856609.issue22417@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 02:07:20 2014 From: report at bugs.python.org (Sai Krishna) Date: Fri, 26 Sep 2014 00:07:20 +0000 Subject: [issue21991] The new email API should use MappingProxyType instead of returning new dicts. In-Reply-To: <1405520998.88.0.739114728398.issue21991@psf.upfronthosting.co.za> Message-ID: <1411690040.64.0.975725199285.issue21991@psf.upfronthosting.co.za> Changes by Sai Krishna : ---------- nosy: +saikrishna17394 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 02:18:52 2014 From: report at bugs.python.org (Claudiu Popa) Date: Fri, 26 Sep 2014 00:18:52 +0000 Subject: [issue22080] Add windows_helper module helper In-Reply-To: <1406378373.46.0.337360125553.issue22080@psf.upfronthosting.co.za> Message-ID: <1411690732.54.0.975153373675.issue22080@psf.upfronthosting.co.za> Changes by Claudiu Popa : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 02:26:09 2014 From: report at bugs.python.org (Claudiu Popa) Date: Fri, 26 Sep 2014 00:26:09 +0000 Subject: [issue21518] Expose RegUnloadKey in winreg In-Reply-To: <1400346760.52.0.0203244636304.issue21518@psf.upfronthosting.co.za> Message-ID: <1411691169.75.0.74049884759.issue21518@psf.upfronthosting.co.za> Claudiu Popa added the comment: Is there something I can do to move this forward? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 02:37:23 2014 From: report at bugs.python.org (Claudiu Popa) Date: Fri, 26 Sep 2014 00:37:23 +0000 Subject: [issue22141] rlcompleter.Completer matches too much In-Reply-To: <1407254399.39.0.799670201718.issue22141@psf.upfronthosting.co.za> Message-ID: <1411691843.31.0.645422162853.issue22141@psf.upfronthosting.co.za> Claudiu Popa added the comment: Looks good. Could you add a test that reproduces the intended behaviour? ---------- nosy: +Claudiu.Popa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 03:24:30 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Fri, 26 Sep 2014 01:24:30 +0000 Subject: [issue22499] [SSL: BAD_WRITE_RETRY] bad write retry in _ssl.c:1636 Message-ID: <1411694670.5.0.645076106925.issue22499@psf.upfronthosting.co.za> New submission from Nikolaus Rath: I received a bugreport due to a crash when calling SSLObject.send(). The traceback ends with: [...] File "/usr/local/lib/python3.4/dist-packages/dugong-3.2-py3.4.egg/dugong/__init__.py", line 584, in _co_send len_ = self._sock.send(buf) File "/usr/lib/python3.4/ssl.py", line 679, in send v = self._sslobj.write(data) ssl.SSLError: [SSL: BAD_WRITE_RETRY] bad write retry (_ssl.c:1636) At first I thought that this is an exception that my application should catch and handle. However, when trying to figure out what exactly BAD_WRITE_RETRY means I get the impression that the fault is actually in Python's _ssl.c. The only places where this error is returned by OpenSSL are ssl/s2_pkt.c:480 and ssl/s3_pkt.c:1179, and in each case the problem seems to be with the caller supplying an invalid buffer after an initial write request failed to complete due to non-blocking IO. This does not seem to be something that could be caused by whatever Python code, so I think there is a problem in _ssl.c. ---------- components: Library (Lib) messages: 227582 nosy: alex, christian.heimes, dstufft, giampaolo.rodola, janssen, nikratio, pitrou priority: normal severity: normal status: open title: [SSL: BAD_WRITE_RETRY] bad write retry in _ssl.c:1636 type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 04:00:24 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 26 Sep 2014 02:00:24 +0000 Subject: [issue20320] select.select(timeout) and select.kqueue.control(timeout) must round the timeout to the upper bound In-Reply-To: <1390264456.23.0.80941463403.issue20320@psf.upfronthosting.co.za> Message-ID: <1411696824.11.0.780398213436.issue20320@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 04:02:59 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 26 Sep 2014 02:02:59 +0000 Subject: [issue20505] Remove resolution from selectors and granularity from asyncio In-Reply-To: <1391470456.74.0.460953910028.issue20505@psf.upfronthosting.co.za> Message-ID: <1411696978.96.0.0230609347046.issue20505@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 04:06:12 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 26 Sep 2014 02:06:12 +0000 Subject: [issue22499] [SSL: BAD_WRITE_RETRY] bad write retry in _ssl.c:1636 In-Reply-To: <1411694670.5.0.645076106925.issue22499@psf.upfronthosting.co.za> Message-ID: <1411697172.25.0.483865880381.issue22499@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Hmm... this sounds like issue8240, except that it should be fixed in 3.4... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 04:06:18 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 26 Sep 2014 02:06:18 +0000 Subject: [issue22499] [SSL: BAD_WRITE_RETRY] bad write retry in _ssl.c:1636 In-Reply-To: <1411694670.5.0.645076106925.issue22499@psf.upfronthosting.co.za> Message-ID: <1411697178.52.0.819483331805.issue22499@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 04:13:11 2014 From: report at bugs.python.org (Tristan Fisher) Date: Fri, 26 Sep 2014 02:13:11 +0000 Subject: [issue22500] Argparse always stores True for positional arguments Message-ID: <1411697591.54.0.644462520859.issue22500@psf.upfronthosting.co.za> New submission from Tristan Fisher: It's my understanding that giving the action="store_true" to an argument in argparse defaults to False. When using non-double-dashed/positional arguments, the argument resorts to True (even if explicitly marked default=False). I've attached a minimal example, but, for clarity, the relevant line is as such: parser.add_argument("meow", action="store_true", default=False) I realize that this might strike some as an odd usage, and I always have the option of using "--meow," but I found it odd that a positional argument is always True, even if not specified in sys.argv. ---------- components: Library (Lib) files: argparse_always_true.py messages: 227584 nosy: Tristan.Fisher priority: normal severity: normal status: open title: Argparse always stores True for positional arguments type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file36727/argparse_always_true.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 04:37:18 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 26 Sep 2014 02:37:18 +0000 Subject: [issue21166] Bus error in pybuilddir.txt 'python -m sysconfigure --generate-posix-vars' build step In-Reply-To: <1396863177.29.0.753462829204.issue21166@psf.upfronthosting.co.za> Message-ID: <1411699038.8.0.723457884961.issue21166@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 04:43:40 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 26 Sep 2014 02:43:40 +0000 Subject: [issue20671] test_create_at_shutdown_with_encoding() of test_io hangs on "SPARC Solaris 10 OpenCSW 3.x" In-Reply-To: <1392716926.59.0.731308582438.issue20671@psf.upfronthosting.co.za> Message-ID: <1411699420.47.0.0952101320474.issue20671@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 05:40:53 2014 From: report at bugs.python.org (paul j3) Date: Fri, 26 Sep 2014 03:40:53 +0000 Subject: [issue22500] Argparse always stores True for positional arguments In-Reply-To: <1411697591.54.0.644462520859.issue22500@psf.upfronthosting.co.za> Message-ID: <1411702853.61.0.523322839452.issue22500@psf.upfronthosting.co.za> paul j3 added the comment: A 'store_true' action takes 0 arguments. In effect `nargs=0`. With an `optional` (flagged) argument, the default `False` is used if the flag is absent, and set to `True` when the flag is encountered (its Action `__call__` function is run). A `positional` is 'encountered' whenever there are enough values to meet its `nargs`. With `nargs=0`, an empty list of strings, i.e. none, is enough. Thus such a `positional` is always found, and its `__call__` is run, setting the value to `True`. As a result, action types like 'store_true', 'store_false', 'store_const' only make sense with `optionals`. And I can't think of simple way of using a 'positional' to set an Namespace 'dest' to boolean values. It could be done with a custom Action, but not with the predefined ones. Or you could translate the values after parsing. ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 06:06:45 2014 From: report at bugs.python.org (Martin Panter) Date: Fri, 26 Sep 2014 04:06:45 +0000 Subject: [issue22474] No explanation of how a task gets destroyed in asyncio 'task' documentation In-Reply-To: <1411516943.46.0.304192335953.issue22474@psf.upfronthosting.co.za> Message-ID: <1411704405.75.0.453556723795.issue22474@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 07:51:36 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Fri, 26 Sep 2014 05:51:36 +0000 Subject: [issue22496] urllib2 fails against IIS (urllib2 can't parse 401 reply www-authenticate headers) In-Reply-To: <1411660131.7.0.581562777837.issue22496@psf.upfronthosting.co.za> Message-ID: <1411710696.24.0.271202255734.issue22496@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Yes, urllib2 does not have any support for NTML based authentication. And it is a long pending feature request too. For 2.7, the best way to handle this might be, instead of crashing on WWW-Authenticate: Negotiate, which is a valid response from IIS (1). It should detect it and fail with a helpful message to use a 3rdparty handler along with urllib2 [2] And for 3.5, I think it is worthy to consider adding the support in stdlib. @Daniel Holth - I see you are the owner of it. If we choose to adopt it, do you give permission to reuse portions of code (with correct attribution) in the stdlib? 1) http://msdn.microsoft.com/en-us/library/ms995330#http-sso-2_topic1 2) https://code.google.com/p/python-ntlm/ ---------- assignee: -> orsenthil nosy: +dholth _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 09:04:11 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Fri, 26 Sep 2014 07:04:11 +0000 Subject: [issue15799] httplib client and statusline In-Reply-To: <1346185891.22.0.123491218752.issue15799@psf.upfronthosting.co.za> Message-ID: <1411715051.88.0.336590643527.issue15799@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Sorry that I did not get involved earlier. It is difficult to prove any problem with the current behavior and it is rightly closed. The issue which was originally raised seems to me a cosmetic one, which won't get exhibited as well. Here is simple test case and the output with the current behavior. # testcases.py testcases = ["HTTP/1.1 200", "HTTP/1.1 200 OK", "HTTP/1.1 200 ", "HTTP/1.1 200"] for tc in testcases: try: version, status, reason = tc.split(None, 2) print "%s (%s,%s,%s)" % (tc, version, status, reason) except ValueError: version, status = tc.split(None, 1) print "%s (%s, %s)" % (tc, version, status) $ python testcases.py HTTP/1.1 200 (HTTP/1.1, 200) HTTP/1.1 200 OK (HTTP/1.1,200,OK) HTTP/1.1 200 (HTTP/1.1, 200 ) HTTP/1.1 200 (HTTP/1.1, 200) The problem is the status code (str at the moment) has a trailing spaces. And now, the status code is not used as string. Just after the parsing, the status is converted to integer, Line 337: status = int(status) and rest of urllib and http/client's behavior use status as int rather than as string. Thanks! ---------- type: enhancement -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 09:13:28 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 26 Sep 2014 07:13:28 +0000 Subject: [issue19645] decouple unittest assertions from the TestCase class In-Reply-To: <1384785494.56.0.149196031493.issue19645@psf.upfronthosting.co.za> Message-ID: <1411715608.7.0.239902102803.issue19645@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here are most popular idioms which deserve special assertion methods: assertHasAttr(obj, name) == assertTrue(hasattr(obj, name)) assertIsSubclass(type, expected) == assertTrue(issubclass(type, expected)) assertTypeIs(obj, expected) == assertIs(type(obj), expected) assertTypedEqual(actual, expected) == assertIs(type(actual), type(expected)) and assertEqual(actual, expected) # or assertIsInstance(actual, type(expected))? assertStartsWith(actual, prefix) == assertTrue(s.startswith(prefix)) assertEndsWith(actual, suffix) == assertTrue(s.endswith(suffix)) assertUnorderedSequenceEqual(first, second) == assertTrue(all(x in second for x in first)) and assertTrue(all(x in first for x in second)) and assertEqual(len(first), len(second)) ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 09:18:39 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 26 Sep 2014 07:18:39 +0000 Subject: [issue19642] shutil to support equivalent of: rm -f /dir/* In-Reply-To: <1384775126.27.0.181995142425.issue19642@psf.upfronthosting.co.za> Message-ID: <1411715919.87.0.156625509574.issue19642@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Rather like this: for n in os.listdir(dirpath): p = os.path.join(dirpath, n) if os.path.isdir(p): shutil.rmtree(p) else: os.unlink(p) ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 09:20:19 2014 From: report at bugs.python.org (paul j3) Date: Fri, 26 Sep 2014 07:20:19 +0000 Subject: [issue22401] argparse: 'resolve' conflict handler damages the actions of the parent parser In-Reply-To: <1410673598.78.0.274465754789.issue22401@psf.upfronthosting.co.za> Message-ID: <1411716019.05.0.567232382407.issue22401@psf.upfronthosting.co.za> Changes by paul j3 : Added file: http://bugs.python.org/file36728/sample3.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 09:20:35 2014 From: report at bugs.python.org (paul j3) Date: Fri, 26 Sep 2014 07:20:35 +0000 Subject: [issue22401] argparse: 'resolve' conflict handler damages the actions of the parent parser In-Reply-To: <1410673598.78.0.274465754789.issue22401@psf.upfronthosting.co.za> Message-ID: <1411716035.05.0.958776986363.issue22401@psf.upfronthosting.co.za> Changes by paul j3 : Removed file: http://bugs.python.org/file36656/sample3.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 09:52:31 2014 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 26 Sep 2014 07:52:31 +0000 Subject: [issue22501] Optimise PyLong division by 1 or -1 Message-ID: <1411717951.94.0.775815371352.issue22501@psf.upfronthosting.co.za> New submission from Stefan Behnel: The attached patch adds fast paths for PyLong division by 1 and -1, as well as dividing 0 by something. This was found helpful for fractions normalisation, as the GCD that is divided by can often be |1|, but firing up the whole division machinery for this eats a lot of CPU cycles for nothing. There are currently two test failures in test_long.py because dividing a huge number by 1 or -1 no longer raises an OverflowError. This is a behavioural change, but I find it acceptable. If others agree, I'll fix the tests and submit a new patch. ---------- components: Interpreter Core files: div_by_1_fast_path.patch keywords: patch messages: 227590 nosy: mark.dickinson, pitrou, scoder, serhiy.storchaka priority: normal severity: normal status: open title: Optimise PyLong division by 1 or -1 type: performance versions: Python 3.5 Added file: http://bugs.python.org/file36729/div_by_1_fast_path.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 09:53:10 2014 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 26 Sep 2014 07:53:10 +0000 Subject: [issue22464] Speed up fractions implementation In-Reply-To: <1411407434.75.0.285038516488.issue22464@psf.upfronthosting.co.za> Message-ID: <1411717990.46.0.307424129086.issue22464@psf.upfronthosting.co.za> Stefan Behnel added the comment: I tried it, but it seems better to open a new ticket for this as there are behavioural changes. See #22501. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 09:54:27 2014 From: report at bugs.python.org (Claudiu Popa) Date: Fri, 26 Sep 2014 07:54:27 +0000 Subject: [issue22143] rlcompleter.Completer has duplicate matches In-Reply-To: <1407255195.5.0.870338576239.issue22143@psf.upfronthosting.co.za> Message-ID: <1411718067.49.0.912696494194.issue22143@psf.upfronthosting.co.za> Claudiu Popa added the comment: The patch looks good. Could you add a test? ---------- nosy: +Claudiu.Popa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 10:12:37 2014 From: report at bugs.python.org (Claudiu Popa) Date: Fri, 26 Sep 2014 08:12:37 +0000 Subject: [issue16512] imghdr doesn't recognize variant jpeg formats In-Reply-To: <1353406880.2.0.236043197389.issue16512@psf.upfronthosting.co.za> Message-ID: <1411719157.33.0.901444016976.issue16512@psf.upfronthosting.co.za> Changes by Claudiu Popa : ---------- stage: patch review -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 10:30:22 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 26 Sep 2014 08:30:22 +0000 Subject: [issue22464] Speed up fractions implementation In-Reply-To: <1411407434.75.0.285038516488.issue22464@psf.upfronthosting.co.za> Message-ID: <1411720222.2.0.117314913631.issue22464@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Please do not use "is" for number comparison. This can be broken unexpectedly in future or on alternative implementation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 10:32:17 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 26 Sep 2014 08:32:17 +0000 Subject: [issue22501] Optimise PyLong division by 1 or -1 In-Reply-To: <1411717951.94.0.775815371352.issue22501@psf.upfronthosting.co.za> Message-ID: <1411720337.45.0.19027241903.issue22501@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Perhaps it would be worth to special case multiplying on 0, 1 and -1 and adding 0, 1 and -1 too. ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 10:51:50 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 26 Sep 2014 08:51:50 +0000 Subject: [issue22501] Optimise PyLong division by 1 or -1 In-Reply-To: <1411717951.94.0.775815371352.issue22501@psf.upfronthosting.co.za> Message-ID: <1411721510.15.0.383669669068.issue22501@psf.upfronthosting.co.za> STINNER Victor added the comment: Any optimization requires a benchmark. What is the speedup? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 10:54:19 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 26 Sep 2014 08:54:19 +0000 Subject: [issue22501] Optimise PyLong division by 1 or -1 In-Reply-To: <1411717951.94.0.775815371352.issue22501@psf.upfronthosting.co.za> Message-ID: <1411721659.94.0.115292962361.issue22501@psf.upfronthosting.co.za> STINNER Victor added the comment: I proposed an optimization for "x << 0" (as part of a larger patch to optimize 2 ** x) but the issue was rejected: http://bugs.python.org/issue21420#msg217802 Mark Dickson wrote (msg217863): "There are many, many tiny optimisations we *could* be making in Objects/longobject.c; each of those potential optimisations adds to the cost of maintaining the code, detracts from readability, and potentially even slows down the common cases fractionally. In general, I think we should only be applying this sort of optimization when there's a clear benefit to real-world code. I don't think this one crosses that line." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 11:03:21 2014 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 26 Sep 2014 09:03:21 +0000 Subject: [issue22501] Optimise PyLong division by 1 or -1 In-Reply-To: <1411717951.94.0.775815371352.issue22501@psf.upfronthosting.co.za> Message-ID: <1411722201.02.0.408766678131.issue22501@psf.upfronthosting.co.za> Stefan Behnel added the comment: Attaching a similar patch for long_mul(). ---------- Added file: http://bugs.python.org/file36730/mul_by_1_fast_path.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 11:08:42 2014 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 26 Sep 2014 09:08:42 +0000 Subject: [issue22501] Optimise PyLong division by 1 or -1 In-Reply-To: <1411717951.94.0.775815371352.issue22501@psf.upfronthosting.co.za> Message-ID: <1411722522.94.0.131797780925.issue22501@psf.upfronthosting.co.za> Stefan Behnel added the comment: > Any optimization requires a benchmark. What is the speedup? I gave numbers in ticket #22464. """ Since many Fraction input values can already be normalised for some reason, the following change shaves off almost 30% of the calls to PyNumber_InPlaceFloorDivide() in the telco benchmark during Fraction instantiation according to callgrind, thus saving 20% of the CPU instructions that go into tp_new(). """ I then proposed to move this into the PyLong type in general, rather than letting Fraction itself do it less efficiently. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 11:22:31 2014 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 26 Sep 2014 09:22:31 +0000 Subject: [issue22501] Optimise PyLong division by 1 or -1 In-Reply-To: <1411717951.94.0.775815371352.issue22501@psf.upfronthosting.co.za> Message-ID: <1411723351.69.0.992569955993.issue22501@psf.upfronthosting.co.za> Stefan Behnel added the comment: @Serhiy: moving the fast path into l_divmod() has the disadvantage of making it even more complex because we'd then also want to determine the modulus, but only if requested, and it can be 1, 0 or -1, depending on the second value. Sounds like a lot more if's. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 11:47:05 2014 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 26 Sep 2014 09:47:05 +0000 Subject: [issue22501] Optimise PyLong division by 1 or -1 In-Reply-To: <1411717951.94.0.775815371352.issue22501@psf.upfronthosting.co.za> Message-ID: <1411724825.0.0.885873013516.issue22501@psf.upfronthosting.co.za> Stefan Behnel added the comment: Combined patch for both mul and div that fixes the return value of long_true_div(), as found by Serhiy, and removes the useless change in long_divrem(), as found by Antoine. Thanks! All test_long.py tests pass now. ---------- Added file: http://bugs.python.org/file36731/mul_div_by_1_fast_path.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 12:05:48 2014 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 26 Sep 2014 10:05:48 +0000 Subject: [issue22501] Optimise PyLong division by 1 or -1 In-Reply-To: <1411717951.94.0.775815371352.issue22501@psf.upfronthosting.co.za> Message-ID: <1411725948.37.0.77203314157.issue22501@psf.upfronthosting.co.za> Stefan Behnel added the comment: @Serhiy: please ignore my comment in msg227599. I'll submit a patch that moves the specialisation to l_divmod(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 12:27:27 2014 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 26 Sep 2014 10:27:27 +0000 Subject: [issue22501] Optimise PyLong division by 1 or -1 In-Reply-To: <1411717951.94.0.775815371352.issue22501@psf.upfronthosting.co.za> Message-ID: <1411727247.13.0.0467200962927.issue22501@psf.upfronthosting.co.za> Stefan Behnel added the comment: Thanks for the reviews, here's a new patch. ---------- Added file: http://bugs.python.org/file36732/mul_div_by_1_fast_path_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 12:35:27 2014 From: report at bugs.python.org (Lorenz Quack) Date: Fri, 26 Sep 2014 10:35:27 +0000 Subject: [issue22141] rlcompleter.Completer matches too much In-Reply-To: <1407254399.39.0.799670201718.issue22141@psf.upfronthosting.co.za> Message-ID: <1411727727.9.0.217990312666.issue22141@psf.upfronthosting.co.za> Lorenz Quack added the comment: Oops! tests sound like a good Idea. I realized my "fix" doesn't work. I had not noticed this before because in my application I had already implemented a workaround :/ The problem with catching the trailing parenthesis is that the group then does not match the attribute of the class. I'll be back with a new patch and test case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 12:42:06 2014 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 26 Sep 2014 10:42:06 +0000 Subject: [issue22501] Optimise PyLong division by 1 or -1 In-Reply-To: <1411717951.94.0.775815371352.issue22501@psf.upfronthosting.co.za> Message-ID: <1411728126.85.0.9070264603.issue22501@psf.upfronthosting.co.za> Changes by Stefan Behnel : Removed file: http://bugs.python.org/file36732/mul_div_by_1_fast_path_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 12:43:16 2014 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 26 Sep 2014 10:43:16 +0000 Subject: [issue22501] Optimise PyLong division by 1 or -1 In-Reply-To: <1411717951.94.0.775815371352.issue22501@psf.upfronthosting.co.za> Message-ID: <1411728196.59.0.398239427728.issue22501@psf.upfronthosting.co.za> Stefan Behnel added the comment: Sorry, last patch version contained a "use before type check" bug. ---------- Added file: http://bugs.python.org/file36733/mul_div_by_1_fast_path_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 12:57:27 2014 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 26 Sep 2014 10:57:27 +0000 Subject: [issue22501] Optimise PyLong division by 1 or -1 In-Reply-To: <1411717951.94.0.775815371352.issue22501@psf.upfronthosting.co.za> Message-ID: <1411729047.39.0.0647147756114.issue22501@psf.upfronthosting.co.za> Stefan Behnel added the comment: Here is an incremental patch that adds fast paths for adding and subtracting 0. Question: the module calls long_long() in some places (e.g. long_abs()) and thus forces the return type to be exactly a PyLong and not a subtype. My changes use a plain "incref+return input value" in some places. Should they call long_long() on it instead? ---------- Added file: http://bugs.python.org/file36734/add_sub_0_fast_path.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 13:09:41 2014 From: report at bugs.python.org (Chris E) Date: Fri, 26 Sep 2014 11:09:41 +0000 Subject: [issue13611] Integrate ElementC14N module into xml.etree package In-Reply-To: <1324023461.04.0.625039310668.issue13611@psf.upfronthosting.co.za> Message-ID: <1411729781.93.0.825973002581.issue13611@psf.upfronthosting.co.za> Chris E added the comment: Whilst in most cases this would be correct, in this case it looks like the original contributor took a subset of what the original author wrote and put it into the python libraries. Until relatively recently the ElementTree.py file included a stanza that attempted to import the ElementC14N module and conditionally set up the 'c14n' key value in _serialize ---------- nosy: +cbz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 13:19:58 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 26 Sep 2014 11:19:58 +0000 Subject: [issue22501] Optimise PyLong division by 1 or -1 In-Reply-To: <1411729047.39.0.0647147756114.issue22501@psf.upfronthosting.co.za> Message-ID: <54254BDC.7000102@free.fr> Antoine Pitrou added the comment: Le 26/09/2014 12:57, Stefan Behnel a ?crit : > > Question: the module calls long_long() in some places (e.g. long_abs()) and thus forces the return type to be exactly a PyLong and not a subtype. My changes use a plain "incref+return input value" in some places. Should they call long_long() on it instead? Ah, yes, they should. The return type should not depend on the input *values* :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 13:32:56 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 26 Sep 2014 11:32:56 +0000 Subject: [issue8212] A tp_dealloc of a subclassed class cannot resurrect an object In-Reply-To: <1269350912.78.0.210466349131.issue8212@psf.upfronthosting.co.za> Message-ID: <1411731176.65.0.240432552038.issue8212@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I think PEP 442 makes this request obsolete: you can simply implement tp_finalize() and incref the object naturally from there. Kristjan, what do you think? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 13:38:51 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 26 Sep 2014 11:38:51 +0000 Subject: [issue13611] Integrate ElementC14N module into xml.etree package In-Reply-To: <1324023461.04.0.625039310668.issue13611@psf.upfronthosting.co.za> Message-ID: <1411731531.97.0.198428273806.issue13611@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +eli.bendersky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 13:43:41 2014 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 26 Sep 2014 11:43:41 +0000 Subject: [issue22501] Optimise PyLong division by 1 or -1 In-Reply-To: <1411717951.94.0.775815371352.issue22501@psf.upfronthosting.co.za> Message-ID: <1411731821.21.0.516275458886.issue22501@psf.upfronthosting.co.za> Stefan Behnel added the comment: Ok, updating both patches. ---------- Added file: http://bugs.python.org/file36735/add_sub_0_fast_path_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 13:44:24 2014 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 26 Sep 2014 11:44:24 +0000 Subject: [issue22501] Optimise PyLong division by 1 or -1 In-Reply-To: <1411717951.94.0.775815371352.issue22501@psf.upfronthosting.co.za> Message-ID: <1411731864.18.0.388360206767.issue22501@psf.upfronthosting.co.za> Changes by Stefan Behnel : Added file: http://bugs.python.org/file36736/mul_div_by_1_fast_path_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 14:05:17 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 26 Sep 2014 12:05:17 +0000 Subject: [issue22197] Allow better verbosity / output control in test cases In-Reply-To: <1408030741.18.0.985330245232.issue22197@psf.upfronthosting.co.za> Message-ID: <1411733117.2.0.448392910471.issue22197@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +rbcollins _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 14:34:55 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 26 Sep 2014 12:34:55 +0000 Subject: [issue17462] argparse FAQ: how it is different from optparse In-Reply-To: <1363624948.23.0.605198582935.issue17462@psf.upfronthosting.co.za> Message-ID: <20140926123450.82055.49466@mail.hg.python.org> Roundup Robot added the comment: New changeset 84313c61e60d by Berker Peksag in branch '3.4': Issue #17462: Add a paragraph about advantages of argparse over optparse. https://hg.python.org/cpython/rev/84313c61e60d New changeset 45e1c0029aff by Berker Peksag in branch 'default': Issue #17462: Add a paragraph about advantages of argparse over optparse. https://hg.python.org/cpython/rev/45e1c0029aff ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 14:37:45 2014 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 26 Sep 2014 12:37:45 +0000 Subject: [issue22501] Optimise PyLong division by 1 or -1 In-Reply-To: <1411717951.94.0.775815371352.issue22501@psf.upfronthosting.co.za> Message-ID: <1411735065.39.0.506296538023.issue22501@psf.upfronthosting.co.za> Stefan Behnel added the comment: I reran the fractions benchmark over the final result and the overall gain turned out to be, well, small. It's a clearly reproducible 2-3% faster. That's not bad for the macro impact of a micro-optimisation, but it's not a clear argument for throwing more code at it either. I'll leave it to you to decide. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 14:38:58 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 26 Sep 2014 12:38:58 +0000 Subject: [issue17462] argparse FAQ: how it is different from optparse In-Reply-To: <1363624948.23.0.605198582935.issue17462@psf.upfronthosting.co.za> Message-ID: <20140926123854.82106.21688@mail.hg.python.org> Roundup Robot added the comment: New changeset 4eb847e7ddde by Berker Peksag in branch '2.7': Issue #17462: Add a paragraph about advantages of argparse over optparse. https://hg.python.org/cpython/rev/4eb847e7ddde ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 14:40:25 2014 From: report at bugs.python.org (Berker Peksag) Date: Fri, 26 Sep 2014 12:40:25 +0000 Subject: [issue17462] argparse FAQ: how it is different from optparse In-Reply-To: <1363624948.23.0.605198582935.issue17462@psf.upfronthosting.co.za> Message-ID: <1411735225.17.0.200457731014.issue17462@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch, Anastasia. ---------- assignee: eric.araujo -> berker.peksag keywords: +easy nosy: +berker.peksag resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 14:50:11 2014 From: report at bugs.python.org (Berker Peksag) Date: Fri, 26 Sep 2014 12:50:11 +0000 Subject: [issue19610] setup.py does not allow a tuple for classifiers In-Reply-To: <1384514692.62.0.115546674646.issue19610@psf.upfronthosting.co.za> Message-ID: <1411735811.89.0.845330949764.issue19610@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- assignee: -> berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 15:06:02 2014 From: report at bugs.python.org (Stefan Krah) Date: Fri, 26 Sep 2014 13:06:02 +0000 Subject: [issue22327] test_gdb failures on Ubuntu 14.10 In-Reply-To: <1409690431.38.0.272932349651.issue22327@psf.upfronthosting.co.za> Message-ID: <1411736762.49.0.0588166807754.issue22327@psf.upfronthosting.co.za> Stefan Krah added the comment: I'm seeing the same, it could be an Ubuntu issue: https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1348275 ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 15:09:19 2014 From: report at bugs.python.org (Berker Peksag) Date: Fri, 26 Sep 2014 13:09:19 +0000 Subject: [issue16324] MIMEText __init__ does not support Charset instance In-Reply-To: <1351180172.93.0.972082460953.issue16324@psf.upfronthosting.co.za> Message-ID: <1411736959.92.0.817312389765.issue16324@psf.upfronthosting.co.za> Berker Peksag added the comment: Here's an updated patch. ---------- nosy: +berker.peksag stage: -> patch review type: behavior -> enhancement versions: +Python 3.5 -Python 3.2 Added file: http://bugs.python.org/file36737/issue16324_v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 15:40:06 2014 From: report at bugs.python.org (Stefan Krah) Date: Fri, 26 Sep 2014 13:40:06 +0000 Subject: [issue22445] Memoryviews require more strict contiguous checks then necessary In-Reply-To: <1411153250.02.0.529032306838.issue22445@psf.upfronthosting.co.za> Message-ID: <1411738806.3.0.0901652933404.issue22445@psf.upfronthosting.co.za> Stefan Krah added the comment: Ok, here's my take on the situation: 1) As far as Python is concerned, shape[0] == 1 was already special-cased, so people could not rely on canonical Fortran or C strides anyway. 2) Accessing an element via strides should be done using PyBuffer_GetPointer(), which can of course handle non-canonical strides. 3) Breakage will only affect NumPy users, since practically no one else is using multidimensional arrays. Regarding your option 2b): I think it may be confusing, the buffer protocol is already so complicated. So, I think purity wins here. If you are sure that all future NumPy versions will ship with precise contiguity checks, then I'll commit the new patch in 3.5 (earlier versions should not be changed IMO). I've moved the checks for 0 in shape[i] to the beginning (len == 0). I hope there are no applications that set len incorrectly, but they would be severely broken anyway. ---------- stage: -> patch review versions: +Python 3.5 Added file: http://bugs.python.org/file36738/issue22445.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 16:05:02 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 26 Sep 2014 14:05:02 +0000 Subject: [issue16324] MIMEText __init__ does not support Charset instance In-Reply-To: <1351180172.93.0.972082460953.issue16324@psf.upfronthosting.co.za> Message-ID: <1411740302.59.0.943124493876.issue16324@psf.upfronthosting.co.za> R. David Murray added the comment: The updated patch looks good to me. Go ahead and commit it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 16:08:54 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 26 Sep 2014 14:08:54 +0000 Subject: [issue19642] shutil to support equivalent of: rm -f /dir/* In-Reply-To: <1384775126.27.0.181995142425.issue19642@psf.upfronthosting.co.za> Message-ID: <1411740534.15.0.212027408521.issue19642@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > "rm -rf /dir" Isn't it shutil.rmtree()? Am I missing something? > "rm -f /dir/*" So it should skip dotted files, or remove them? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 17:01:58 2014 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 26 Sep 2014 15:01:58 +0000 Subject: [issue22486] Add math.gcd() In-Reply-To: <1411591235.17.0.168367966743.issue22486@psf.upfronthosting.co.za> Message-ID: <1411743717.99.0.619655315403.issue22486@psf.upfronthosting.co.za> Stefan Behnel added the comment: Thanks, Serhiy. However, something is wrong with the implementation. The benchmark runs into an infinite loop (it seems). And so do the previous patches. Does it work for you? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 17:06:22 2014 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 26 Sep 2014 15:06:22 +0000 Subject: [issue22486] Add math.gcd() In-Reply-To: <1411591235.17.0.168367966743.issue22486@psf.upfronthosting.co.za> Message-ID: <1411743982.74.0.981210254703.issue22486@psf.upfronthosting.co.za> Stefan Behnel added the comment: I compiled it with 30 bit digits, in case that's relevant. (It might be.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 17:10:14 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 26 Sep 2014 15:10:14 +0000 Subject: [issue22197] Allow better verbosity / output control in test cases In-Reply-To: <1408030741.18.0.985330245232.issue22197@psf.upfronthosting.co.za> Message-ID: <1411744214.68.0.630819396549.issue22197@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There is the verbose attribute of the test.support module. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 17:20:44 2014 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 26 Sep 2014 15:20:44 +0000 Subject: [issue22197] Allow better verbosity / output control in test cases In-Reply-To: <1408030741.18.0.985330245232.issue22197@psf.upfronthosting.co.za> Message-ID: <1411744844.93.0.356872138618.issue22197@psf.upfronthosting.co.za> Ezio Melotti added the comment: That only works for the CPython test suite (and it's not a public API). FWIW I'm +1 on the idea, but I would have to see how it will get implemented in a patch. ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 17:21:26 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 26 Sep 2014 15:21:26 +0000 Subject: [issue22486] Add math.gcd() In-Reply-To: <1411743717.99.0.619655315403.issue22486@psf.upfronthosting.co.za> Message-ID: <1647804.cIdT3ZWbto@raxxla> Serhiy Storchaka added the comment: It works to me (compiled with 15-bit digits). Cold you please add debugging prints (before and after the call of math.gcd()) and find which operation is looping (math.gcd() itself, and for what arguments, or some Python code)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 17:21:50 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 26 Sep 2014 15:21:50 +0000 Subject: [issue22197] Allow better verbosity / output control in test cases In-Reply-To: <1408030741.18.0.985330245232.issue22197@psf.upfronthosting.co.za> Message-ID: <1411744910.79.0.982852307313.issue22197@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 17:29:31 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 26 Sep 2014 15:29:31 +0000 Subject: [issue22197] Allow better verbosity / output control in test cases In-Reply-To: <1411744844.93.0.356872138618.issue22197@psf.upfronthosting.co.za> Message-ID: <2597534.Fss5oYmycT@raxxla> Serhiy Storchaka added the comment: Usages of test.support.verbose should be replaced by self.verbosity. As for output buffering, may be replace sys.stdout by file-like object which flushes its buffered content to original stdout on failure and discard it on success. Or add the self.log file-like object with such behavior and redirect all verbose output to it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 17:34:27 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 26 Sep 2014 15:34:27 +0000 Subject: [issue22501] Optimise PyLong division by 1 or -1 In-Reply-To: <1411717951.94.0.775815371352.issue22501@psf.upfronthosting.co.za> Message-ID: <1411745667.1.0.13137820843.issue22501@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Oh, such small gain and only on one specific benchmark not included still in standard benchmark suite, looks discourage. May be other benchmarks have gain from these changes? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 17:35:02 2014 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 26 Sep 2014 15:35:02 +0000 Subject: [issue22197] Allow better verbosity / output control in test cases In-Reply-To: <1408030741.18.0.985330245232.issue22197@psf.upfronthosting.co.za> Message-ID: <1411745702.17.0.945543928309.issue22197@psf.upfronthosting.co.za> Ezio Melotti added the comment: > As for output buffering, may be replace sys.stdout by file-like object > which flushes its buffered content to original stdout on failure and > discard it on success. This is what the --buffer option is already supposed to do (I only found out about it thanks to this issue, the name is not very indicative of what it does...). IIUC what Antoine is suggesting is having a more fine-grained control of the buffering, and the ability to set it from individual test cases rather than using a global command line flag or unittest.main(buffer=True) (which is only used while executing the test file directly). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 17:47:46 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 26 Sep 2014 15:47:46 +0000 Subject: [issue22501] Optimise PyLong division by 1 or -1 In-Reply-To: <1411745667.1.0.13137820843.issue22501@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > 2-3% faster 3% is not enough to justify the change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 17:56:06 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 26 Sep 2014 15:56:06 +0000 Subject: [issue22197] Allow better verbosity / output control in test cases In-Reply-To: <1408030741.18.0.985330245232.issue22197@psf.upfronthosting.co.za> Message-ID: <1411746966.46.0.591803656115.issue22197@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Indeed, I'm sorry for suggesting two features in one issue :-) Feature #1 is "self.verbosity" (as a read-only variable) on test cases. Sounds like a no-brainer, IMHO :-) Feature #2 is selective enabling of the buffering feature in test cases. This rather misnamed features only prints out stdout when the test fails, which is useful when you want permanent debug statements that only pollute stdout when there is a test failure. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 17:56:51 2014 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 26 Sep 2014 15:56:51 +0000 Subject: [issue22486] Add math.gcd() In-Reply-To: <1411591235.17.0.168367966743.issue22486@psf.upfronthosting.co.za> Message-ID: <1411747011.23.0.598611194128.issue22486@psf.upfronthosting.co.za> Stefan Behnel added the comment: This is what hangs for me: math.gcd(1216342683557601535506311712, 436522681849110124616458784) "a" and "b" keep switching between both values, but otherwise, the loop just keeps running. The old fractions.gcd() gives 32 for them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 18:03:17 2014 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 26 Sep 2014 16:03:17 +0000 Subject: [issue22486] Add math.gcd() In-Reply-To: <1411591235.17.0.168367966743.issue22486@psf.upfronthosting.co.za> Message-ID: <1411747397.77.0.704716192491.issue22486@psf.upfronthosting.co.za> Stefan Behnel added the comment: I can confirm that it works with 15 bit digits. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 18:33:17 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 26 Sep 2014 16:33:17 +0000 Subject: [issue18554] os.__all__ is incomplete In-Reply-To: <1374759898.69.0.624700414808.issue18554@psf.upfronthosting.co.za> Message-ID: <20140926163311.47405.73592@mail.hg.python.org> Roundup Robot added the comment: New changeset 7230978647a8 by Yury Selivanov in branch 'default': os: Include posix functions in os.__all__. Closes issue #18554. https://hg.python.org/cpython/rev/7230978647a8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 18:34:24 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 26 Sep 2014 16:34:24 +0000 Subject: [issue18554] os.__all__ is incomplete In-Reply-To: <1374759898.69.0.624700414808.issue18554@psf.upfronthosting.co.za> Message-ID: <1411749264.33.0.0707258470809.issue18554@psf.upfronthosting.co.za> Yury Selivanov added the comment: Thanks for the patch. I've committed this to 3.5 only, as there is a slight chance that it breaks backwards compatibility for some scripts. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 18:37:23 2014 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 26 Sep 2014 16:37:23 +0000 Subject: [issue22501] Optimise PyLong division by 1 or -1 In-Reply-To: <1411717951.94.0.775815371352.issue22501@psf.upfronthosting.co.za> Message-ID: <1411749443.66.0.910454259689.issue22501@psf.upfronthosting.co.za> Stefan Behnel added the comment: Since Serhiy gave another round of valid feedback, here's an updated patch. ---------- Added file: http://bugs.python.org/file36739/mul_div_by_1_fast_path_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 18:44:01 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 26 Sep 2014 16:44:01 +0000 Subject: [issue22203] inspect.getargspec() returns wrong spec for builtins In-Reply-To: <1408080032.86.0.165011450626.issue22203@psf.upfronthosting.co.za> Message-ID: <1411749841.85.0.91299683045.issue22203@psf.upfronthosting.co.za> Yury Selivanov added the comment: The problem is that map & filter are classes, and their __init__ and __new__ methods do not provide any text_signature, hence signature uses the one from object.__init__. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 18:44:44 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 26 Sep 2014 16:44:44 +0000 Subject: [issue22203] inspect.getargspec() returns wrong spec for builtins In-Reply-To: <1408080032.86.0.165011450626.issue22203@psf.upfronthosting.co.za> Message-ID: <1411749884.14.0.130622818039.issue22203@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 18:51:05 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 26 Sep 2014 16:51:05 +0000 Subject: [issue22437] re module: number of named groups is limited to 100 max In-Reply-To: <1411061982.07.0.646375842297.issue22437@psf.upfronthosting.co.za> Message-ID: <1411750265.36.0.478015473901.issue22437@psf.upfronthosting.co.za> Yury Selivanov added the comment: I'm fine with either one, Serhiy. The static one looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 19:15:08 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 26 Sep 2014 17:15:08 +0000 Subject: [issue22203] inspect.getargspec() returns wrong spec for builtins In-Reply-To: <1408080032.86.0.165011450626.issue22203@psf.upfronthosting.co.za> Message-ID: <1411751708.19.0.927313821961.issue22203@psf.upfronthosting.co.za> Larry Hastings added the comment: We should be able to get proper signatures for 3.5. For 3.4, probably the best thing is to prevent the signature / raise an error. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 19:28:05 2014 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 26 Sep 2014 17:28:05 +0000 Subject: [issue22486] Add math.gcd() In-Reply-To: <1411591235.17.0.168367966743.issue22486@psf.upfronthosting.co.za> Message-ID: <1411752485.95.0.976663336327.issue22486@psf.upfronthosting.co.za> Mark Dickinson added the comment: To avoid regressions, please can we leave the old `fractions.gcd` exactly as it was? For example, the current `fractions.gcd` *does* work for Fraction instances [1]. That's certainly not its intended use, but I wouldn't be surprised if there's code out there that uses it in that way. It also just happens to work for nonnegative finite float inputs, because a % b gives exact results when a and b are positive floats, so no error is introduced at any point. I'd also worry about breaking existing uses involving integer-like objects (instances of numpy.int64, for example) in place of instances of ints. [1] By "works", I mean that if a and b are Fractions then gcd(a, b) returns a Fraction such that (1) a and b are integer multiples of gcd(a, b), and (2) gcd(a, b) is an integer multiple of any other number with this property. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 19:28:54 2014 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 26 Sep 2014 17:28:54 +0000 Subject: [issue22486] Add math.gcd() In-Reply-To: <1411591235.17.0.168367966743.issue22486@psf.upfronthosting.co.za> Message-ID: <1411752534.82.0.190443231167.issue22486@psf.upfronthosting.co.za> Mark Dickinson added the comment: > This is what hangs for me: Uh-oh. Sounds like I screwed up somewhere. I'll take a look this weekend, unless Serhiy beats me too it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 19:29:48 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 26 Sep 2014 17:29:48 +0000 Subject: [issue22460] idle editor: replace all in selection In-Reply-To: <1411381735.15.0.967867369025.issue22460@psf.upfronthosting.co.za> Message-ID: <1411752588.28.0.181006018475.issue22460@psf.upfronthosting.co.za> Terry J. Reedy added the comment: This is an interesting idea, but not a high priority. One can selectively replace now with [Find], [Replace], and [Replace+Find] buttons. I have been thinking about improving the Search and Replace dialogs, so I will not immediately reject this. Some additional comments follow. A changed method name has to be replaced in all use sites, not just in the class definition. Some editors will make replacements across multiple files. Renaming a local variable in a def statement, or the loop variable in a for statement (using the [X] whole word option) would be good uses. [Replace All] could be defined to only apply to a selection when there is a selection. The new feature would be more useful if there were a 'select suite' or 'select statement' command that would, for instance, select an entire def statement if the cursor were on the first line, with the 'def' keyword. Currently, on Windows, the 'found' highlight does not work when there is a selection. That might be a simple fix. There is already an issue for fixing Search dialogs. Do you know of any other editors with this feature? ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 19:30:27 2014 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 26 Sep 2014 17:30:27 +0000 Subject: [issue22486] Add math.gcd() In-Reply-To: <1411591235.17.0.168367966743.issue22486@psf.upfronthosting.co.za> Message-ID: <1411752627.97.0.129152899088.issue22486@psf.upfronthosting.co.za> Mark Dickinson added the comment: > too it. Bah. "to it". Stupid fingers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 19:42:01 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 26 Sep 2014 17:42:01 +0000 Subject: [issue22486] Add math.gcd() In-Reply-To: <1411747011.23.0.598611194128.issue22486@psf.upfronthosting.co.za> Message-ID: <24342987.L6z30fR5l0@raxxla> Serhiy Storchaka added the comment: Thank you Stefan. I confirm that it hangs with 30-bit digits. One existing bug is in the use of PyLong_AsLong() before simple Euclidean loop. It should be PyLong_AsLongLong() if the long is not enough for two digits. But there is another bug in inner loop... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 19:42:43 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 26 Sep 2014 17:42:43 +0000 Subject: [issue22466] problem with installing python 2.7.8 In-Reply-To: <1411436875.43.0.487980102228.issue22466@psf.upfronthosting.co.za> Message-ID: <1411753363.65.0.277676402517.issue22466@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Khalid, when responding by email, please delete the message you are responding to. Steve, is there any reason to leave this open? IE, do you plan to change the installer in response to this? ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 19:47:13 2014 From: report at bugs.python.org (Steve Dower) Date: Fri, 26 Sep 2014 17:47:13 +0000 Subject: [issue22466] problem with installing python 2.7.8 In-Reply-To: <1411436875.43.0.487980102228.issue22466@psf.upfronthosting.co.za> Message-ID: <1411753633.89.0.878568650927.issue22466@psf.upfronthosting.co.za> Steve Dower added the comment: Nope - closed. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 19:57:23 2014 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 26 Sep 2014 17:57:23 +0000 Subject: [issue22501] Optimise PyLong division by 1 or -1 In-Reply-To: <1411717951.94.0.775815371352.issue22501@psf.upfronthosting.co.za> Message-ID: <1411754243.91.0.709314947968.issue22501@psf.upfronthosting.co.za> Stefan Behnel added the comment: I callgrinded it again and it confirmed that the gain when doing this inside of long_div() and friends is way lower than doing it right in Fraction.__new__(). It's not safe to do there, though, as "is" tests on integers are generally not a good idea in Python code. (Although it doesn't break anything if it fails, as it's a pure optimisation to avoid useless overhead.) The micro benchmarks with timeit confirm that it's as fast as expected. Large numbers before: $ ./python -m timeit -s 'x = 2**2000 + 3**234 + 5**891 + 7**1234' ' -x' 10000000 loops, best of 3: 0.177 usec per loop $ ./python -m timeit -s 'x = 2**2000 + 3**234 + 5**891 + 7**1234' 'x * -2' 1000000 loops, best of 3: 0.329 usec per loop $ ./python -m timeit -s 'x = 2**2000 + 3**234 + 5**891 + 7**1234' 'x // -2' 100000 loops, best of 3: 2.8 usec per loop $ ./python -m timeit -s 'x = 2**2000 + 3**234 + 5**891 + 7**1234' 'x * -1' 1000000 loops, best of 3: 0.329 usec per loop $ ./python -m timeit -s 'x = 2**2000 + 3**234 + 5**891 + 7**1234' 'x // -1' 100000 loops, best of 3: 2.36 usec per loop $ ./python -m timeit -s 'x = 2**2000 + 3**234 + 5**891 + 7**1234' 'x * 1' 1000000 loops, best of 3: 0.333 usec per loop $ ./python -m timeit -s 'x = 2**2000 + 3**234 + 5**891 + 7**1234' 'x // 1' 100000 loops, best of 3: 2.37 usec per loop Patched: $ ./python -m timeit -s 'x = 2**2000 + 3**234 + 5**891 + 7**1234' ' -x' 10000000 loops, best of 3: 0.176 usec per loop $ ./python -m timeit -s 'x = 2**2000 + 3**234 + 5**891 + 7**1234' 'x * -2' 1000000 loops, best of 3: 0.328 usec per loop $ ./python -m timeit -s 'x = 2**2000 + 3**234 + 5**891 + 7**1234' 'x // -2' 100000 loops, best of 3: 2.8 usec per loop $ ./python -m timeit -s 'x = 2**2000 + 3**234 + 5**891 + 7**1234' 'x * -1' 10000000 loops, best of 3: 0.177 usec per loop $ ./python -m timeit -s 'x = 2**2000 + 3**234 + 5**891 + 7**1234' 'x // -1' 10000000 loops, best of 3: 0.178 usec per loop $ ./python -m timeit -s 'x = 2**2000 + 3**234 + 5**891 + 7**1234' 'x * 1' 10000000 loops, best of 3: 0.0244 usec per loop $ ./python -m timeit -s 'x = 2**2000 + 3**234 + 5**891 + 7**1234' 'x // 1' 10000000 loops, best of 3: 0.0258 usec per loop Small numbers before: $ ./python -m timeit -s 'x = 5' 'x * -2' 10000000 loops, best of 3: 0.0408 usec per loop $ ./python -m timeit -s 'x = 5' 'x // -2' 10000000 loops, best of 3: 0.0714 usec per loop $ ./python -m timeit -s 'x = 5' 'x * -1' 10000000 loops, best of 3: 0.0293 usec per loop $ ./python -m timeit -s 'x = 5' 'x * 1' 10000000 loops, best of 3: 0.0282 usec per loop $ ./python -m timeit -s 'x = 5' 'x // 1' 10000000 loops, best of 3: 0.0529 usec per loop $ ./python -m timeit -s 'x = 5' 'x // -1' 10000000 loops, best of 3: 0.0536 usec per loop Patched: $ ./python -m timeit -s 'x = 5' 'x * -2' 10000000 loops, best of 3: 0.0391 usec per loop $ ./python -m timeit -s 'x = 5' 'x // -2' 10000000 loops, best of 3: 0.0718 usec per loop $ ./python -m timeit -s 'x = 5' 'x * -1' 10000000 loops, best of 3: 0.0267 usec per loop $ ./python -m timeit -s 'x = 5' 'x * 1' 10000000 loops, best of 3: 0.0265 usec per loop $ ./python -m timeit -s 'x = 5' 'x // 1' 10000000 loops, best of 3: 0.0259 usec per loop $ ./python -m timeit -s 'x = 5' 'x // -1' 10000000 loops, best of 3: 0.0285 usec per loop Note: we're talking ?secs here, not usually something to worry about. And it's unlikely that other benchmarks see similarly "high" speedups as the one for fractions (due to the relatively high likelihood of the GCD being 1 there). I'm ok with closing this ticket as "won't fix". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 20:37:00 2014 From: report at bugs.python.org (Petr Viktorin) Date: Fri, 26 Sep 2014 18:37:00 +0000 Subject: [issue22444] Floor divide should return int In-Reply-To: <1411145815.79.0.695099073811.issue22444@psf.upfronthosting.co.za> Message-ID: <1411756620.22.0.367001915566.issue22444@psf.upfronthosting.co.za> Changes by Petr Viktorin : ---------- nosy: +encukou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 22:30:23 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 26 Sep 2014 20:30:23 +0000 Subject: [issue17319] http.server.BaseHTTPRequestHandler send_response_only doesn't check the type and value of the code. In-Reply-To: <1362024725.4.0.923647295599.issue17319@psf.upfronthosting.co.za> Message-ID: <1411763423.62.0.848355303912.issue17319@psf.upfronthosting.co.za> Yury Selivanov added the comment: I left some comments in the codereview. I think that having some half-baked solution is great, but I really would like to see a proper fix, i.e. with remove_header and other methods fixed. Ideally, you should add a UserDict implementation for headers that implements proper __XXXitem__ methods. ---------- nosy: +yselivanov versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 22:31:14 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 26 Sep 2014 20:31:14 +0000 Subject: [issue5550] [urllib.request]: Comparison of HTTP headers should be insensitive to the case In-Reply-To: <1237870141.83.0.616869799184.issue5550@psf.upfronthosting.co.za> Message-ID: <1411763473.98.0.959664056184.issue5550@psf.upfronthosting.co.za> Yury Selivanov added the comment: I left some comments in the codereview. I think that having some half-baked solution is great, but I really would like to see a proper fix, i.e. with remove_header and other methods fixed. Ideally, you should add a UserDict implementation for headers that implements proper __XXXitem__ methods. ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 22:32:04 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 26 Sep 2014 20:32:04 +0000 Subject: [issue17319] http.server.BaseHTTPRequestHandler send_response_only doesn't check the type and value of the code. In-Reply-To: <1362024725.4.0.923647295599.issue17319@psf.upfronthosting.co.za> Message-ID: <1411763524.68.0.709089006398.issue17319@psf.upfronthosting.co.za> Yury Selivanov added the comment: Oups, my previous comment is related to issue #5550, wrong window. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 22:35:44 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 26 Sep 2014 20:35:44 +0000 Subject: [issue5550] [urllib.request]: Comparison of HTTP headers should be insensitive to the case In-Reply-To: <1237870141.83.0.616869799184.issue5550@psf.upfronthosting.co.za> Message-ID: <1411763744.89.0.218164009867.issue5550@psf.upfronthosting.co.za> Yury Selivanov added the comment: Ideally, we should just wait when PEP 455 lands, so we can use TransformDict for headers. Also, I don't think we can land a fix for this in any pythons out there, I would focus on making this right in 3.5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 23:02:50 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 26 Sep 2014 21:02:50 +0000 Subject: [issue20267] TemporaryDirectory does not resolve path when created using a relative path In-Reply-To: <1389761308.4.0.00958902784577.issue20267@psf.upfronthosting.co.za> Message-ID: <1411765370.34.0.168182861616.issue20267@psf.upfronthosting.co.za> Yury Selivanov added the comment: A second version of the patch (tempfile_02), fixing more tempfile functions to properly support relative paths. Please review. ---------- nosy: +serhiy.storchaka Added file: http://bugs.python.org/file36740/tempfile_02.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 23:08:55 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 26 Sep 2014 21:08:55 +0000 Subject: [issue21397] tempfile.py: Fix grammar in docstring, comment typos In-Reply-To: <1398854871.81.0.354739462705.issue21397@psf.upfronthosting.co.za> Message-ID: <20140926210848.47413.63423@mail.hg.python.org> Roundup Robot added the comment: New changeset adac8ba7b1b1 by Yury Selivanov in branch '2.7': tempfile: Fix docstring. Issue #21397, patch by R. David Murray. https://hg.python.org/cpython/rev/adac8ba7b1b1 New changeset 500d3d6f22ff by Yury Selivanov in branch '3.4': tempfile: Fix docstring. Issue #21397, patch by R. David Murray. https://hg.python.org/cpython/rev/500d3d6f22ff New changeset db17f57c32af by Yury Selivanov in branch 'default': tempfile: Fix docstring. Issue #21397, patch by R. David Murray. https://hg.python.org/cpython/rev/db17f57c32af ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 23:09:14 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 26 Sep 2014 21:09:14 +0000 Subject: [issue21397] tempfile.py: Fix grammar in docstring, comment typos In-Reply-To: <1398854871.81.0.354739462705.issue21397@psf.upfronthosting.co.za> Message-ID: <1411765754.94.0.199958001869.issue21397@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 23:32:17 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 26 Sep 2014 21:32:17 +0000 Subject: [issue5309] distutils doesn't parallelize extension module compilation In-Reply-To: <1235007592.93.0.0598331575131.issue5309@psf.upfronthosting.co.za> Message-ID: <20140926213204.82106.47860@mail.hg.python.org> Roundup Robot added the comment: New changeset bbe57429eba0 by Antoine Pitrou in branch 'default': Issue #5309: distutils' build and build_ext commands now accept a ``-j`` https://hg.python.org/cpython/rev/bbe57429eba0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 23:33:47 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 26 Sep 2014 21:33:47 +0000 Subject: [issue5309] distutils doesn't parallelize extension module compilation In-Reply-To: <1235007592.93.0.0598331575131.issue5309@psf.upfronthosting.co.za> Message-ID: <1411767227.54.0.576092768394.issue5309@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This is now pushed. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 23:35:20 2014 From: report at bugs.python.org (Antony Lee) Date: Fri, 26 Sep 2014 21:35:20 +0000 Subject: [issue20267] TemporaryDirectory does not resolve path when created using a relative path In-Reply-To: <1389761308.4.0.00958902784577.issue20267@psf.upfronthosting.co.za> Message-ID: <1411767320.37.0.80121768997.issue20267@psf.upfronthosting.co.za> Antony Lee added the comment: This looks reasonable. Note that the output of gettempdir is always passed as first argument to os.path.join (possibly via _mkstemp_inner), so perhaps you should rather define something like def _absolute_child_of_parent_or_tmpdir(parent, *args): """Return the absolute child of parent, or gettempdir() if parent is None, given by *args. """ if parent is None: parent = <_sanitize_dir> # inline the code here return _os.path.join(parent, *args) and use that function instead. This factorizes the code a little bit more and makes intent clearer (I don't think _sanitize_dir is a very clear name). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 23:35:37 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 26 Sep 2014 21:35:37 +0000 Subject: [issue1764286] inspect.getsource does not work with decorated functions Message-ID: <20140926213513.82513.14899@mail.hg.python.org> Roundup Robot added the comment: New changeset ad9cc6124a19 by Yury Selivanov in branch 'default': inspect: Fix getsource() to support decorated functions. https://hg.python.org/cpython/rev/ad9cc6124a19 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 23:36:35 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 26 Sep 2014 21:36:35 +0000 Subject: [issue1764286] inspect.getsource does not work with decorated functions Message-ID: <1411767395.24.0.331171070048.issue1764286@psf.upfronthosting.co.za> Yury Selivanov added the comment: Thanks for the bug report and patch! Committed to 3.5. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 23:42:15 2014 From: report at bugs.python.org (Berker Peksag) Date: Fri, 26 Sep 2014 21:42:15 +0000 Subject: [issue21397] tempfile.py: Fix grammar in docstring, comment typos In-Reply-To: <1398854871.81.0.354739462705.issue21397@psf.upfronthosting.co.za> Message-ID: <1411767735.22.0.54947878325.issue21397@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: commit review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 23:45:24 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 26 Sep 2014 21:45:24 +0000 Subject: [issue22389] Generalize contextlib.redirect_stdout In-Reply-To: <1410445513.66.0.871890162607.issue22389@psf.upfronthosting.co.za> Message-ID: <1411767924.31.0.608656650512.issue22389@psf.upfronthosting.co.za> Yury Selivanov added the comment: @Berker Peksag: The patch looks fine, although I would rename 'redirect_stream' -> '_redirect_stream' or '_RedirectStream' ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 23:46:22 2014 From: report at bugs.python.org (Berker Peksag) Date: Fri, 26 Sep 2014 21:46:22 +0000 Subject: [issue1764286] inspect.getsource does not work with decorated functions Message-ID: <1411767982.1.0.745512233422.issue1764286@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 23:48:07 2014 From: report at bugs.python.org (Berker Peksag) Date: Fri, 26 Sep 2014 21:48:07 +0000 Subject: [issue22389] Generalize contextlib.redirect_stdout In-Reply-To: <1410445513.66.0.871890162607.issue22389@psf.upfronthosting.co.za> Message-ID: <1411768087.26.0.32799316195.issue22389@psf.upfronthosting.co.za> Berker Peksag added the comment: Good point. Will update the patch. Thanks! ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 23:48:39 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 26 Sep 2014 21:48:39 +0000 Subject: [issue22389] Generalize contextlib.redirect_stdout In-Reply-To: <1410445513.66.0.871890162607.issue22389@psf.upfronthosting.co.za> Message-ID: <1411768119.0.0.643733367278.issue22389@psf.upfronthosting.co.za> Yury Selivanov added the comment: @Berker Peksag: Also, please update the docs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 23:54:18 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 26 Sep 2014 21:54:18 +0000 Subject: [issue20267] TemporaryDirectory does not resolve path when created using a relative path In-Reply-To: <1389761308.4.0.00958902784577.issue20267@psf.upfronthosting.co.za> Message-ID: <1411768458.65.0.210867949919.issue20267@psf.upfronthosting.co.za> Yury Selivanov added the comment: Antony, I agree regarding the poor naming of '_sanitize_dir()' helper. As for your other suggestion, I think such a refactoring will actually make code harder to follow (+ it's more invasive). Generally, I'm in favour of transforming parameters like 'dir' closer to the beginning of the method's code, so that it's immediately obvious what's going on, and is also easier to put debug code [like 'print("mkdtemp call for: ", dir)']. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 23:57:24 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 26 Sep 2014 21:57:24 +0000 Subject: [issue16324] MIMEText __init__ does not support Charset instance In-Reply-To: <1351180172.93.0.972082460953.issue16324@psf.upfronthosting.co.za> Message-ID: <20140926215717.82513.78039@mail.hg.python.org> Roundup Robot added the comment: New changeset d43d4d4ebf2c by Berker Peksag in branch 'default': Issue #16324: _charset parameter of MIMEText now also accepts email.charset.Charset instances. https://hg.python.org/cpython/rev/d43d4d4ebf2c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 26 23:58:57 2014 From: report at bugs.python.org (Berker Peksag) Date: Fri, 26 Sep 2014 21:58:57 +0000 Subject: [issue16324] MIMEText __init__ does not support Charset instance In-Reply-To: <1351180172.93.0.972082460953.issue16324@psf.upfronthosting.co.za> Message-ID: <1411768737.1.0.429674604801.issue16324@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch, Claude and thanks for the review, David! ---------- assignee: -> berker.peksag resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 00:08:58 2014 From: report at bugs.python.org (Antony Lee) Date: Fri, 26 Sep 2014 22:08:58 +0000 Subject: [issue20267] TemporaryDirectory does not resolve path when created using a relative path In-Reply-To: <1389761308.4.0.00958902784577.issue20267@psf.upfronthosting.co.za> Message-ID: <1411769338.43.0.650591036798.issue20267@psf.upfronthosting.co.za> Antony Lee added the comment: I don't feel strongly about this, so either way is fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 02:28:17 2014 From: report at bugs.python.org (Martin Panter) Date: Sat, 27 Sep 2014 00:28:17 +0000 Subject: [issue22197] Allow better verbosity / output control in test cases In-Reply-To: <1408030741.18.0.985330245232.issue22197@psf.upfronthosting.co.za> Message-ID: <1411777697.42.0.723828262124.issue22197@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 10:23:26 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 27 Sep 2014 08:23:26 +0000 Subject: [issue22486] Add math.gcd() In-Reply-To: <24342987.L6z30fR5l0@raxxla> Message-ID: <1749686.ljOe70FXRz@raxxla> Serhiy Storchaka added the comment: Here is fixed patch. There was integer overflow. In C short*short is extended to int, but int*int results int. ---------- Added file: http://bugs.python.org/file36741/lehmer_gcd_7.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r e9d4288c32de Doc/library/math.rst --- a/Doc/library/math.rst Wed Sep 24 13:29:27 2014 +0300 +++ b/Doc/library/math.rst Sat Sep 27 11:09:15 2014 +0300 @@ -100,6 +100,14 @@ Number-theoretic and representation func `_\. +.. function:: gcd(a, b) + + Return the greatest common divisor of the integers *a* and *b*. If either + *a* or *b* is nonzero, then the value of ``gcd(a, b)`` is the largest + positive integer that divides both *a* and *b*. ``gcd(0, 0)`` returns + ``0``. + + .. function:: isfinite(x) Return ``True`` if *x* is neither an infinity nor a NaN, and diff -r e9d4288c32de Include/longobject.h --- a/Include/longobject.h Wed Sep 24 13:29:27 2014 +0300 +++ b/Include/longobject.h Sat Sep 27 11:09:15 2014 +0300 @@ -198,6 +198,9 @@ PyAPI_FUNC(int) _PyLong_FormatAdvancedWr PyAPI_FUNC(unsigned long) PyOS_strtoul(const char *, char **, int); PyAPI_FUNC(long) PyOS_strtol(const char *, char **, int); +/* For use by the gcd function in mathmodule.c */ +PyAPI_FUNC(PyObject *) _PyLong_GCD(PyObject *, PyObject *); + #ifdef __cplusplus } #endif diff -r e9d4288c32de Lib/fractions.py --- a/Lib/fractions.py Wed Sep 24 13:29:27 2014 +0300 +++ b/Lib/fractions.py Sat Sep 27 11:09:15 2014 +0300 @@ -174,9 +174,12 @@ class Fraction(numbers.Rational): if denominator == 0: raise ZeroDivisionError('Fraction(%s, 0)' % numerator) if _normalize: - g = gcd(numerator, denominator) + g = math.gcd(numerator, denominator) numerator //= g denominator //= g + if denominator < 0: + numerator = -numerator + denominator = -denominator self._numerator = numerator self._denominator = denominator return self diff -r e9d4288c32de Lib/test/test_math.py --- a/Lib/test/test_math.py Wed Sep 24 13:29:27 2014 +0300 +++ b/Lib/test/test_math.py Sat Sep 27 11:09:15 2014 +0300 @@ -595,6 +595,45 @@ class MathTests(unittest.TestCase): s = msum(vals) self.assertEqual(msum(vals), math.fsum(vals)) + def testGcd(self): + gcd = math.gcd + self.assertEqual(gcd(0, 0), 0) + self.assertEqual(gcd(1, 0), 1) + self.assertEqual(gcd(-1, 0), 1) + self.assertEqual(gcd(0, 1), 1) + self.assertEqual(gcd(0, -1), 1) + self.assertEqual(gcd(7, 1), 1) + self.assertEqual(gcd(7, -1), 1) + self.assertEqual(gcd(-23, 15), 1) + self.assertEqual(gcd(120, 84), 12) + self.assertEqual(gcd(84, -120), 12) + self.assertEqual(gcd(1216342683557601535506311712, + 436522681849110124616458784), 32) + c = 652560 + x = 434610456570399902378880679233098819019853229470286994367836600566 + y = 1064502245825115327754847244914921553977 + a = x * c + b = y * c + self.assertEqual(gcd(a, b), c) + self.assertEqual(gcd(b, a), c) + self.assertEqual(gcd(-a, b), c) + self.assertEqual(gcd(b, -a), c) + self.assertEqual(gcd(a, -b), c) + self.assertEqual(gcd(-b, a), c) + self.assertEqual(gcd(-a, -b), c) + self.assertEqual(gcd(-b, -a), c) + c = 576559230871654959816130551884856912003141446781646602790216406874 + a = x * c + b = y * c + self.assertEqual(gcd(a, b), c) + self.assertEqual(gcd(b, a), c) + self.assertEqual(gcd(-a, b), c) + self.assertEqual(gcd(b, -a), c) + self.assertEqual(gcd(a, -b), c) + self.assertEqual(gcd(-b, a), c) + self.assertEqual(gcd(-a, -b), c) + self.assertEqual(gcd(-b, -a), c) + def testHypot(self): self.assertRaises(TypeError, math.hypot) self.ftest('hypot(0,0)', math.hypot(0,0), 0) diff -r e9d4288c32de Modules/mathmodule.c --- a/Modules/mathmodule.c Wed Sep 24 13:29:27 2014 +0300 +++ b/Modules/mathmodule.c Sat Sep 27 11:09:15 2014 +0300 @@ -656,6 +656,22 @@ m_log10(double x) } +static PyObject * +math_gcd(PyObject *self, PyObject *args) +{ + PyObject *a, *b; + + if (!PyArg_ParseTuple(args, "O!O!:gcd", &PyLong_Type, &a, &PyLong_Type, &b)) + return NULL; + + return _PyLong_GCD(a, b); +} + +PyDoc_STRVAR(math_gcd_doc, +"gcd(x, y) -> int\n\ +greatest common divisor of x and y"); + + /* Call is_error when errno != 0, and where x is the result libm * returned. is_error will usually set up an exception and return * true (1), but may return false (0) without setting up an exception. @@ -1958,6 +1974,7 @@ static PyMethodDef math_methods[] = { {"frexp", math_frexp, METH_O, math_frexp_doc}, {"fsum", math_fsum, METH_O, math_fsum_doc}, {"gamma", math_gamma, METH_O, math_gamma_doc}, + {"gcd", math_gcd, METH_VARARGS, math_gcd_doc}, {"hypot", math_hypot, METH_VARARGS, math_hypot_doc}, {"isfinite", math_isfinite, METH_O, math_isfinite_doc}, {"isinf", math_isinf, METH_O, math_isinf_doc}, diff -r e9d4288c32de Objects/longobject.c --- a/Objects/longobject.c Wed Sep 24 13:29:27 2014 +0300 +++ b/Objects/longobject.c Sat Sep 27 11:09:15 2014 +0300 @@ -4327,6 +4327,211 @@ long_long(PyObject *v) return v; } +PyObject * +_PyLong_GCD(PyObject *aarg, PyObject *barg) +{ + PyLongObject *a, *b, *c = NULL, *d = NULL, *r; + stwodigits x, y, q, s, t, c_carry, d_carry; + stwodigits A, B, C, D, T; + int nbits, k; + Py_ssize_t size_a, size_b, alloc_a, alloc_b; + digit *a_digit, *b_digit, *c_digit, *d_digit, *a_end, *b_end; + + a = (PyLongObject *)aarg; + b = (PyLongObject *)barg; + size_a = Py_SIZE(a); + size_b = Py_SIZE(b); + if (-2 <= size_a && size_a <= 2 && -2 <= size_b && size_b <= 2) { + Py_INCREF(a); + Py_INCREF(b); + goto simple; + } + + /* Initial reduction: make sure that 0 <= b <= a. */ + a = (PyLongObject *)long_abs(a); + if (a == NULL) + return NULL; + b = (PyLongObject *)long_abs(b); + if (b == NULL) { + Py_DECREF(a); + return NULL; + } + if (long_compare(a, b) < 0) { + r = a; + a = b; + b = r; + } + /* We now own references to a and b */ + + alloc_a = Py_SIZE(a); + alloc_b = Py_SIZE(b); + /* reduce until a fits into 2 digits */ + while ((size_a = Py_SIZE(a)) > 2) { + nbits = bits_in_digit(a->ob_digit[size_a-1]); + /* extract top 2*PyLong_SHIFT bits of a into x, along with + corresponding bits of b into y */ + size_b = Py_SIZE(b); + assert(size_b <= size_a); + if (size_b == 0) { + if (size_a < alloc_a) { + r = (PyLongObject *)_PyLong_Copy(a); + Py_DECREF(a); + } + else + r = a; + Py_DECREF(b); + Py_XDECREF(c); + Py_XDECREF(d); + return (PyObject *)r; + } + x = (((twodigits)a->ob_digit[size_a-1] << (2*PyLong_SHIFT-nbits)) | + ((twodigits)a->ob_digit[size_a-2] << (PyLong_SHIFT-nbits)) | + (a->ob_digit[size_a-3] >> nbits)); + + y = ((size_b >= size_a - 2 ? b->ob_digit[size_a-3] >> nbits : 0) | + (size_b >= size_a - 1 ? (twodigits)b->ob_digit[size_a-2] << (PyLong_SHIFT-nbits) : 0) | + (size_b >= size_a ? (twodigits)b->ob_digit[size_a-1] << (2*PyLong_SHIFT-nbits) : 0)); + + /* inner loop of Lehmer's algorithm; A, B, C, D never grow + larger than PyLong_MASK during the algorithm. */ + A = 1; B = 0; C = 0; D = 1; + for (k=0;; k++) { + if (y-C == 0) + break; + q = (x+(A-1))/(y-C); + s = B+q*D; + t = x-q*y; + if (s > t) + break; + x = y; y = t; + t = A+q*C; A = D; B = C; C = s; D = t; + } + + if (k == 0) { + /* no progress; do a Euclidean step */ + if (l_divmod(a, b, NULL, &r) < 0) + goto error; + Py_DECREF(a); + a = b; + b = r; + alloc_a = alloc_b; + alloc_b = Py_SIZE(b); + continue; + } + + /* + a, b = A*b-B*a, D*a-C*b if k is odd + a, b = A*a-B*b, D*b-C*a if k is even + */ + if (k&1) { + T = -A; A = -B; B = T; + T = -C; C = -D; D = T; + } + if (c != NULL) + Py_SIZE(c) = size_a; + else if (Py_REFCNT(a) == 1) { + Py_INCREF(a); + c = a; + } + else { + alloc_a = size_a; + c = _PyLong_New(size_a); + if (c == NULL) + goto error; + } + + if (d != NULL) + Py_SIZE(d) = size_a; + else if (Py_REFCNT(b) == 1 && size_a <= alloc_b) { + Py_INCREF(b); + d = b; + Py_SIZE(d) = size_a; + } + else { + alloc_b = size_a; + d = _PyLong_New(size_a); + if (d == NULL) + goto error; + } + a_end = a->ob_digit + size_a; + b_end = b->ob_digit + size_b; + + /* compute new a and new b in parallel */ + a_digit = a->ob_digit; + b_digit = b->ob_digit; + c_digit = c->ob_digit; + d_digit = d->ob_digit; + c_carry = 0; + d_carry = 0; + while (b_digit < b_end) { + c_carry += (A * *a_digit) - (B * *b_digit); + d_carry += (D * *b_digit++) - (C * *a_digit++); + *c_digit++ = (digit)(c_carry & PyLong_MASK); + *d_digit++ = (digit)(d_carry & PyLong_MASK); + c_carry >>= PyLong_SHIFT; + d_carry >>= PyLong_SHIFT; + } + while (a_digit < a_end) { + c_carry += A * *a_digit; + d_carry -= C * *a_digit++; + *c_digit++ = (digit)(c_carry & PyLong_MASK); + *d_digit++ = (digit)(d_carry & PyLong_MASK); + c_carry >>= PyLong_SHIFT; + d_carry >>= PyLong_SHIFT; + } + assert(c_carry == 0); + assert(d_carry == 0); + + Py_INCREF(c); + Py_INCREF(d); + Py_DECREF(a); + Py_DECREF(b); + a = long_normalize(c); + b = long_normalize(d); + } + Py_XDECREF(c); + Py_XDECREF(d); + +simple: + assert(Py_REFCNT(a) > 0); + assert(Py_REFCNT(b) > 0); +#if LONG_MAX >> 2*PyLong_SHIFT + /* a fits into a long, so b must too */ + x = PyLong_AsLong((PyObject *)a); + y = PyLong_AsLong((PyObject *)b); +#elif defined(PY_LONG_LONG) && PY_LLONG_MAX >> 2*PyLong_SHIFT + x = PyLong_AsLongLong((PyObject *)a); + y = PyLong_AsLongLong((PyObject *)b); +#else +# error "_PyLong_GCD" +#endif + x = Py_ABS(x); + y = Py_ABS(y); + Py_DECREF(a); + Py_DECREF(b); + + /* usual Euclidean algorithm for longs */ + while (y != 0) { + t = y; + y = x % y; + x = t; + } +#if LONG_MAX >> 2*PyLong_SHIFT + return PyLong_FromLong(x); +#elif defined(PY_LONG_LONG) && PY_LLONG_MAX >> 2*PyLong_SHIFT + return PyLong_FromLongLong(x); +#else +# error "_PyLong_GCD" +#endif + +error: + Py_DECREF(a); + Py_DECREF(b); + Py_XDECREF(c); + Py_XDECREF(d); + return NULL; +} + static PyObject * long_float(PyObject *v) { From report at bugs.python.org Sat Sep 27 10:28:06 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 27 Sep 2014 08:28:06 +0000 Subject: [issue22486] Add math.gcd() In-Reply-To: <1749686.ljOe70FXRz@raxxla> Message-ID: <1541994.J9ylQCFyBM@raxxla> Serhiy Storchaka added the comment: And for comparison here is simpler patch with Euclidean algorithm. ---------- Added file: http://bugs.python.org/file36742/euclidean_gcd.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r e9d4288c32de Doc/library/math.rst --- a/Doc/library/math.rst Wed Sep 24 13:29:27 2014 +0300 +++ b/Doc/library/math.rst Fri Sep 26 21:37:23 2014 +0300 @@ -100,6 +100,14 @@ Number-theoretic and representation func `_\. +.. function:: gcd(a, b) + + Return the greatest common divisor of the integers *a* and *b*. If either + *a* or *b* is nonzero, then the value of ``gcd(a, b)`` is the largest + positive integer that divides both *a* and *b*. ``gcd(0, 0)`` returns + ``0``. + + .. function:: isfinite(x) Return ``True`` if *x* is neither an infinity nor a NaN, and diff -r e9d4288c32de Include/longobject.h --- a/Include/longobject.h Wed Sep 24 13:29:27 2014 +0300 +++ b/Include/longobject.h Fri Sep 26 21:37:23 2014 +0300 @@ -198,6 +198,9 @@ PyAPI_FUNC(int) _PyLong_FormatAdvancedWr PyAPI_FUNC(unsigned long) PyOS_strtoul(const char *, char **, int); PyAPI_FUNC(long) PyOS_strtol(const char *, char **, int); +/* For use by the gcd function in mathmodule.c */ +PyAPI_FUNC(PyObject *) _PyLong_GCD(PyObject *, PyObject *); + #ifdef __cplusplus } #endif diff -r e9d4288c32de Lib/fractions.py --- a/Lib/fractions.py Wed Sep 24 13:29:27 2014 +0300 +++ b/Lib/fractions.py Sat Sep 27 11:09:15 2014 +0300 @@ -174,9 +174,12 @@ class Fraction(numbers.Rational): if denominator == 0: raise ZeroDivisionError('Fraction(%s, 0)' % numerator) if _normalize: - g = gcd(numerator, denominator) + g = math.gcd(numerator, denominator) numerator //= g denominator //= g + if denominator < 0: + numerator = -numerator + denominator = -denominator self._numerator = numerator self._denominator = denominator return self diff -r e9d4288c32de Lib/test/test_math.py --- a/Lib/test/test_math.py Wed Sep 24 13:29:27 2014 +0300 +++ b/Lib/test/test_math.py Sat Sep 27 11:09:15 2014 +0300 @@ -595,6 +595,45 @@ class MathTests(unittest.TestCase): s = msum(vals) self.assertEqual(msum(vals), math.fsum(vals)) + def testGcd(self): + gcd = math.gcd + self.assertEqual(gcd(0, 0), 0) + self.assertEqual(gcd(1, 0), 1) + self.assertEqual(gcd(-1, 0), 1) + self.assertEqual(gcd(0, 1), 1) + self.assertEqual(gcd(0, -1), 1) + self.assertEqual(gcd(7, 1), 1) + self.assertEqual(gcd(7, -1), 1) + self.assertEqual(gcd(-23, 15), 1) + self.assertEqual(gcd(120, 84), 12) + self.assertEqual(gcd(84, -120), 12) + self.assertEqual(gcd(1216342683557601535506311712, + 436522681849110124616458784), 32) + c = 652560 + x = 434610456570399902378880679233098819019853229470286994367836600566 + y = 1064502245825115327754847244914921553977 + a = x * c + b = y * c + self.assertEqual(gcd(a, b), c) + self.assertEqual(gcd(b, a), c) + self.assertEqual(gcd(-a, b), c) + self.assertEqual(gcd(b, -a), c) + self.assertEqual(gcd(a, -b), c) + self.assertEqual(gcd(-b, a), c) + self.assertEqual(gcd(-a, -b), c) + self.assertEqual(gcd(-b, -a), c) + c = 576559230871654959816130551884856912003141446781646602790216406874 + a = x * c + b = y * c + self.assertEqual(gcd(a, b), c) + self.assertEqual(gcd(b, a), c) + self.assertEqual(gcd(-a, b), c) + self.assertEqual(gcd(b, -a), c) + self.assertEqual(gcd(a, -b), c) + self.assertEqual(gcd(-b, a), c) + self.assertEqual(gcd(-a, -b), c) + self.assertEqual(gcd(-b, -a), c) + def testHypot(self): self.assertRaises(TypeError, math.hypot) self.ftest('hypot(0,0)', math.hypot(0,0), 0) diff -r e9d4288c32de Modules/mathmodule.c --- a/Modules/mathmodule.c Wed Sep 24 13:29:27 2014 +0300 +++ b/Modules/mathmodule.c Fri Sep 26 21:37:23 2014 +0300 @@ -656,6 +656,22 @@ m_log10(double x) } +static PyObject * +math_gcd(PyObject *self, PyObject *args) +{ + PyObject *a, *b; + + if (!PyArg_ParseTuple(args, "O!O!:gcd", &PyLong_Type, &a, &PyLong_Type, &b)) + return NULL; + + return _PyLong_GCD(a, b); +} + +PyDoc_STRVAR(math_gcd_doc, +"gcd(x, y) -> int\n\ +greatest common divisor of x and y"); + + /* Call is_error when errno != 0, and where x is the result libm * returned. is_error will usually set up an exception and return * true (1), but may return false (0) without setting up an exception. @@ -1958,6 +1974,7 @@ static PyMethodDef math_methods[] = { {"frexp", math_frexp, METH_O, math_frexp_doc}, {"fsum", math_fsum, METH_O, math_fsum_doc}, {"gamma", math_gamma, METH_O, math_gamma_doc}, + {"gcd", math_gcd, METH_VARARGS, math_gcd_doc}, {"hypot", math_hypot, METH_VARARGS, math_hypot_doc}, {"isfinite", math_isfinite, METH_O, math_isfinite_doc}, {"isinf", math_isinf, METH_O, math_isinf_doc}, diff -r e9d4288c32de Objects/longobject.c --- a/Objects/longobject.c Wed Sep 24 13:29:27 2014 +0300 +++ b/Objects/longobject.c Fri Sep 26 21:37:23 2014 +0300 @@ -4327,6 +4327,80 @@ long_long(PyObject *v) return v; } +PyObject * +_PyLong_GCD(PyObject *a, PyObject *b) +{ + PyObject *e; + long x, y, t; + int overflow; + + x = PyLong_AsLongAndOverflow(a, &overflow); + if (x == -1 && PyErr_Occurred()) + return NULL; + if (!overflow && x >= -LONG_MAX) { + y = PyLong_AsLongAndOverflow(b, &overflow); + if (y == -1 && PyErr_Occurred()) + return NULL; + if (!overflow && y >= -LONG_MAX) { + x = Py_ABS(x); + y = Py_ABS(y); + goto fastloop; + } + } + + /* Initial reduction: make sure that 0 <= b <= a. */ + a = long_abs((PyLongObject *)a); + if (a == NULL) + return NULL; + b = long_abs((PyLongObject *)b); + if (b == NULL) { + Py_DECREF(a); + return NULL; + } + if (long_compare((PyLongObject *)a, (PyLongObject *)b) < 0) { + e = a; + a = b; + b = e; + } + /* We now own references to a and b */ + + /* reduce until a fits into longs or b == 0 */ + while (1) { + if (!Py_SIZE(b)) { + Py_DECREF(b); + return a; + } + x = PyLong_AsLongAndOverflow(a, &overflow); + assert(x != -1 || !PyErr_Occurred()); + if (!overflow) + break; + + if (l_divmod((PyLongObject *)a, (PyLongObject *)b, + NULL, (PyLongObject **)&e) < 0) { + Py_DECREF(a); + Py_DECREF(b); + return NULL; + } + Py_DECREF(a); + a = b; + b = e; + } + Py_DECREF(a); + y = PyLong_AsLongAndOverflow(b, &overflow); + Py_DECREF(b); + if (y == -1 && PyErr_Occurred()) + return NULL; + +fastloop: + /* usual Euclidean algorithm for longs */ + while (y != 0) { + t = y; + y = x % y; + x = t; + } + return PyLong_FromLong(x); +} + static PyObject * long_float(PyObject *v) { From report at bugs.python.org Sat Sep 27 10:38:34 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 27 Sep 2014 08:38:34 +0000 Subject: [issue20267] TemporaryDirectory does not resolve path when created using a relative path In-Reply-To: <1389761308.4.0.00958902784577.issue20267@psf.upfronthosting.co.za> Message-ID: <1411807114.8.0.339243809963.issue20267@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Note that abspath() can return incorrect result in case of symbolic links to directories and pardir components. I.e. abspath('symlink/..'). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 10:39:24 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 27 Sep 2014 08:39:24 +0000 Subject: [issue20267] TemporaryDirectory does not resolve path when created using a relative path In-Reply-To: <1389761308.4.0.00958902784577.issue20267@psf.upfronthosting.co.za> Message-ID: <1411807164.94.0.610723771804.issue20267@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 10:40:39 2014 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 27 Sep 2014 08:40:39 +0000 Subject: [issue22502] after continue in pdb stops in signal.py Message-ID: <1411807239.7.0.969118354208.issue22502@psf.upfronthosting.co.za> New submission from Xavier de Gaye: With the following script: import time def foo(): import pdb; pdb.set_trace() while 1: time.sleep(.5) foo() Hitting ^C after continue gives: $ ./python foo.py > foo.py(5)foo() -> while 1: (Pdb) continue ^C Program interrupted. (Use 'cont' to resume). --Call-- > Lib/signal.py(51)signal() -> @_wraps(_signal.signal) (Pdb) This is fixed with the following change: diff --git a/Lib/pdb.py b/Lib/pdb.py --- a/Lib/pdb.py +++ b/Lib/pdb.py @@ -186,9 +186,9 @@ raise KeyboardInterrupt self.message("\nProgram interrupted. (Use 'cont' to resume).") self.set_step() - self.set_trace(frame) # restore previous signal handler signal.signal(signal.SIGINT, self._previous_sigint_handler) + self.set_trace(frame) def reset(self): bdb.Bdb.reset(self) ---------- components: Library (Lib) messages: 227666 nosy: georg.brandl, xdegaye priority: normal severity: normal status: open title: after continue in pdb stops in signal.py type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 12:57:21 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 27 Sep 2014 10:57:21 +0000 Subject: [issue21883] relpath: Provide better errors when mixing bytes and strings In-Reply-To: <1404097975.91.0.971553035109.issue21883@psf.upfronthosting.co.za> Message-ID: <1411815441.1.0.0367588151481.issue21883@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka stage: -> patch review versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 14:41:37 2014 From: report at bugs.python.org (Andreas Schwab) Date: Sat, 27 Sep 2014 12:41:37 +0000 Subject: [issue22503] Signal stack overflow in faulthandler_user Message-ID: <1411821697.8.0.131937255622.issue22503@psf.upfronthosting.co.za> New submission from Andreas Schwab: test_register_chain fails on aarch64 due to signal stack overflow, when re-raising the signal in faulthandler_user. The problem is that the signal stack can only handle a single signal frame, but faulthandler_user adds a second one. _Py_Faulthandler_Init should allocate twice the amount of stack to cater for the two signal frames. ====================================================================== FAIL: test_register_chain (test.test_faulthandler.FaultHandlerTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/abuild/rpmbuild/BUILD/Python-3.4.1/Lib/test/test_faulthandler.py", line 592, in test_register_chain self.check_register(chain=True) File "/home/abuild/rpmbuild/BUILD/Python-3.4.1/Lib/test/test_faulthandler.py", line 576, in check_register self.assertEqual(exitcode, 0) AssertionError: -11 != 0 ---------------------------------------------------------------------- ---------- components: Extension Modules messages: 227667 nosy: schwab priority: normal severity: normal status: open title: Signal stack overflow in faulthandler_user type: resource usage versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 14:41:38 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 27 Sep 2014 12:41:38 +0000 Subject: [issue21883] relpath: Provide better errors when mixing bytes and strings In-Reply-To: <1404097975.91.0.971553035109.issue21883@psf.upfronthosting.co.za> Message-ID: <1411821698.57.0.918999448544.issue21883@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Error message for posixpath.join() was fixed and enhanced in issue22034. Here is a patch which extends this enhancement to relpath() and to other os.path implementations (ntpath and macpath). ---------- Added file: http://bugs.python.org/file36743/os_path_typeerrors.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 14:51:54 2014 From: report at bugs.python.org (Stefan Krah) Date: Sat, 27 Sep 2014 12:51:54 +0000 Subject: [issue15986] memoryview: expose 'buf' attribute In-Reply-To: <1406804088.12.0.41195183921.issue15986@psf.upfronthosting.co.za> Message-ID: <1411822314.86.0.471388420322.issue15986@psf.upfronthosting.co.za> Stefan Krah added the comment: Sometimes I've used memoryview slices to model pointers in C code. memoryview could have limited number methods for pointer arithmetic on the buf pointer. Arithmetic would return new slices, so in fact everything would be safe with respect to bounds checking and life-cycle management. Not completely safe of course once you pass the pointer to ctypes, but the following is less likely to happen: m = memoryview(b"123") ptr = m.buf del m my_ctypes_func(ptr) This is safer, since the view itself is the pointer: m = memoryview(b"123") my_ctypes_func(m) Of course you could still subvert the second idiom by using ptr = int(m). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 15:06:01 2014 From: report at bugs.python.org (Stefan Behnel) Date: Sat, 27 Sep 2014 13:06:01 +0000 Subject: [issue22486] Add math.gcd() In-Reply-To: <1411591235.17.0.168367966743.issue22486@psf.upfronthosting.co.za> Message-ID: <1411823161.49.0.80996013704.issue22486@psf.upfronthosting.co.za> Stefan Behnel added the comment: Patch 7 works for me. Why are the two Py_ABS() calls at the end needed when we start off the algorithm with long_abs()? The Lehmer code is complex (I guess that's why you added the pure Euclidean implementation), but it's the right algorithm to use here, so I'd say we should. It's 4% faster than the Euclidean code for the fractions benchmark when using 30 bit digits, but (surprisingly enough) about the same speed with 15 bit digits. There is no major difference to expect here as the numbers are perpetually normalised in Fractions and thus kept small (usually small enough to fit into a 64bit integer), i.e. Euclid should do quite well on them. The difference for big numbers is substantial though: Euclid: $ ./python -m timeit -s 'from math import gcd; a = 2**123 + 3**653 + 5**23 + 7**49; b = 2**653 + 2**123 + 5**23 + 11**34' 'gcd(a,b)' 10000 loops, best of 3: 71 usec per loop Lehmer: $ ./python -m timeit -s 'from math import gcd; a = 2**123 + 3**653 + 5**23 + 7**49; b = 2**653 + 2**123 + 5**23 + 11**34' 'gcd(a,b)' 100000 loops, best of 3: 11.6 usec per loop ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 15:21:51 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 27 Sep 2014 13:21:51 +0000 Subject: [issue21883] relpath: Provide better errors when mixing bytes and strings In-Reply-To: <1411821698.57.0.918999448544.issue21883@psf.upfronthosting.co.za> Message-ID: <1821758.pl1bOmKLP4@raxxla> Serhiy Storchaka added the comment: Ah, tests fail when Python runs without the -bb option. Here is fixed path. ---------- Added file: http://bugs.python.org/file36744/os_path_typeerrors_2.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r d43d4d4ebf2c Lib/genericpath.py --- a/Lib/genericpath.py Sat Sep 27 00:57:29 2014 +0300 +++ b/Lib/genericpath.py Sat Sep 27 15:52:32 2014 +0300 @@ -130,3 +130,16 @@ def _splitext(p, sep, altsep, extsep): filenameIndex += 1 return p, p[:0] + +def _check_arg_types(funcname, *args): + hasstr = hasbytes = False + for s in args: + if isinstance(s, str): + hasstr = True + elif isinstance(s, bytes): + hasbytes = True + else: + raise TypeError('%s() argument must be str or bytes, not %r' % + (funcname, s.__class__.__name__)) from None + if hasstr and hasbytes: + raise TypeError("Can't mix strings and bytes in path components") from None diff -r d43d4d4ebf2c Lib/macpath.py --- a/Lib/macpath.py Sat Sep 27 00:57:29 2014 +0300 +++ b/Lib/macpath.py Sat Sep 27 15:52:32 2014 +0300 @@ -50,20 +50,24 @@ def isabs(s): def join(s, *p): - colon = _get_colon(s) - path = s - for t in p: - if (not s) or isabs(t): - path = t - continue - if t[:1] == colon: - t = t[1:] - if colon not in path: - path = colon + path - if path[-1:] != colon: - path = path + colon - path = path + t - return path + try: + colon = _get_colon(s) + path = s + for t in p: + if (not s) or isabs(t): + path = t + continue + if t[:1] == colon: + t = t[1:] + if colon not in path: + path = colon + path + if path[-1:] != colon: + path = path + colon + path = path + t + return path + except (TypeError, AttributeError, BytesWarning): + genericpath._check_arg_types('join', s, *p) + raise def split(s): diff -r d43d4d4ebf2c Lib/ntpath.py --- a/Lib/ntpath.py Sat Sep 27 00:57:29 2014 +0300 +++ b/Lib/ntpath.py Sat Sep 27 15:52:32 2014 +0300 @@ -80,32 +80,36 @@ def join(path, *paths): sep = '\\' seps = '\\/' colon = ':' - result_drive, result_path = splitdrive(path) - for p in paths: - p_drive, p_path = splitdrive(p) - if p_path and p_path[0] in seps: - # Second path is absolute - if p_drive or not result_drive: - result_drive = p_drive - result_path = p_path - continue - elif p_drive and p_drive != result_drive: - if p_drive.lower() != result_drive.lower(): - # Different drives => ignore the first path entirely - result_drive = p_drive + try: + result_drive, result_path = splitdrive(path) + for p in paths: + p_drive, p_path = splitdrive(p) + if p_path and p_path[0] in seps: + # Second path is absolute + if p_drive or not result_drive: + result_drive = p_drive result_path = p_path continue - # Same drive in different case - result_drive = p_drive - # Second path is relative to the first - if result_path and result_path[-1] not in seps: - result_path = result_path + sep - result_path = result_path + p_path - ## add separator between UNC and non-absolute path - if (result_path and result_path[0] not in seps and - result_drive and result_drive[-1:] != colon): - return result_drive + sep + result_path - return result_drive + result_path + elif p_drive and p_drive != result_drive: + if p_drive.lower() != result_drive.lower(): + # Different drives => ignore the first path entirely + result_drive = p_drive + result_path = p_path + continue + # Same drive in different case + result_drive = p_drive + # Second path is relative to the first + if result_path and result_path[-1] not in seps: + result_path = result_path + sep + result_path = result_path + p_path + ## add separator between UNC and non-absolute path + if (result_path and result_path[0] not in seps and + result_drive and result_drive[-1:] != colon): + return result_drive + sep + result_path + return result_drive + result_path + except (TypeError, AttributeError, BytesWarning): + genericpath._check_arg_types('join', path, *paths) + raise # Split a path in a drive specification (a drive letter followed by a @@ -558,27 +562,31 @@ def relpath(path, start=None): if not path: raise ValueError("no path specified") - start_abs = abspath(normpath(start)) - path_abs = abspath(normpath(path)) - start_drive, start_rest = splitdrive(start_abs) - path_drive, path_rest = splitdrive(path_abs) - if normcase(start_drive) != normcase(path_drive): - raise ValueError("path is on mount %r, start on mount %r" % ( - path_drive, start_drive)) + try: + start_abs = abspath(normpath(start)) + path_abs = abspath(normpath(path)) + start_drive, start_rest = splitdrive(start_abs) + path_drive, path_rest = splitdrive(path_abs) + if normcase(start_drive) != normcase(path_drive): + raise ValueError("path is on mount %r, start on mount %r" % ( + path_drive, start_drive)) - start_list = [x for x in start_rest.split(sep) if x] - path_list = [x for x in path_rest.split(sep) if x] - # Work out how much of the filepath is shared by start and path. - i = 0 - for e1, e2 in zip(start_list, path_list): - if normcase(e1) != normcase(e2): - break - i += 1 + start_list = [x for x in start_rest.split(sep) if x] + path_list = [x for x in path_rest.split(sep) if x] + # Work out how much of the filepath is shared by start and path. + i = 0 + for e1, e2 in zip(start_list, path_list): + if normcase(e1) != normcase(e2): + break + i += 1 - rel_list = [pardir] * (len(start_list)-i) + path_list[i:] - if not rel_list: - return curdir - return join(*rel_list) + rel_list = [pardir] * (len(start_list)-i) + path_list[i:] + if not rel_list: + return curdir + return join(*rel_list) + except (TypeError, ValueError, AttributeError, BytesWarning): + genericpath._check_arg_types('relpath', path, start) + raise # determine if two files are in fact the same file diff -r d43d4d4ebf2c Lib/posixpath.py --- a/Lib/posixpath.py Sat Sep 27 00:57:29 2014 +0300 +++ b/Lib/posixpath.py Sat Sep 27 15:52:32 2014 +0300 @@ -82,13 +82,9 @@ def join(a, *p): path += b else: path += sep + b - except (TypeError, AttributeError): - for s in (a,) + p: - if not isinstance(s, (str, bytes)): - raise TypeError('join() argument must be str or bytes, not %r' % - s.__class__.__name__) from None - # Must have a mixture of text and binary data - raise TypeError("Can't mix strings and bytes in path components") from None + except (TypeError, AttributeError, BytesWarning): + genericpath._check_arg_types('join', a, *p) + raise return path @@ -446,13 +442,16 @@ def relpath(path, start=None): if start is None: start = curdir - start_list = [x for x in abspath(start).split(sep) if x] - path_list = [x for x in abspath(path).split(sep) if x] + try: + start_list = [x for x in abspath(start).split(sep) if x] + path_list = [x for x in abspath(path).split(sep) if x] + # Work out how much of the filepath is shared by start and path. + i = len(commonprefix([start_list, path_list])) - # Work out how much of the filepath is shared by start and path. - i = len(commonprefix([start_list, path_list])) - - rel_list = [pardir] * (len(start_list)-i) + path_list[i:] - if not rel_list: - return curdir - return join(*rel_list) + rel_list = [pardir] * (len(start_list)-i) + path_list[i:] + if not rel_list: + return curdir + return join(*rel_list) + except (TypeError, AttributeError, BytesWarning): + genericpath._check_arg_types('relpath', path, start) + raise diff -r d43d4d4ebf2c Lib/test/test_genericpath.py --- a/Lib/test/test_genericpath.py Sat Sep 27 00:57:29 2014 +0300 +++ b/Lib/test/test_genericpath.py Sat Sep 27 15:52:32 2014 +0300 @@ -434,6 +434,39 @@ class CommonTest(GenericTest): with support.temp_cwd(name): self.test_abspath() + def test_join_errors(self): + # Check join() raises friendly TypeErrors. + with support.check_warnings(('', BytesWarning), quiet=True): + errmsg = "Can't mix strings and bytes in path components" + with self.assertRaisesRegex(TypeError, errmsg): + self.pathmodule.join(b'bytes', 'str') + with self.assertRaisesRegex(TypeError, errmsg): + self.pathmodule.join('str', b'bytes') + # regression, see #15377 + errmsg = r'join\(\) argument must be str or bytes, not %r' + with self.assertRaisesRegex(TypeError, errmsg % 'int'): + self.pathmodule.join(42, 'str') + with self.assertRaisesRegex(TypeError, errmsg % 'int'): + self.pathmodule.join('str', 42) + with self.assertRaisesRegex(TypeError, errmsg % 'bytearray'): + self.pathmodule.join(bytearray(b'foo'), bytearray(b'bar')) + + def test_relpath_errors(self): + # Check relpath() raises friendly TypeErrors. + with support.check_warnings(('', BytesWarning), quiet=True): + errmsg = "Can't mix strings and bytes in path components" + with self.assertRaisesRegex(TypeError, errmsg): + self.pathmodule.relpath(b'bytes', 'str') + with self.assertRaisesRegex(TypeError, errmsg): + self.pathmodule.relpath('str', b'bytes') + errmsg = r'relpath\(\) argument must be str or bytes, not %r' + with self.assertRaisesRegex(TypeError, errmsg % 'int'): + self.pathmodule.relpath(42, 'str') + with self.assertRaisesRegex(TypeError, errmsg % 'int'): + self.pathmodule.relpath('str', 42) + with self.assertRaisesRegex(TypeError, errmsg % 'bytearray'): + self.pathmodule.relpath(bytearray(b'foo'), bytearray(b'bar')) + if __name__=="__main__": unittest.main() diff -r d43d4d4ebf2c Lib/test/test_macpath.py --- a/Lib/test/test_macpath.py Sat Sep 27 00:57:29 2014 +0300 +++ b/Lib/test/test_macpath.py Sat Sep 27 15:52:32 2014 +0300 @@ -118,6 +118,8 @@ class MacPathTestCase(unittest.TestCase) class MacCommonTest(test_genericpath.CommonTest, unittest.TestCase): pathmodule = macpath + test_relpath_errors = None + if __name__ == "__main__": unittest.main() diff -r d43d4d4ebf2c Lib/test/test_posixpath.py --- a/Lib/test/test_posixpath.py Sat Sep 27 00:57:29 2014 +0300 +++ b/Lib/test/test_posixpath.py Sat Sep 27 15:52:32 2014 +0300 @@ -57,22 +57,6 @@ class PosixPathTest(unittest.TestCase): self.assertEqual(posixpath.join(b"/foo/", b"bar/", b"baz/"), b"/foo/bar/baz/") - def test_join_errors(self): - # Check posixpath.join raises friendly TypeErrors. - errmsg = "Can't mix strings and bytes in path components" - with self.assertRaisesRegex(TypeError, errmsg): - posixpath.join(b'bytes', 'str') - with self.assertRaisesRegex(TypeError, errmsg): - posixpath.join('str', b'bytes') - # regression, see #15377 - errmsg = r'join\(\) argument must be str or bytes, not %r' - with self.assertRaisesRegex(TypeError, errmsg % 'NoneType'): - posixpath.join(None, 'str') - with self.assertRaisesRegex(TypeError, errmsg % 'NoneType'): - posixpath.join('str', None) - with self.assertRaisesRegex(TypeError, errmsg % 'bytearray'): - posixpath.join(bytearray(b'foo'), bytearray(b'bar')) - def test_split(self): self.assertEqual(posixpath.split("/foo/bar"), ("/foo", "bar")) self.assertEqual(posixpath.split("/"), ("/", "")) From report at bugs.python.org Sat Sep 27 15:39:24 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 27 Sep 2014 13:39:24 +0000 Subject: [issue22486] Add math.gcd() In-Reply-To: <1411823161.49.0.80996013704.issue22486@psf.upfronthosting.co.za> Message-ID: <1485407.hENKg6x4Dx@raxxla> Serhiy Storchaka added the comment: > Why are the two Py_ABS() calls at the end needed when we start off the > algorithm with long_abs()? Because long_abs()'s are omitted for small enough numbers (common case). So we avoid a copying for negative numbers or int subclasses. > I guess that's why you added the pure Euclidean implementation Euclidean algorithm is required step at the end of Lehmer algorithm. > It's 4% faster than the Euclidean code for the fractions benchmark > when using 30 bit digits, but (surprisingly enough) about the same speed > with 15 bit digits. May be because Lehmer code uses 64-bit computation for 30-bit digits, and Euclidean code always uses 32-bit computation. > The difference for big numbers is substantial though: 1000-bit integers are big, but can be encountered in real word (e.g. in cryptography). So may be there is need in Lehmer algorithm. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 16:03:21 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 27 Sep 2014 14:03:21 +0000 Subject: [issue9393] shelve.open/bsddb.hashopen exception with unicode paths In-Reply-To: <1280308243.23.0.510970772038.issue9393@psf.upfronthosting.co.za> Message-ID: <1411826601.21.0.426429002812.issue9393@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: dbm_open_unicode-32.patch no longer applied cleanly due to Argument Clinic. I'm not sure about applying patches to 2.7. I support this, but it looks as new feature, and you should ask on Python-Dev mailing list. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 16:06:39 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 27 Sep 2014 14:06:39 +0000 Subject: [issue19569] Use __attribute__((deprecated)) to warn usage of deprecated functions and macros In-Reply-To: <1384348276.8.0.185765824651.issue19569@psf.upfronthosting.co.za> Message-ID: <1411826799.39.0.376296547375.issue19569@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Idea looks good to me. ---------- components: +Interpreter Core nosy: +serhiy.storchaka type: -> enhancement versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 16:09:05 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 27 Sep 2014 14:09:05 +0000 Subject: [issue20021] "modernize" makeopcodetargets.py In-Reply-To: <1387426285.76.0.769422966502.issue20021@psf.upfronthosting.co.za> Message-ID: <1411826945.74.0.576925194594.issue20021@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +easy stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 16:18:29 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 27 Sep 2014 14:18:29 +0000 Subject: [issue20335] bytes constructor accepts more than one argument even if the first one is not a string In-Reply-To: <1390340737.95.0.677221459573.issue20335@psf.upfronthosting.co.za> Message-ID: <1411827509.63.0.625034392367.issue20335@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. Do you want to provide a test Renaud? ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka stage: -> test needed type: -> behavior versions: +Python 2.7, Python 3.4, Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 16:19:55 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 27 Sep 2014 14:19:55 +0000 Subject: [issue19569] Use __attribute__((deprecated)) to warn usage of deprecated functions and macros In-Reply-To: <1384348276.8.0.185765824651.issue19569@psf.upfronthosting.co.za> Message-ID: <1411827595.96.0.31773942321.issue19569@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Does the __attribute__ work for macros as well? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 16:23:28 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 27 Sep 2014 14:23:28 +0000 Subject: [issue17174] Posix os.path.join should raise TypeError when passed unusable type In-Reply-To: <1360444357.09.0.528759954869.issue17174@psf.upfronthosting.co.za> Message-ID: <1411827808.93.0.806698266056.issue17174@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Fixed in issue22034. See also issue21883. ---------- nosy: +serhiy.storchaka resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 16:28:23 2014 From: report at bugs.python.org (Ram Rachum) Date: Sat, 27 Sep 2014 14:28:23 +0000 Subject: [issue22504] Add ordering between `Enum` objects Message-ID: <1411828103.4.0.73202336425.issue22504@psf.upfronthosting.co.za> New submission from Ram Rachum: I suggest making Enum members orderable, according to their order in the enum type. Currently trying to order them raises an exception: >>> import enum >>> class Number(enum.Enum): ... one = 1 ... two = 2 ... three = 3 >>> sorted((Number.one, Number.two)) Traceback (most recent call last): File "", line 1, in sorted((Number.one, Number.two)) TypeError: unorderable types: Number() < Number() If there's agreement from core developers that this is a good feature to add, I'll write a patch. ---------- components: Library (Lib) messages: 227678 nosy: cool-RR priority: normal severity: normal status: open title: Add ordering between `Enum` objects type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 16:29:15 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 27 Sep 2014 14:29:15 +0000 Subject: [issue20164] Undocumented KeyError from os.path.expanduser In-Reply-To: <1389111327.1.0.12442170212.issue20164@psf.upfronthosting.co.za> Message-ID: <1411828155.01.0.650625459705.issue20164@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python stage: -> needs patch versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 16:32:21 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 27 Sep 2014 14:32:21 +0000 Subject: [issue15414] os.path.join behavior on Windows (ntpath.join) is unexpected and not well documented In-Reply-To: <1342903268.21.0.193498975528.issue15414@psf.upfronthosting.co.za> Message-ID: <1411828341.17.0.742302435757.issue15414@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +needs review stage: -> patch review versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 16:36:34 2014 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 27 Sep 2014 14:36:34 +0000 Subject: [issue19569] Use __attribute__((deprecated)) to warn usage of deprecated functions and macros In-Reply-To: <1384348276.8.0.185765824651.issue19569@psf.upfronthosting.co.za> Message-ID: <1411828594.53.0.37369022343.issue19569@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 16:40:46 2014 From: report at bugs.python.org (Ram Rachum) Date: Sat, 27 Sep 2014 14:40:46 +0000 Subject: [issue22505] Expose an Enum object's serial number Message-ID: <1411828846.19.0.205599343734.issue22505@psf.upfronthosting.co.za> New submission from Ram Rachum: I'd like Enum objects to expose their serial numbers. Currently it seems the only way to get this is `MyEnum._member_names_.index(my_enum.name)`, which is not cool because it's cumbersome and involves private variables. Perhaps we can use `int(my_enum) == 7`? Or `my_enum.number == 7`? I'll be happy to make a patch if there's agreement about this. ---------- components: Library (Lib) messages: 227679 nosy: cool-RR priority: normal severity: normal status: open title: Expose an Enum object's serial number type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 16:42:35 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 27 Sep 2014 14:42:35 +0000 Subject: [issue1669539] Add os.path.isrelative() and improve ntpath.isabs() Message-ID: <1411828955.15.0.425637011824.issue1669539@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- title: Improve Windows os.path.join (ntpath.join) "smart" joining -> Add os.path.isrelative() and improve ntpath.isabs() versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 16:49:48 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 27 Sep 2014 14:49:48 +0000 Subject: [issue21301] pathlib missing Path.expandvars(env=os.environ) In-Reply-To: <1397849465.53.0.177138390921.issue21301@psf.upfronthosting.co.za> Message-ID: <1411829388.7.0.836567576497.issue21301@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: expandvars() works with string, not with path, and I don't think there is a place for it in pathlib. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 16:54:01 2014 From: report at bugs.python.org (Berker Peksag) Date: Sat, 27 Sep 2014 14:54:01 +0000 Subject: [issue22505] Expose an Enum object's serial number In-Reply-To: <1411828846.19.0.205599343734.issue22505@psf.upfronthosting.co.za> Message-ID: <1411829641.58.0.568154379022.issue22505@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +barry, eli.bendersky, ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 16:57:25 2014 From: report at bugs.python.org (Ram Rachum) Date: Sat, 27 Sep 2014 14:57:25 +0000 Subject: [issue22506] `dir` on Enum subclass doesn't expose parent class attributes Message-ID: <1411829845.48.0.985714520453.issue22506@psf.upfronthosting.co.za> New submission from Ram Rachum: Calling `dir` on an enum subclass shows only the contents of that class, not its parent classes. In normal classes, you can do this: Python 3.4.0 (v3.4.0:04f714765c13, Mar 16 2014, 19:25:23) [MSC v.1600 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> class A: ... x = lambda self: 7 ... >>> class B(a): pass ... >>> assert 'x' in dir(B) But in enum subclasses, it fails: >>> import enum >>> class A(enum.Enum): ... x = lambda self: 7 ... >>> class B(A): ... pass ... >>> assert 'x' in dir(B) Traceback (most recent call last): File "", line 1, in AssertionError >>> Looks like the `__dir__` implementation needs to be tweaked. ---------- components: Library (Lib) messages: 227681 nosy: cool-RR priority: normal severity: normal status: open title: `dir` on Enum subclass doesn't expose parent class attributes type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 16:58:15 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Sat, 27 Sep 2014 14:58:15 +0000 Subject: [issue22505] Expose an Enum object's serial number In-Reply-To: <1411828846.19.0.205599343734.issue22505@psf.upfronthosting.co.za> Message-ID: <20140927105804.101eec40@anarchist.wooz.org> Barry A. Warsaw added the comment: On Sep 27, 2014, at 02:40 PM, Ram Rachum wrote: >I'd like Enum objects to expose their serial numbers. Can you please provide some motivating use cases? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 16:59:24 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Sat, 27 Sep 2014 14:59:24 +0000 Subject: [issue22504] Add ordering between `Enum` objects In-Reply-To: <1411828103.4.0.73202336425.issue22504@psf.upfronthosting.co.za> Message-ID: <20140927105913.113ef0d4@anarchist.wooz.org> Barry A. Warsaw added the comment: On Sep 27, 2014, at 02:28 PM, Ram Rachum wrote: >I suggest making Enum members orderable, according to their order in the enum >type. Can you please provide a motivating use case? ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 16:59:41 2014 From: report at bugs.python.org (Ram Rachum) Date: Sat, 27 Sep 2014 14:59:41 +0000 Subject: [issue22505] Expose an Enum object's serial number In-Reply-To: <1411828846.19.0.205599343734.issue22505@psf.upfronthosting.co.za> Message-ID: <1411829981.85.0.261386871342.issue22505@psf.upfronthosting.co.za> Ram Rachum added the comment: Right now I want it for this: http://bugs.python.org/issue22504 Another use case I can think of is that if you store enum values in a database, you're probably using an int field and you'd want to easily convert between an enum and it's int value. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 17:02:55 2014 From: report at bugs.python.org (Berker Peksag) Date: Sat, 27 Sep 2014 15:02:55 +0000 Subject: [issue18855] Inconsistent README filenames In-Reply-To: <1377616570.1.0.108273179071.issue18855@psf.upfronthosting.co.za> Message-ID: <1411830175.94.0.927356835328.issue18855@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- keywords: +easy stage: -> needs patch versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 17:31:11 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 27 Sep 2014 15:31:11 +0000 Subject: [issue22504] Add ordering between `Enum` objects In-Reply-To: <1411828103.4.0.73202336425.issue22504@psf.upfronthosting.co.za> Message-ID: <1411831871.98.0.0390454670575.issue22504@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Why don't you use IntEnum? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 17:35:36 2014 From: report at bugs.python.org (Ram Rachum) Date: Sat, 27 Sep 2014 15:35:36 +0000 Subject: [issue22504] Add ordering between `Enum` objects In-Reply-To: <1411828103.4.0.73202336425.issue22504@psf.upfronthosting.co.za> Message-ID: <1411832136.71.0.761241271922.issue22504@psf.upfronthosting.co.za> Ram Rachum added the comment: Just because I want to be able to get the `int` value of an enum object, doesn't mean I want the enum object to *be* an `int`, which is what `IntEnum` means. I don't want it to be comparable to an int, I don't want to use arithmetic on it, and most importantly I don't want it to be equal to an enum object of a different type that happens to have the same int. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 17:58:41 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 27 Sep 2014 15:58:41 +0000 Subject: [issue9850] obsolete macpath module dangerously broken and should be removed In-Reply-To: <1284441709.03.0.73507598284.issue9850@psf.upfronthosting.co.za> Message-ID: <20140927155836.81817.26722@mail.hg.python.org> Roundup Robot added the comment: New changeset 2ae2ca9d2b66 by Serhiy Storchaka in branch '2.7': Issue #9850: Fixed macpath.join() for empty first component. Patch by https://hg.python.org/cpython/rev/2ae2ca9d2b66 New changeset 54987723de99 by Serhiy Storchaka in branch '3.4': Issue #9850: Fixed macpath.join() for empty first component. Patch by https://hg.python.org/cpython/rev/54987723de99 New changeset e29866cb6b98 by Serhiy Storchaka in branch 'default': Issue #9850: Fixed macpath.join() for empty first component. Patch by https://hg.python.org/cpython/rev/e29866cb6b98 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 18:00:38 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Sat, 27 Sep 2014 16:00:38 +0000 Subject: [issue22504] Add ordering between `Enum` objects In-Reply-To: <1411832136.71.0.761241271922.issue22504@psf.upfronthosting.co.za> Message-ID: <20140927120027.7db21aa3@anarchist.wooz.org> Barry A. Warsaw added the comment: On Sep 27, 2014, at 03:35 PM, Ram Rachum wrote: >Just because I want to be able to get the `int` value of an enum object, >doesn't mean I want the enum object to *be* an `int`, which is what `IntEnum` >means. I don't want it to be comparable to an int, I don't want to use >arithmetic on it, and most importantly I don't want it to be equal to an enum >object of a different type that happens to have the same int. Okay, but that still doesn't explain the use case. Also, why wouldn't an Enum subclass, possibly using the ordered dictionary __members__ would not be sufficient. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 18:01:28 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 27 Sep 2014 16:01:28 +0000 Subject: [issue9850] obsolete macpath module dangerously broken and should be removed In-Reply-To: <1284441709.03.0.73507598284.issue9850@psf.upfronthosting.co.za> Message-ID: <1411833688.86.0.559645669295.issue9850@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Committed macpath_join_fix_with_test.patch with some additional tests. Thank you for your contribution Oleg. Needed a patch for deprecating all module or some functions. ---------- nosy: +serhiy.storchaka stage: commit review -> needs patch type: behavior -> enhancement versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 18:01:33 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 27 Sep 2014 16:01:33 +0000 Subject: [issue22503] Signal stack overflow in faulthandler_user In-Reply-To: <1411821697.8.0.131937255622.issue22503@psf.upfronthosting.co.za> Message-ID: <1411833693.43.0.551247208609.issue22503@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 18:02:47 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Sat, 27 Sep 2014 16:02:47 +0000 Subject: [issue22504] Add ordering between `Enum` objects In-Reply-To: <1411828103.4.0.73202336425.issue22504@psf.upfronthosting.co.za> Message-ID: <1411833767.05.0.114524764206.issue22504@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: https://docs.python.org/3/library/enum.html#orderedenum ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 18:07:38 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Sat, 27 Sep 2014 16:07:38 +0000 Subject: [issue22505] Expose an Enum object's serial number In-Reply-To: <1411829981.85.0.261386871342.issue22505@psf.upfronthosting.co.za> Message-ID: <20140927120730.33cf67b8@anarchist.wooz.org> Barry A. Warsaw added the comment: On Sep 27, 2014, at 02:59 PM, Ram Rachum wrote: >Right now I want it for this: > >http://bugs.python.org/issue22504 https://docs.python.org/3/library/enum.html#orderedenum >Another use case I can think of is that if you store enum values in a >database, you're probably using an int field and you'd want to easily convert >between an enum and it's int value. Why would you do that for non-int enum values? There's lots of ways you could store enum values in a database. In Mailman, I use "regular" enums (not IntEnums) but I use int values and store them in the database as INTEGERS. I could just as easily have used a string type and stored the enum member name in the database. Using subclasses and __members__ I think there's lots of other viable alternatives that don't require changing the Enum API. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 18:07:41 2014 From: report at bugs.python.org (Daniel Holth) Date: Sat, 27 Sep 2014 16:07:41 +0000 Subject: [issue22496] urllib2 fails against IIS (urllib2 can't parse 401 reply www-authenticate headers) In-Reply-To: <1411710696.24.0.271202255734.issue22496@psf.upfronthosting.co.za> Message-ID: <1411834059.3828748.172419989.3C2AFC4E@webmail.messagingengine.com> Daniel Holth added the comment: I am not the copyright holder, I only maintain the pypi package for python-ntlm. I might have 10 lines of my own code in the whole package. If running on Windows it would be great to have out of the box "native windows NTLM" which can be done somehow with the win32 module, I think... It may also be possible to use Kerberos authentication (NTLMv2) instead of NTLM in most cases these days; since after Windows 2000 according to Wikipedia. On Fri, Sep 26, 2014, at 01:51 AM, Senthil Kumaran wrote: > > Senthil Kumaran added the comment: > > Yes, urllib2 does not have any support for NTML based authentication. > And it is a long pending feature request too. > > For 2.7, the best way to handle this might be, instead of crashing on > WWW-Authenticate: Negotiate, which is a valid response from IIS (1). It > should detect it and fail with a helpful message to use a 3rdparty > handler along with urllib2 [2] > > And for 3.5, I think it is worthy to consider adding the support in > stdlib. > @Daniel Holth - I see you are the owner of it. If we choose to adopt it, > do you give permission to reuse portions of code (with correct > attribution) in the stdlib? > > 1) http://msdn.microsoft.com/en-us/library/ms995330#http-sso-2_topic1 > 2) https://code.google.com/p/python-ntlm/ > > ---------- > assignee: -> orsenthil > nosy: +dholth > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 18:08:44 2014 From: report at bugs.python.org (Ram Rachum) Date: Sat, 27 Sep 2014 16:08:44 +0000 Subject: [issue22504] Add ordering between `Enum` objects In-Reply-To: <1411828103.4.0.73202336425.issue22504@psf.upfronthosting.co.za> Message-ID: <1411834124.87.0.959975980264.issue22504@psf.upfronthosting.co.za> Ram Rachum added the comment: My particular use case is that I have objects with a tuple of enum objects to each, and I want the tuple to be in canonical order rather than random, for convenience. I can easily use a subclass, but I think it's general enough functionality for it to be included in the standard library. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 18:15:44 2014 From: report at bugs.python.org (Ram Rachum) Date: Sat, 27 Sep 2014 16:15:44 +0000 Subject: [issue22505] Expose an Enum object's serial number In-Reply-To: <1411828846.19.0.205599343734.issue22505@psf.upfronthosting.co.za> Message-ID: <1411834544.21.0.577244285448.issue22505@psf.upfronthosting.co.za> Ram Rachum added the comment: > https://docs.python.org/3/library/enum.html#orderedenum As I said in the other ticket: I can easily use a subclass, but I think it's general enough functionality for it to be included in the standard library. I could continue the discussion about databases, but it feels like a waste of time to me. The main principle is: If something has an important property (in this case an enum object's numerical value), it should be publicly exposed. Period. No need to spend hours discussing if and how that property will be used. They always end up getting used somehow-- The only question is whether the people using them need to obtain them through private variables for years until the developers finally understand that the property needs to be exposed publicly. If you want to go through that, be my guest. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 18:16:54 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 27 Sep 2014 16:16:54 +0000 Subject: [issue19569] Use __attribute__((deprecated)) to warn usage of deprecated functions and macros In-Reply-To: <1411827595.96.0.31773942321.issue19569@psf.upfronthosting.co.za> Message-ID: <8611145.PP96UXk25K@raxxla> Serhiy Storchaka added the comment: Deprecated macros can be replaced by deprecated functions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 18:25:50 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 27 Sep 2014 16:25:50 +0000 Subject: [issue11102] configure doesn't find "major()" on HP-UX v11.31 In-Reply-To: <1296677130.56.0.432506284039.issue11102@psf.upfronthosting.co.za> Message-ID: <1411835150.54.0.569298901614.issue11102@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: -r.david.murray stage: commit review -> needs patch versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 18:30:33 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 27 Sep 2014 16:30:33 +0000 Subject: [issue20140] UnicodeDecodeError in ntpath.py when home dir contains non-ascii signs In-Reply-To: <1389005031.99.0.692658963376.issue20140@psf.upfronthosting.co.za> Message-ID: <1411835433.03.0.884770202373.issue20140@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This looks to me as documentation issue. Unfortunately it is not explicitly documented that os.path.join() shouldn't mix str and unicode components (except ascii-only str, such as '.'). There is relevant note in 3.x documentation. It should be adapted to 2.7. ---------- assignee: -> docs at python components: +Documentation -Windows keywords: +easy nosy: +docs at python, serhiy.storchaka stage: -> needs patch type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 18:33:29 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 27 Sep 2014 16:33:29 +0000 Subject: [issue16121] shlex.shlex.error_leader() reports incorrect line number In-Reply-To: <1349295018.27.0.805550020258.issue16121@psf.upfronthosting.co.za> Message-ID: <1411835609.29.0.659811626477.issue16121@psf.upfronthosting.co.za> R. David Murray added the comment: I think I'll leave it up to whoever works on this whether they want to tackle making posix mode and non-posix mode return the same values or turn this into an enhancement ticket for the proposed wrapped_lineno. Or, if no one is interested, we can just close this. (Or, third option, turn it into a doc issue and document exactly what shlex actually does with lineno). ---------- stage: commit review -> needs patch versions: +Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 18:38:30 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 27 Sep 2014 16:38:30 +0000 Subject: [issue11479] Add discussion of trailing backslash in raw string to tutorial In-Reply-To: <1299985803.24.0.199507309731.issue11479@psf.upfronthosting.co.za> Message-ID: <1411835910.93.0.564871376486.issue11479@psf.upfronthosting.co.za> R. David Murray added the comment: I'm on a quest to clear my 'commit ready' queue. This issue needs to go back to 'needs patch' stage...I'll leave it to someone else to rewrite my original patch based on the feedback, since it is unlikely I will get back to it any time soon. I'll commit it if someone else does the revision and moves it back to commit review, though ;) ---------- stage: commit review -> needs patch versions: +Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 18:45:11 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 27 Sep 2014 16:45:11 +0000 Subject: [issue4755] Add function to get common path prefix In-Reply-To: <1230350435.61.0.221193783724.issue4755@psf.upfronthosting.co.za> Message-ID: <1411836311.08.0.0753748030943.issue4755@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There is more developed patch in issue10395. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 18:46:11 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Sat, 27 Sep 2014 16:46:11 +0000 Subject: [issue22505] Expose an Enum object's serial number In-Reply-To: <1411834544.21.0.577244285448.issue22505@psf.upfronthosting.co.za> Message-ID: <20140927124559.638e7473@anarchist.wooz.org> Barry A. Warsaw added the comment: On Sep 27, 2014, at 04:15 PM, Ram Rachum wrote: >The main principle is: If something has an important property (in this case >an enum object's numerical value), it should be publicly exposed. I think this is a misunderstanding. Only IntEnum members have a defined numerical value. Base Enum members have no inherent value semantics except their existence. The *syntax* of using integers for values is simply a convention and one that's not even necessary for Enums to work properly. Enum members are also defined to be unordered, so their serial number is meaningless. The fact that __members__ is an ordered dictionary is a convenient implementation detail that's only exposed in the API to support iteration over all members including aliases. Let me say specifically that I am opposed to int() for coercion for non-IntEnums because Enum values can be anything. Likewise, member.number is also a misnomer in this case: >>> from enum import Enum >>> class Colors(Enum): ... a = 'a' ... b = 'b' ... c = 'c' ... >>> Colors.a is Colors.b False >>> Colors.a is Colors.a True I think using IntEnums or a subclass to provide a convenient wrapper around __members__ iteration is the only thing that makes sense here, but I still don't think the stdlib needs to support it. IMHO, this is a case where adding to the public stdlib API would provide more complexity for little common benefit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 18:46:27 2014 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 27 Sep 2014 16:46:27 +0000 Subject: [issue20267] TemporaryDirectory does not resolve path when created using a relative path In-Reply-To: <1389761308.4.0.00958902784577.issue20267@psf.upfronthosting.co.za> Message-ID: <1411836387.39.0.674465231717.issue20267@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Note that abspath() can return incorrect result in case of symbolic links to directories and pardir components. I.e. abspath('symlink/..'). Good catch.. Should I use os.path.realpath? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 19:04:21 2014 From: report at bugs.python.org (Ram Rachum) Date: Sat, 27 Sep 2014 17:04:21 +0000 Subject: [issue22505] Expose an Enum object's serial number In-Reply-To: <1411828846.19.0.205599343734.issue22505@psf.upfronthosting.co.za> Message-ID: <1411837461.4.0.840373690018.issue22505@psf.upfronthosting.co.za> Ram Rachum added the comment: > Enum members are also defined to be unordered, so their serial number is meaningless. Are you sure? The documentation says "Enumerations support iteration, in definition order" and shows how `tuple(MyEnum)` outputs the values in definition order. > Likewise, member.number is also a misnomer in this case: I don't understand why it's a misnomer in the case you showed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 19:50:57 2014 From: report at bugs.python.org (Berker Peksag) Date: Sat, 27 Sep 2014 17:50:57 +0000 Subject: [issue20021] "modernize" makeopcodetargets.py In-Reply-To: <1387426285.76.0.769422966502.issue20021@psf.upfronthosting.co.za> Message-ID: <1411840257.03.0.638913567489.issue20021@psf.upfronthosting.co.za> Berker Peksag added the comment: Here's a patch. ---------- keywords: +patch nosy: +berker.peksag, brett.cannon stage: needs patch -> patch review Added file: http://bugs.python.org/file36745/issue20021.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 20:10:30 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 27 Sep 2014 18:10:30 +0000 Subject: [issue19062] Idle: problem confighandler getting userdir In-Reply-To: <1379777943.19.0.474410652516.issue19062@psf.upfronthosting.co.za> Message-ID: <1411841430.17.0.404129328659.issue19062@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I suppose that on patrick's computeron his account (but not on admin account) HOME is literal "%userprofile%". It looks as just misconfiguration. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 20:15:37 2014 From: report at bugs.python.org (Francis MB) Date: Sat, 27 Sep 2014 18:15:37 +0000 Subject: [issue6623] Lib/ftplib.py Netrc class should be removed. In-Reply-To: <1249165781.68.0.418938928921.issue6623@psf.upfronthosting.co.za> Message-ID: <1411841737.57.0.93130187089.issue6623@psf.upfronthosting.co.za> Francis MB added the comment: I've downloaded 'remove_Netrc_class2.patch' and passes the test suite, the examples on the documentation run ok and manually from the command line: $hg tip changeset: 92597:e29866cb6b98 tag: tip parent: 92594:d43d4d4ebf2c parent: 92596:54987723de99 ... $ hg status M Lib/ftplib.py M Lib/test/test_ftplib.py ? Modules/_testembed $ ./python -m ftplib -d ftp.debian.org -ddebian *cmd* 'USER anonymous' *resp* '331 Please specify the password.' *cmd* 'PASS *********' *resp* '230 Login successful.' *cmd* 'CWD debian' *resp* '250 Directory successfully changed.' *cmd* 'QUIT' *resp* '221 Goodbye.' My test '.netrc' file was: $ cat ~/.netrc machine ftp.debian.org login anonymous password anonymous The patch also looks good for me. ---------- nosy: +francismb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 20:20:16 2014 From: report at bugs.python.org (Berker Peksag) Date: Sat, 27 Sep 2014 18:20:16 +0000 Subject: [issue6623] Lib/ftplib.py Netrc class should be removed. In-Reply-To: <1249165781.68.0.418938928921.issue6623@psf.upfronthosting.co.za> Message-ID: <1411842016.92.0.40085219979.issue6623@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 20:23:51 2014 From: report at bugs.python.org (Maries Ionel Cristian) Date: Sat, 27 Sep 2014 18:23:51 +0000 Subject: [issue22507] PyType_IsSubtype doesn't call __subclasscheck__ Message-ID: <1411842231.97.0.146200630679.issue22507@psf.upfronthosting.co.za> New submission from Maries Ionel Cristian: It appears it just does a reference check: https://hg.python.org/cpython/file/3.4/Objects/typeobject.c#l1300 It appears it's the same in 2.7: https://hg.python.org/cpython/file/2.7/Objects/typeobject.c#l1161 But this is not the intended behaviour right? ---------- components: Interpreter Core messages: 227706 nosy: ionel.mc priority: normal severity: normal status: open title: PyType_IsSubtype doesn't call __subclasscheck__ versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 20:28:06 2014 From: report at bugs.python.org (Skip Montanaro) Date: Sat, 27 Sep 2014 18:28:06 +0000 Subject: [issue4755] Add function to get common path prefix In-Reply-To: <1230350435.61.0.221193783724.issue4755@psf.upfronthosting.co.za> Message-ID: <1411842486.96.0.281545582569.issue4755@psf.upfronthosting.co.za> Skip Montanaro added the comment: Feel free to close this ticket. I long ago gave up on it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 20:28:14 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 27 Sep 2014 18:28:14 +0000 Subject: [issue6623] Lib/ftplib.py Netrc class should be removed. In-Reply-To: <1249165781.68.0.418938928921.issue6623@psf.upfronthosting.co.za> Message-ID: <1411842494.53.0.253023450668.issue6623@psf.upfronthosting.co.za> R. David Murray added the comment: Great. The patch looks good to me, too. Can someone add a What's New removal entry to the patch? (See the 3.4 What's New for a model of what removals look like in What's New.) (It would also be nice if the patch were in hg format so that we get a 'review' link, but that's not critical as I don't think we need a line-by-line review here). ---------- stage: patch review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 20:32:09 2014 From: report at bugs.python.org (Stefan Behnel) Date: Sat, 27 Sep 2014 18:32:09 +0000 Subject: [issue22501] Optimise PyLong division by 1 or -1 In-Reply-To: <1411717951.94.0.775815371352.issue22501@psf.upfronthosting.co.za> Message-ID: <1411842729.0.0.358943590166.issue22501@psf.upfronthosting.co.za> Stefan Behnel added the comment: One more comment: I also benchmarked the change in long_true_div() now and found that it's only a minor improvement for large numbers and a *pessimisation* for small numbers: Before: $ ./python -m timeit -s 'x = 5' 'x / -1' 10000000 loops, best of 3: 0.0313 usec per loop $ ./python -m timeit -s 'x = 5' 'x / 1' 10000000 loops, best of 3: 0.0307 usec per loop $ ./python -m timeit -s 'x = 2**200 + 3**234 + 5**89 + 7**123' 'x / 1' 10000000 loops, best of 3: 0.101 usec per loop $ ./python -m timeit -s 'x = 2**200 + 3**234 + 5**89 + 7**123' 'x / -1' 10000000 loops, best of 3: 0.104 usec per loop Patched: $ ./python -m timeit -s 'x = 5' 'x / 1' 10000000 loops, best of 3: 0.0569 usec per loop $ ./python -m timeit -s 'x = 5' 'x / -1' 10000000 loops, best of 3: 0.0576 usec per loop $ ./python -m timeit -s 'x = 2**200 + 3**234 + 5**89 + 7**123' 'x / -1' 10000000 loops, best of 3: 0.056 usec per loop $ ./python -m timeit -s 'x = 2**200 + 3**234 + 5**89 + 7**123' 'x / 1' 10000000 loops, best of 3: 0.056 usec per loop $ ./python -m timeit -s 'x = 2**200 + 3**234 + 5**89 + 7**123' 'x / -2' 10000000 loops, best of 3: 0.106 usec per loop So, just for completeness, here's the patch without that part, with changes only in l_divmod() and long_mul(), with the timeit results as given in my previous comment. ---------- Added file: http://bugs.python.org/file36746/mul_div_by_1_fast_path_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 20:37:26 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 27 Sep 2014 18:37:26 +0000 Subject: [issue9104] test.support method for dual-testing accelerated code (fixes test_exceptions and other's pickle testing) In-Reply-To: <1277741892.3.0.0849773844587.issue9104@psf.upfronthosting.co.za> Message-ID: <1411843046.89.0.0716675190708.issue9104@psf.upfronthosting.co.za> R. David Murray added the comment: Looks like there is still some disagreement about the implementation here, so this isn't actually ready to commit yet? ---------- resolution: accepted -> stage: commit review -> needs patch title: test_exceptions does not test pickling with pickle.py -> test.support method for dual-testing accelerated code (fixes test_exceptions and other's pickle testing) versions: +Python 3.5 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 20:42:25 2014 From: report at bugs.python.org (Stefan Behnel) Date: Sat, 27 Sep 2014 18:42:25 +0000 Subject: [issue22486] Add math.gcd() In-Reply-To: <1411591235.17.0.168367966743.issue22486@psf.upfronthosting.co.za> Message-ID: <1411843345.7.0.96166186723.issue22486@psf.upfronthosting.co.za> Stefan Behnel added the comment: My personal take is: if there is an implementation in the stdlib, it should be the one that's most widely applicable. And that includes large numbers. We have a working implementation that is algorithmically faster for large numbers, so I can't see why we should drop it unused. I'm for merging patch 7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 20:43:33 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 27 Sep 2014 18:43:33 +0000 Subject: [issue7665] test_urllib2 and test_ntpath fail if path contains "\" In-Reply-To: <1263142226.0.0.91918347375.issue7665@psf.upfronthosting.co.za> Message-ID: <1411843413.11.0.388641903919.issue7665@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The ntpath test failure is replicated when the test is ran directly: ~/py/cpython\1$ ./python Lib/test/test_ntpath.py ........................s........E..... ====================================================================== ERROR: test_relpath (__main__.TestNtpath) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_ntpath.py", line 314, in test_relpath tester('ntpath.relpath("a", "../b")', '..\\'+currentdir+'\\a') File "Lib/test/test_ntpath.py", line 16, in tester %(str(fn), str(wantResult), str(gotResult))) test.support.TestFailed: ntpath.relpath("a", "../b") should return: ..\cpython\1\a but returned: ..\1\a ---------------------------------------------------------------------- Here is a patch with a fix of test_ntpath and with simpler fix of test_urllib2. ---------- nosy: +serhiy.storchaka versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 21:03:12 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 27 Sep 2014 19:03:12 +0000 Subject: [issue20974] email module docs say not compatible with current python version In-Reply-To: <1395176910.11.0.458502603486.issue20974@psf.upfronthosting.co.za> Message-ID: <20140927190310.82106.32354@mail.hg.python.org> Roundup Robot added the comment: New changeset 2eea52c287b7 by R David Murray in branch '3.4': #20974: Update version table in email intro. https://hg.python.org/cpython/rev/2eea52c287b7 New changeset 655b34cd8871 by R David Murray in branch 'default': Merge: #20974: Update version table in email intro. https://hg.python.org/cpython/rev/655b34cd8871 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 21:07:24 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 27 Sep 2014 19:07:24 +0000 Subject: [issue20974] email module docs say not compatible with current python version In-Reply-To: <1395176910.11.0.458502603486.issue20974@psf.upfronthosting.co.za> Message-ID: <1411844844.41.0.517083634097.issue20974@psf.upfronthosting.co.za> R. David Murray added the comment: I've updated the table (thanks for the patch) but noted that after 5.1/3.2 there is no independent email version. I'd like to just delete __version__ in 3.5, but I don't know if I have to deprecate the constant first :) It didn't get updated in 3.3 or 3.4, so it isn't *accurate* in any case. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 21:38:46 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 27 Sep 2014 19:38:46 +0000 Subject: [issue18854] is_multipart and walk should document their treatment of 'message' parts. In-Reply-To: <1377612312.75.0.466824716408.issue18854@psf.upfronthosting.co.za> Message-ID: <20140927193840.81965.347@mail.hg.python.org> Roundup Robot added the comment: New changeset b717128799b5 by R David Murray in branch '3.4': #18854: make it explicit that is_multipart does not mean 'multipart/xxx'. https://hg.python.org/cpython/rev/b717128799b5 New changeset 9909de463dc9 by R David Murray in branch 'default': Merge: #18854: make it explicit that is_multipart does not mean 'multipart/xxx'. https://hg.python.org/cpython/rev/9909de463dc9 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 21:39:55 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 27 Sep 2014 19:39:55 +0000 Subject: [issue18854] is_multipart and walk should document their treatment of 'message' parts. In-Reply-To: <1377612312.75.0.466824716408.issue18854@psf.upfronthosting.co.za> Message-ID: <1411846795.95.0.21171945308.issue18854@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks Abhilash. I decided to use the full example after all, but tuned up the language a bit. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed type: -> behavior versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 21:49:39 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 27 Sep 2014 19:49:39 +0000 Subject: =?utf-8?q?=5Bissue16537=5D_Python=E2=80=99s_setup=2Epy_raises_a_ValueErro?= =?utf-8?q?r_when_self=2Eextensions_is_empty?= In-Reply-To: <1353633257.31.0.391670680901.issue16537@psf.upfronthosting.co.za> Message-ID: <20140927194937.81965.43473@mail.hg.python.org> Roundup Robot added the comment: New changeset a169ee4f254a by Berker Peksag in branch '3.4': Issue #16537: Check whether self.extensions is empty in setup.py. https://hg.python.org/cpython/rev/a169ee4f254a New changeset 491a4d3e2bdd by Berker Peksag in branch 'default': Issue #16537: Check whether self.extensions is empty in setup.py. https://hg.python.org/cpython/rev/491a4d3e2bdd ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 21:54:59 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 27 Sep 2014 19:54:59 +0000 Subject: =?utf-8?q?=5Bissue16537=5D_Python=E2=80=99s_setup=2Epy_raises_a_ValueErro?= =?utf-8?q?r_when_self=2Eextensions_is_empty?= In-Reply-To: <1353633257.31.0.391670680901.issue16537@psf.upfronthosting.co.za> Message-ID: <20140927195456.53368.63012@mail.hg.python.org> Roundup Robot added the comment: New changeset 6946036f21ef by Berker Peksag in branch '2.7': Issue #16537: Check whether self.extensions is empty in setup.py. https://hg.python.org/cpython/rev/6946036f21ef ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 21:55:49 2014 From: report at bugs.python.org (Berker Peksag) Date: Sat, 27 Sep 2014 19:55:49 +0000 Subject: =?utf-8?q?=5Bissue16537=5D_Python=E2=80=99s_setup=2Epy_raises_a_ValueErro?= =?utf-8?q?r_when_self=2Eextensions_is_empty?= In-Reply-To: <1353633257.31.0.391670680901.issue16537@psf.upfronthosting.co.za> Message-ID: <1411847749.97.0.189626710136.issue16537@psf.upfronthosting.co.za> Berker Peksag added the comment: Committed. Thanks for the patch, Jonathan! ---------- assignee: -> berker.peksag nosy: +berker.peksag resolution: -> fixed stage: commit review -> resolved status: open -> closed versions: +Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 22:09:20 2014 From: report at bugs.python.org (Berker Peksag) Date: Sat, 27 Sep 2014 20:09:20 +0000 Subject: [issue10702] bytes and bytearray methods are not documented In-Reply-To: <1292347564.88.0.542769666771.issue10702@psf.upfronthosting.co.za> Message-ID: <1411848560.13.0.0759501657962.issue10702@psf.upfronthosting.co.za> Berker Peksag added the comment: Fixed in issue 21777. ---------- nosy: +berker.peksag resolution: -> out of date stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 22:10:04 2014 From: report at bugs.python.org (Berker Peksag) Date: Sat, 27 Sep 2014 20:10:04 +0000 Subject: [issue16252] bytes and bytearray methods are undocumented In-Reply-To: <1350414656.76.0.593225775655.issue16252@psf.upfronthosting.co.za> Message-ID: <1411848604.87.0.799061495617.issue16252@psf.upfronthosting.co.za> Berker Peksag added the comment: Fixed in issue 21777. ---------- nosy: +berker.peksag resolution: -> out of date stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 22:19:10 2014 From: report at bugs.python.org (Cybjit) Date: Sat, 27 Sep 2014 20:19:10 +0000 Subject: [issue22103] bdist_wininst does not run install script In-Reply-To: <1406670252.28.0.0982043111898.issue22103@psf.upfronthosting.co.za> Message-ID: <1411849150.32.0.779366376624.issue22103@psf.upfronthosting.co.za> Cybjit added the comment: Probably caused by issue #21354 ---------- nosy: +Cybjit _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 22:22:29 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 27 Sep 2014 20:22:29 +0000 Subject: [issue22251] Various markup errors in documentation In-Reply-To: <1408723193.3.0.461529652893.issue22251@psf.upfronthosting.co.za> Message-ID: <20140927202227.38203.1135@mail.hg.python.org> Roundup Robot added the comment: New changeset 0ec56e677bc3 by Berker Peksag in branch '3.4': Issue #22251: Fix ReST markup to avoid errors building docs. https://hg.python.org/cpython/rev/0ec56e677bc3 New changeset ed1dbac90b92 by Berker Peksag in branch 'default': Issue #22251: Fix ReST markup to avoid errors building docs. https://hg.python.org/cpython/rev/ed1dbac90b92 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 22:23:04 2014 From: report at bugs.python.org (Berker Peksag) Date: Sat, 27 Sep 2014 20:23:04 +0000 Subject: [issue22251] Various markup errors in documentation In-Reply-To: <1408723193.3.0.461529652893.issue22251@psf.upfronthosting.co.za> Message-ID: <1411849384.95.0.549801301856.issue22251@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 22:24:22 2014 From: report at bugs.python.org (Berker Peksag) Date: Sat, 27 Sep 2014 20:24:22 +0000 Subject: [issue22251] Various markup errors in documentation In-Reply-To: <1408723193.3.0.461529652893.issue22251@psf.upfronthosting.co.za> Message-ID: <1411849462.89.0.854845190947.issue22251@psf.upfronthosting.co.za> Berker Peksag added the comment: See issue 16805 for a similar issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 22:24:59 2014 From: report at bugs.python.org (Georg Brandl) Date: Sat, 27 Sep 2014 20:24:59 +0000 Subject: [issue22251] Various markup errors in documentation In-Reply-To: <1408723193.3.0.461529652893.issue22251@psf.upfronthosting.co.za> Message-ID: <1411849499.81.0.214017191825.issue22251@psf.upfronthosting.co.za> Georg Brandl added the comment: These "errors" are all valid markup. They would have been discovered much earlier had they been errors. Please consider checking why your Sphinx setup produces the errors, fixing it and then reverting the changes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 22:42:40 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 27 Sep 2014 20:42:40 +0000 Subject: [issue22251] Various markup errors in documentation In-Reply-To: <1408723193.3.0.461529652893.issue22251@psf.upfronthosting.co.za> Message-ID: <1411850560.31.0.457231011426.issue22251@psf.upfronthosting.co.za> R. David Murray added the comment: I suppose this is one disadvantage of using the system sphinx when 'make html' is run? ---------- nosy: +r.david.murray status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 22:43:12 2014 From: report at bugs.python.org (Ethan Furman) Date: Sat, 27 Sep 2014 20:43:12 +0000 Subject: [issue22504] Add ordering between `Enum` objects In-Reply-To: <1411828103.4.0.73202336425.issue22504@psf.upfronthosting.co.za> Message-ID: <1411850592.22.0.207655187918.issue22504@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 22:44:48 2014 From: report at bugs.python.org (Ethan Furman) Date: Sat, 27 Sep 2014 20:44:48 +0000 Subject: [issue22506] `dir` on Enum subclass doesn't expose parent class attributes In-Reply-To: <1411829845.48.0.985714520453.issue22506@psf.upfronthosting.co.za> Message-ID: <1411850688.8.0.895887972286.issue22506@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 22:51:07 2014 From: report at bugs.python.org (eryksun) Date: Sat, 27 Sep 2014 20:51:07 +0000 Subject: [issue19569] Use __attribute__((deprecated)) to warn usage of deprecated functions and macros In-Reply-To: <1384348276.8.0.185765824651.issue19569@psf.upfronthosting.co.za> Message-ID: <1411851067.27.0.839227058424.issue19569@psf.upfronthosting.co.za> eryksun added the comment: MSC has __declspec(deprecated). See http://stackoverflow.com/a/21265197, for example. It's a level 3 (/W3) warning. http://msdn.microsoft.com/en-us/library/ttcz0bys%28v=vs.100%29.aspx ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 22:59:21 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 27 Sep 2014 20:59:21 +0000 Subject: [issue10510] distutils upload/register should use CRLF in HTTP requests In-Reply-To: <1290489114.33.0.672814735109.issue10510@psf.upfronthosting.co.za> Message-ID: <20140927205918.37446.66358@mail.hg.python.org> Roundup Robot added the comment: New changeset 5e3f8bd33cf2 by R David Murray in branch '3.4': #10510: make distuitls upload/register use HTML standards compliant CRLF. https://hg.python.org/cpython/rev/5e3f8bd33cf2 New changeset ea665bae2ea0 by R David Murray in branch 'default': Merge: #10510: make distuitls upload/register use HTML standards compliant CRLF. https://hg.python.org/cpython/rev/ea665bae2ea0 New changeset 9ad78b4b169c by R David Murray in branch '2.7': #10510: make distuitls upload/register use HTML standards compliant CRLF. https://hg.python.org/cpython/rev/9ad78b4b169c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 22:59:57 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 27 Sep 2014 20:59:57 +0000 Subject: [issue10510] distutils upload/register should use CRLF in HTTP requests In-Reply-To: <1290489114.33.0.672814735109.issue10510@psf.upfronthosting.co.za> Message-ID: <1411851597.5.0.2976955565.issue10510@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 23:01:45 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 27 Sep 2014 21:01:45 +0000 Subject: [issue22251] Various markup errors in documentation In-Reply-To: <1408723193.3.0.461529652893.issue22251@psf.upfronthosting.co.za> Message-ID: <20140927210141.73863.61646@mail.hg.python.org> Roundup Robot added the comment: New changeset 0b84904c9471 by Berker Peksag in branch '3.4': Revert #22251 https://hg.python.org/cpython/rev/0b84904c9471 New changeset 78ae78f967f1 by Berker Peksag in branch 'default': Revert #22251 https://hg.python.org/cpython/rev/78ae78f967f1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 23:03:09 2014 From: report at bugs.python.org (Berker Peksag) Date: Sat, 27 Sep 2014 21:03:09 +0000 Subject: [issue22251] Various markup errors in documentation In-Reply-To: <1408723193.3.0.461529652893.issue22251@psf.upfronthosting.co.za> Message-ID: <1411851789.79.0.432319628552.issue22251@psf.upfronthosting.co.za> Berker Peksag added the comment: I was using Sphinx 1.2.2 and found two related issues: issue 16805 and issue 20961. I've just upgraded Sphinx to 1.2.3, did a clean checkout, reverted the changes and everything looks good. Sorry for the noise! ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 23:05:22 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 27 Sep 2014 21:05:22 +0000 Subject: [issue22508] Remove __version__ string from email Message-ID: <1411851922.47.0.151418243457.issue22508@psf.upfronthosting.co.za> New submission from R. David Murray: There is no longer a concept of a separate 'email' release from the stdlib release. The __version__ string didn't get updated in either 3.3 or 3.4 (my fault). I propose that we simply delete the __version__ variable from __init__.py (patch attached). Any objections? ---------- components: email files: remove_email_version.patch keywords: patch messages: 227731 nosy: barry, r.david.murray priority: normal severity: normal status: open title: Remove __version__ string from email versions: Python 3.5 Added file: http://bugs.python.org/file36747/remove_email_version.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 23:05:51 2014 From: report at bugs.python.org (Claudiu Popa) Date: Sat, 27 Sep 2014 21:05:51 +0000 Subject: [issue16837] Number ABC can be instantiated In-Reply-To: <1357082763.61.0.378054227113.issue16837@psf.upfronthosting.co.za> Message-ID: <1411851951.59.0.231890636509.issue16837@psf.upfronthosting.co.za> Changes by Claudiu Popa : ---------- components: +Library (Lib) versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 23:09:49 2014 From: report at bugs.python.org (Claudiu Popa) Date: Sat, 27 Sep 2014 21:09:49 +0000 Subject: [issue16837] Number ABC can be instantiated In-Reply-To: <1357082763.61.0.378054227113.issue16837@psf.upfronthosting.co.za> Message-ID: <1411852189.9.0.391751445606.issue16837@psf.upfronthosting.co.za> Claudiu Popa added the comment: I'd say that this should be fixed, it breaks the expectancy imposed by the documentation, so +1 from me. ---------- nosy: +Claudiu.Popa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 23:10:29 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Sat, 27 Sep 2014 21:10:29 +0000 Subject: [issue22508] Remove __version__ string from email In-Reply-To: <1411851922.47.0.151418243457.issue22508@psf.upfronthosting.co.za> Message-ID: <20140927171018.1db958a8@anarchist.wooz.org> Barry A. Warsaw added the comment: On Sep 27, 2014, at 09:05 PM, R. David Murray wrote: >There is no longer a concept of a separate 'email' release from the stdlib >release. The __version__ string didn't get updated in either 3.3 or 3.4 (my >fault). I propose that we simply delete the __version__ variable from >__init__.py (patch attached). +1 -Barry ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 23:18:11 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 27 Sep 2014 21:18:11 +0000 Subject: [issue17849] Missing size argument in readline() method for httplib's class LineAndFileWrapper In-Reply-To: <1366979224.14.0.876475494511.issue17849@psf.upfronthosting.co.za> Message-ID: <1411852691.66.0.525920060294.issue17849@psf.upfronthosting.co.za> R. David Murray added the comment: I tried the patch, but the test fails for me: test test_httplib failed -- Traceback (most recent call last): File "/home/rdmurray/python/p27/Lib/test/test_httplib.py", line 434, in test_proxy_tunnel_without_status_line conn.set_tunnel('foo') File "/home/rdmurray/python/p27/Lib/httplib.py", line 734, in set_tunnel raise RuntimeError("Can't setup tunnel for established connection.") RuntimeError: Can't setup tunnel for established connection. ---------- stage: commit review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 23:29:52 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 27 Sep 2014 21:29:52 +0000 Subject: [issue21578] Misleading error message when ImportError called with invalid keyword args In-Reply-To: <1401078695.26.0.813929580296.issue21578@psf.upfronthosting.co.za> Message-ID: <1411853392.47.0.0834798995384.issue21578@psf.upfronthosting.co.za> R. David Murray added the comment: The standard error message for this case is: xxx() got an unexpected keyword argument 'foo' I have no idea where that gets generated (a grep didn't teach me anything useful), but I think it would make sense to use that form for the message. I think the fix can be applied to 3.4. ---------- stage: commit review -> needs patch type: enhancement -> behavior versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 23:43:25 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 27 Sep 2014 21:43:25 +0000 Subject: [issue10766] optparse uses %s in gettext calls In-Reply-To: <1293148753.14.0.11198082887.issue10766@psf.upfronthosting.co.za> Message-ID: <1411854205.68.0.580926462634.issue10766@psf.upfronthosting.co.za> R. David Murray added the comment: OK, since there seems to be some concern about backward compatibility (in the related argparse issue) and optparse is indeed no longer maintained, let's close this. ---------- resolution: -> rejected stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 23:47:30 2014 From: report at bugs.python.org (Ethan Furman) Date: Sat, 27 Sep 2014 21:47:30 +0000 Subject: [issue22504] Add ordering between `Enum` objects In-Reply-To: <1411828103.4.0.73202336425.issue22504@psf.upfronthosting.co.za> Message-ID: <1411854450.42.0.929825043825.issue22504@psf.upfronthosting.co.za> Ethan Furman added the comment: Enums have a definition order to aid in the use-case of auto-numbering, and to make displays consistent. However, the basic Enum type is unordered. If you need/want your particular enum type to be ordered, mix-in the ordered magic methods. ---------- assignee: -> ethan.furman resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 23:48:50 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 27 Sep 2014 21:48:50 +0000 Subject: [issue21044] tarfile does not handle file .name being an int In-Reply-To: <1395624777.51.0.277506799413.issue21044@psf.upfronthosting.co.za> Message-ID: <1411854530.39.0.501028770753.issue21044@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: commit review -> test needed versions: +Python 2.7 -Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 23:55:00 2014 From: report at bugs.python.org (Ethan Furman) Date: Sat, 27 Sep 2014 21:55:00 +0000 Subject: [issue22505] Expose an Enum object's serial number In-Reply-To: <1411828846.19.0.205599343734.issue22505@psf.upfronthosting.co.za> Message-ID: <1411854900.46.0.730153652563.issue22505@psf.upfronthosting.co.za> Ethan Furman added the comment: Yes, we're sure. ;) Enums have a definition order to aid in the use-case of auto-numbering, and to make displays consistent. However, the basic Enum type is unordered. I do not see a serial number as being an intrinsic property of an enum -- outside of auto-numbering (also not available in the stdlib), what difference does it make what order it was defined in? What matters is the name and the value. If you want your enum to have a serial number you can easily add that functionality in. ---------- assignee: -> ethan.furman resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 23:55:23 2014 From: report at bugs.python.org (Ethan Furman) Date: Sat, 27 Sep 2014 21:55:23 +0000 Subject: [issue22506] `dir` on Enum subclass doesn't expose parent class attributes In-Reply-To: <1411829845.48.0.985714520453.issue22506@psf.upfronthosting.co.za> Message-ID: <1411854923.59.0.43738443467.issue22506@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 27 23:58:18 2014 From: report at bugs.python.org (Ram Rachum) Date: Sat, 27 Sep 2014 21:58:18 +0000 Subject: [issue22506] `dir` on Enum subclass doesn't expose parent class attributes In-Reply-To: <1411829845.48.0.985714520453.issue22506@psf.upfronthosting.co.za> Message-ID: <1411855098.05.0.206570868159.issue22506@psf.upfronthosting.co.za> Ram Rachum added the comment: Ethan, I saw you just marked this as "test needed". I just gave you code to reproduce this problem. Isn't that sufficient? Or you want me to do add it to Python's test suite? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 00:05:15 2014 From: report at bugs.python.org (Henning von Bargen) Date: Sat, 27 Sep 2014 22:05:15 +0000 Subject: [issue22139] python windows 2.7.8 64-bit did not install In-Reply-To: <1407238374.16.0.107772681213.issue22139@psf.upfronthosting.co.za> Message-ID: <1411855515.9.0.330843283568.issue22139@psf.upfronthosting.co.za> Henning von Bargen added the comment: Martin, while I technically understand your anwers, I have to say that from an ordinary developer's perspective, the behavior is actually *not* expected. It may be expected for python-dev experts, but not for those who are just programming _with_ python. It did cost me half a day to find out what's going on. Luckily, this happened on an internal development machine and not while installing the application on one of our customer's machine. IIRC earlier versions of python did not install a python2*.* ZIP or DLL into %WINDIR%\System32. It should at least be documented that installing two different 2.7.x releases on the same machine is not supported. Furthermore, the technical difference between "install for all users" and "install just for me" is not clear. As you said, the docs do not even mention that after an installation "for all users" the system uses %WINDIR%\System32\python2x.zip for searching libraries. For a developer it is not obvious that hmac is built in while other standard libs (implemented in pure Python) are not. BTW, if it was built-in (technically), then it could not be not found, as it happened to Andreas and me. Fool-proof built-in would mean: statically linked with the executable, not in a DLL. I recommend to keep things as is, but add a few sentences to the docs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 00:13:03 2014 From: report at bugs.python.org (Ned Deily) Date: Sat, 27 Sep 2014 22:13:03 +0000 Subject: [issue22103] bdist_wininst does not run install script In-Reply-To: <1406670252.28.0.0982043111898.issue22103@psf.upfronthosting.co.za> Message-ID: <1411855983.41.0.364196889343.issue22103@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 00:31:14 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 27 Sep 2014 22:31:14 +0000 Subject: [issue20135] FAQ need list mutation answers In-Reply-To: <1388979444.45.0.0357103143169.issue20135@psf.upfronthosting.co.za> Message-ID: <1411857074.91.0.155337712774.issue20135@psf.upfronthosting.co.za> R. David Murray added the comment: Here is my version of Ezio's patch. ---------- Added file: http://bugs.python.org/file36748/mutable_faq.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 02:06:14 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 28 Sep 2014 00:06:14 +0000 Subject: [issue19062] Idle: problem confighandler getting userdir In-Reply-To: <1379777943.19.0.474410652516.issue19062@psf.upfronthosting.co.za> Message-ID: <1411862774.39.0.123057189445.issue19062@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The fact that Idle quits when there is a problem getting (or writing to) the home directory is a design bug discussed in #8231. I do not see any other bug with Idle. So I am closing this as a duplicate. ---------- resolution: -> duplicate stage: test needed -> resolved status: open -> closed superseder: -> Unable to run IDLE without write-access to home directory _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 02:12:14 2014 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 28 Sep 2014 00:12:14 +0000 Subject: [issue9179] Lookback with group references incorrect (two issues?) In-Reply-To: <1278411814.72.0.368411829683.issue9179@psf.upfronthosting.co.za> Message-ID: <1411863134.49.0.351717557371.issue9179@psf.upfronthosting.co.za> Mark Lawrence added the comment: Given the comment from Matthew Barnett in msg109399 "...I had a look at the re module, found it too difficult..." can this be closed as "won't fix"? ---------- nosy: +BreamoreBoy, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 02:21:01 2014 From: report at bugs.python.org (Ethan Furman) Date: Sun, 28 Sep 2014 00:21:01 +0000 Subject: [issue22506] `dir` on Enum subclass doesn't expose parent class attributes In-Reply-To: <1411829845.48.0.985714520453.issue22506@psf.upfronthosting.co.za> Message-ID: <1411863661.39.0.43846457155.issue22506@psf.upfronthosting.co.za> Ethan Furman added the comment: More just a note to myself to research this further, to see exactly what does and does not get inherited. Any tests added will likely be more comprehensive than your example. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 03:34:47 2014 From: report at bugs.python.org (Prof Oak) Date: Sun, 28 Sep 2014 01:34:47 +0000 Subject: [issue22509] Website incorrect link Message-ID: <1411868086.99.0.320325997195.issue22509@psf.upfronthosting.co.za> New submission from Prof Oak: On the python.org website, if you follow the link to PFS on the top, then click on the media tab (not any of the items in the dropdown menu), it takes you to this web page: https://www.python.org/inner/ It looks to be a sample page. ---------- assignee: docs at python components: Documentation messages: 227745 nosy: Prof.Oak, docs at python priority: normal severity: normal status: open title: Website incorrect link type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 03:43:30 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 28 Sep 2014 01:43:30 +0000 Subject: [issue10496] Python startup should not require passwd entry In-Reply-To: <1290398281.89.0.568058332092.issue10496@psf.upfronthosting.co.za> Message-ID: <1411868610.84.0.281136475272.issue10496@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- stage: -> patch review versions: +Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 03:49:08 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 28 Sep 2014 01:49:08 +0000 Subject: [issue20164] Undocumented KeyError from os.path.expanduser In-Reply-To: <1389111327.1.0.12442170212.issue20164@psf.upfronthosting.co.za> Message-ID: <1411868948.17.0.98501292219.issue20164@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I think the doc should be considered correct and posixpath buggy. The ntpath code checks for the existence of HOME and substitutes before returning the arg unchanged, as documented. if 'HOME' in os.environ: userhome = os.environ['HOME'] elif 'USERPROFILE' in os.environ: userhome = os.environ['USERPROFILE'] elif not 'HOMEPATH' in os.environ: return path components: -Documentation nosy: +terry.reedy stage: needs patch -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 04:03:17 2014 From: report at bugs.python.org (Ned Deily) Date: Sun, 28 Sep 2014 02:03:17 +0000 Subject: [issue22509] Website incorrect link In-Reply-To: <1411868086.99.0.320325997195.issue22509@psf.upfronthosting.co.za> Message-ID: <1411869797.86.0.421908709091.issue22509@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the report. However, as noted on the python.org web site help page, https://www.python.org/about/help/, the place to report web site problems is here: https://github.com/python/pythondotorg/issues/ I've opened a new issue there on your behalf: https://github.com/python/pythondotorg/issues/479 ---------- nosy: +ned.deily resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 04:12:09 2014 From: report at bugs.python.org (Martin Panter) Date: Sun, 28 Sep 2014 02:12:09 +0000 Subject: [issue21329] configparser can't parse MySQL style config In-Reply-To: <1398180453.28.0.0252275500481.issue21329@psf.upfronthosting.co.za> Message-ID: <1411870329.61.0.563490014497.issue21329@psf.upfronthosting.co.za> Martin Panter added the comment: See Issue 12662 for a related earlier proposal. (Although the multimap proposal here sounds better than concatenating the values as proposed there.) ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 04:36:34 2014 From: report at bugs.python.org (Martin Panter) Date: Sun, 28 Sep 2014 02:36:34 +0000 Subject: [issue22253] ConfigParser does not handle files without sections In-Reply-To: <1408731768.17.0.221948826268.issue22253@psf.upfronthosting.co.za> Message-ID: <1411871794.7.0.0815995362393.issue22253@psf.upfronthosting.co.za> Martin Panter added the comment: See also Issue 549037, about handling files with a single anonymous section ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 05:13:36 2014 From: report at bugs.python.org (Yongzhi Pan) Date: Sun, 28 Sep 2014 03:13:36 +0000 Subject: [issue22379] Empty exception message of str.join In-Reply-To: <1410317691.24.0.990266868285.issue22379@psf.upfronthosting.co.za> Message-ID: <1411874016.91.0.964906197093.issue22379@psf.upfronthosting.co.za> Yongzhi Pan added the comment: Do the patches still have problems? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 09:05:27 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 28 Sep 2014 07:05:27 +0000 Subject: [issue22139] python windows 2.7.8 64-bit did not install In-Reply-To: <1407238374.16.0.107772681213.issue22139@psf.upfronthosting.co.za> Message-ID: <1411887927.18.0.337629372719.issue22139@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Reopening for somebody to look at; I'm not interested in Python 2.7 anymore. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 10:22:58 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 28 Sep 2014 08:22:58 +0000 Subject: =?utf-8?q?=5Bissue16537=5D_Python=E2=80=99s_setup=2Epy_raises_a_ValueErro?= =?utf-8?q?r_when_self=2Eextensions_is_empty?= In-Reply-To: <1353633257.31.0.391670680901.issue16537@psf.upfronthosting.co.za> Message-ID: <1411892578.32.0.919821743324.issue16537@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: You can use the default parameter of max() in 3.4+. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 10:29:45 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 28 Sep 2014 08:29:45 +0000 Subject: [issue1772673] Replacing char* with const char* Message-ID: <20140928082943.15895.47328@mail.hg.python.org> Roundup Robot added the comment: New changeset 599a957038fa by Serhiy Storchaka in branch 'default': Removed redundant casts to `char *`. https://hg.python.org/cpython/rev/599a957038fa ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 10:51:05 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 28 Sep 2014 08:51:05 +0000 Subject: [issue22503] Signal stack overflow in faulthandler_user In-Reply-To: <1411821697.8.0.131937255622.issue22503@psf.upfronthosting.co.za> Message-ID: <1411894265.38.0.19847493532.issue22503@psf.upfronthosting.co.za> STINNER Victor added the comment: _PyFaulthandler_Init() uses sigaltstack() with a stack of SIGSTKSZ bytes. On my Linux/x86_64, SIGSTKSZ is 8 KB. What is the value of SIGSTKSZ on aarch64? Is there a C define (#ifdef) to use a different size on this architecture? Does the test pass if you modify faulthandler.c to use "SIGSTKSZ * 2"? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 11:19:41 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 28 Sep 2014 09:19:41 +0000 Subject: [issue15363] Idle/tkinter ~x.py 'save as' fails. closes idle In-Reply-To: <1342394243.7.0.336788716257.issue15363@psf.upfronthosting.co.za> Message-ID: <1411895981.7.0.419980547888.issue15363@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Agree with Martin. And I think we should check for starting tilde not base name, but full name. ---------- nosy: +serhiy.storchaka stage: patch review -> needs patch versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 13:43:22 2014 From: report at bugs.python.org (Andreas Schwab) Date: Sun, 28 Sep 2014 11:43:22 +0000 Subject: [issue22503] Signal stack overflow in faulthandler_user In-Reply-To: <1411821697.8.0.131937255622.issue22503@psf.upfronthosting.co.za> Message-ID: <1411904602.57.0.855004035244.issue22503@psf.upfronthosting.co.za> Andreas Schwab added the comment: There is an open bug about MINSIGSTKSZ being too small on aarch64 . How much SIGSTKSZ can guarantee about nested signals is unclear. POSIX does not appear give any guidance. On aarch64 SIGSTKSZ is defined to 8192, which is the default for architectures not overriding it (both in glibc and the kernel headers). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 14:39:32 2014 From: report at bugs.python.org (Eli Bendersky) Date: Sun, 28 Sep 2014 12:39:32 +0000 Subject: [issue22505] Expose an Enum object's serial number In-Reply-To: <1411828846.19.0.205599343734.issue22505@psf.upfronthosting.co.za> Message-ID: <1411907972.86.0.522541049541.issue22505@psf.upfronthosting.co.za> Eli Bendersky added the comment: >> I could continue the discussion about databases, but it feels like a waste of time to me. The main principle is: If something has an important property (in this case an enum object's numerical value), it should be publicly exposed. Period. No need to spend hours discussing if and how that property will be used. They always end up getting used somehow-- The only question is whether the people using them need to obtain them through private variables for years until the developers finally understand that the property needs to be exposed publicly. If you want to go through that, be my guest. This kind of attitude is not welcome in the core Python development community. Please keep the discussion courteous and stick to technical arguments. FWIW I fully agree with Barry and Ethan here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 15:43:11 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 28 Sep 2014 13:43:11 +0000 Subject: [issue22510] Faster bypass re cache when DEBUG is passed Message-ID: <1411911791.72.0.231619321435.issue22510@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Here is a patch which gets rid of small performance regression introduced by issue20426 patch. No need to check flags before cache lookup because patterns with the DEBUG flag are newer cached. $ ./python -m timeit -s "import re" -- "re.match('', '')" Before patch: 9.08 usec per loop After patch: 8 usec per loop ---------- components: Library (Lib), Regular Expressions files: re_debug_cache_faster.patch keywords: patch messages: 227758 nosy: ezio.melotti, mrabarnett, pitrou, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Faster bypass re cache when DEBUG is passed type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file36749/re_debug_cache_faster.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 17:00:06 2014 From: report at bugs.python.org (Saimadhav Heblikar) Date: Sun, 28 Sep 2014 15:00:06 +0000 Subject: [issue22133] IDLE: Set correct WM_CLASS on X11 In-Reply-To: <1407162622.12.0.711549475862.issue22133@psf.upfronthosting.co.za> Message-ID: <1411916406.71.0.0570961198998.issue22133@psf.upfronthosting.co.za> Saimadhav Heblikar added the comment: >I don't know how dialogs and calltip popups behave on Gnome Shell Can you reply what behaviour you want to confirm? If you meant, grouping - Toplevels like ClassBrowser, PathBrowser etc are always grouped as single unit in the "Activity Bar". But, in the popup which you get for "Alt + Tab", they are displayed as 2 different applications - stress on different. For example, if I have two different windows of Google Chrome open, they are listed as a single application, both windows nested under a single logo. With IDLE, its two different applications. tkMessageBox and tkFileDialog usage like in "open_class_browser()" and "Save As" change the title of in the Activity Bar and "Alt+Tab" menu to "tkFDialog". I am not sure if there is a way to pass class_ argument in such a situation. Just a suggestion, can we use sys.version_info to get Python major version to have uniform code? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 17:02:21 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 28 Sep 2014 15:02:21 +0000 Subject: [issue10510] distutils upload/register should use CRLF in HTTP requests In-Reply-To: <1290489114.33.0.672814735109.issue10510@psf.upfronthosting.co.za> Message-ID: <20140928150219.100597.89208@mail.hg.python.org> Roundup Robot added the comment: New changeset 6375bf34fff6 by R David Murray in branch '3.4': #10510: Fix bug in forward port of 2.7 distutils patch. https://hg.python.org/cpython/rev/6375bf34fff6 New changeset 90b07d422bd9 by R David Murray in branch 'default': #10510: Fix bug in forward port of 2.7 distutils patch. https://hg.python.org/cpython/rev/90b07d422bd9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 17:26:49 2014 From: report at bugs.python.org (Mohammed Mustafa Al-Habshi) Date: Sun, 28 Sep 2014 15:26:49 +0000 Subject: [issue22511] Assignment Operators behavior within a user-defined function and arguments being passed by reference or value Message-ID: <1411918009.83.0.649870728612.issue22511@psf.upfronthosting.co.za> New submission from Mohammed Mustafa Al-Habshi: hello every one, I was trying to understand the behavior of passing arguments in a function to differentiate how we can pass argument by value. Though it is a technique matter. However, the behavior of assignment operator += when using it with a list is more to toward behavior to the "append" method of the list object, and not like a a normal assignment. This causes a confusing when teach python language concepts , especially the behavior of += with numerical data types is list normal assignment and the parameters are then passed by value. The issue is more related to data type mutability. and I believe assignment operator should be synthetically more compatible with normal assignment. ---- inline code example ----- def pass_(x): # x is list type print "Within the function" print " x was " , x #x = x + [50] # here x is passed by value x += [50] # here x is passed by reference. #x.append(50) # here x is passed by reference. print " x then is " , x return x = [12,32,12] pass_(x) print "\n x out of the function is " , x ---------- messages: 227761 nosy: alhabshi3k priority: normal severity: normal status: open title: Assignment Operators behavior within a user-defined function and arguments being passed by reference or value type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 18:04:28 2014 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 28 Sep 2014 16:04:28 +0000 Subject: [issue22511] Assignment Operators behavior within a user-defined function and arguments being passed by reference or value In-Reply-To: <1411918009.83.0.649870728612.issue22511@psf.upfronthosting.co.za> Message-ID: <1411920268.43.0.184226440217.issue22511@psf.upfronthosting.co.za> Mark Dickinson added the comment: I'm afraid this bug tracker isn't really the appropriate place for this discussion, so I'm going to close this issue. You could open a discussion on the Python mailing list, here: https://mail.python.org/mailman/listinfo/python-list. ---------- nosy: +mark.dickinson resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 18:11:50 2014 From: report at bugs.python.org (Steven D'Aprano) Date: Sun, 28 Sep 2014 16:11:50 +0000 Subject: [issue22511] Assignment Operators behavior within a user-defined function and arguments being passed by reference or value In-Reply-To: <1411918009.83.0.649870728612.issue22511@psf.upfronthosting.co.za> Message-ID: <1411920710.45.0.687545139895.issue22511@psf.upfronthosting.co.za> Steven D'Aprano added the comment: I'm afraid that you are mistaken about Python's argument passing semantics. Arguments are *always* passed using the same semantics, and *never* using either pass-by-value or pass-by-reference. These two pages may help you understand why Python's argument passing semantics are always the same: http://import-that.dreamwidth.org/1130.html http://effbot.org/zone/call-by-object.htm (Unfortunately, although this is the standard argument passing semantics used in many modern languages, including Python, Java and Ruby, there is no standard name for it.) Augmented assignment is sometimes a little tricky to understand, because it may use both in-place mutation and assignment at the same time. But arguments are still always passed the same way. If you have a concrete suggestion for a documentation change that will help reduce this confusion, please tell us. Otherwise, I think this issue can be closed. This is not the right place to discuss Python's argument passing semantics, but if you would like to discuss it, I'm happy to do so in the comments on the first link, or on the python-list at python.org mailing list. ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 18:23:48 2014 From: report at bugs.python.org (R. David Murray) Date: Sun, 28 Sep 2014 16:23:48 +0000 Subject: [issue22511] Assignment Operators behavior within a user-defined function and arguments being passed by reference or value In-Reply-To: <1411918009.83.0.649870728612.issue22511@psf.upfronthosting.co.za> Message-ID: <1411921428.33.0.547139375376.issue22511@psf.upfronthosting.co.za> R. David Murray added the comment: See also issue 20135. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 18:24:11 2014 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 28 Sep 2014 16:24:11 +0000 Subject: [issue4093] add gc/memory management tests to pybench In-Reply-To: <1223583671.55.0.378027083511.issue4093@psf.upfronthosting.co.za> Message-ID: <1411921451.79.0.0728403286397.issue4093@psf.upfronthosting.co.za> Mark Lawrence added the comment: Antoine or Marc-Andre will either of you follow up on this as the last message msg74608 was nearly six years ago? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 18:50:19 2014 From: report at bugs.python.org (Francis MB) Date: Sun, 28 Sep 2014 16:50:19 +0000 Subject: [issue9313] distutils error on MSVC older than 8 In-Reply-To: <1279624042.03.0.724891043691.issue9313@psf.upfronthosting.co.za> Message-ID: <1411923019.65.0.544923474393.issue9313@psf.upfronthosting.co.za> Francis MB added the comment: Hi ?ric, are the changes to distutils2 applied? could the issue be closed (has resolution:fixed) or is something to be done? ---------- nosy: +francismb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 18:54:30 2014 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 28 Sep 2014 16:54:30 +0000 Subject: [issue9313] distutils error on MSVC older than 8 In-Reply-To: <1279624042.03.0.724891043691.issue9313@psf.upfronthosting.co.za> Message-ID: <1411923270.39.0.412819278542.issue9313@psf.upfronthosting.co.za> Mark Lawrence added the comment: Distutils2 is dead. ---------- components: -Distutils2 nosy: +BreamoreBoy, dstufft _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 18:57:31 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 28 Sep 2014 16:57:31 +0000 Subject: [issue22379] Empty exception message of str.join In-Reply-To: <1410317691.24.0.990266868285.issue22379@psf.upfronthosting.co.za> Message-ID: <20140928165729.51041.9948@mail.hg.python.org> Roundup Robot added the comment: New changeset 0ad19246d16d by Benjamin Peterson in branch '2.7': give exception a nice message (closes #22379) https://hg.python.org/cpython/rev/0ad19246d16d New changeset ab1570d0132d by Benjamin Peterson in branch '3.4': check that exception messages are not empty (#22379) https://hg.python.org/cpython/rev/ab1570d0132d New changeset 78727a11b5ae by Benjamin Peterson in branch 'default': merge 3.4 (#22379) https://hg.python.org/cpython/rev/78727a11b5ae ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 19:15:39 2014 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 28 Sep 2014 17:15:39 +0000 Subject: [issue2148] nis module not supporting group aliases In-Reply-To: <1203510631.66.0.497834646199.issue2148@psf.upfronthosting.co.za> Message-ID: <1411924539.87.0.813937616765.issue2148@psf.upfronthosting.co.za> Mark Lawrence added the comment: I think this should be an enhancement request. ---------- components: +Library (Lib) -None nosy: +BreamoreBoy, jcea type: behavior -> enhancement versions: +Python 3.5 -Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 19:19:20 2014 From: report at bugs.python.org (Francis MB) Date: Sun, 28 Sep 2014 17:19:20 +0000 Subject: [issue9313] distutils error on MSVC older than 8 In-Reply-To: <1279624042.03.0.724891043691.issue9313@psf.upfronthosting.co.za> Message-ID: <1411924760.02.0.222093837216.issue9313@psf.upfronthosting.co.za> Francis MB added the comment: > Distutils2 is dead. I wasn't aware of that and I'm sorry for that. In that case that issue can IMHO be closed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 19:46:38 2014 From: report at bugs.python.org (Berker Peksag) Date: Sun, 28 Sep 2014 17:46:38 +0000 Subject: [issue9313] distutils error on MSVC older than 8 In-Reply-To: <1279624042.03.0.724891043691.issue9313@psf.upfronthosting.co.za> Message-ID: <1411926398.48.0.620490930851.issue9313@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 20:55:15 2014 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 28 Sep 2014 18:55:15 +0000 Subject: [issue10007] Visual C++ cannot build _ssl and _hashlib if newer OpenSSL is placed in $(dist) directory (PCBuild) In-Reply-To: <1285944430.56.0.132893198817.issue10007@psf.upfronthosting.co.za> Message-ID: <1411930515.21.0.290424889126.issue10007@psf.upfronthosting.co.za> Mark Lawrence added the comment: Has this been superseded by the many improvements made to the Windows build system over the last few months or even years? ---------- nosy: +BreamoreBoy, steve.dower, zach.ware type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 20:55:57 2014 From: report at bugs.python.org (RobertG) Date: Sun, 28 Sep 2014 18:55:57 +0000 Subject: [issue20742] 2to3 zip fixer doesn't fix for loops. In-Reply-To: <1393153907.74.0.496388533035.issue20742@psf.upfronthosting.co.za> Message-ID: <1411930557.01.0.163342945621.issue20742@psf.upfronthosting.co.za> RobertG added the comment: As far as a non contrived example, see http://bugs.python.org/issue21628, which was marked as a duplicate of this bug. This bug is the main thing preventing me from using 2to3, so I think it is a real issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 21:10:42 2014 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 28 Sep 2014 19:10:42 +0000 Subject: [issue1382562] --install-base not honored on win32 Message-ID: <1411931442.68.0.46810287117.issue1382562@psf.upfronthosting.co.za> Mark Lawrence added the comment: I'd try to reproduce this but with so little data to go on I don't understand how. Can somebody fill the gaps? ---------- components: +Windows -Distutils2 nosy: +BreamoreBoy, dstufft versions: +Python 3.4, Python 3.5 -3rd party, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 22:50:37 2014 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 28 Sep 2014 20:50:37 +0000 Subject: [issue9643] urllib2 - Basic, Digest Proxy Auth Handlers failure will give 401 code instead of 407 In-Reply-To: <1282240751.95.0.79564995249.issue9643@psf.upfronthosting.co.za> Message-ID: <1411937437.21.0.278005012185.issue9643@psf.upfronthosting.co.za> Mark Lawrence added the comment: Slipped under the radar? ---------- components: +Library (Lib) nosy: +BreamoreBoy type: -> behavior versions: +Python 3.4, Python 3.5 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 22:57:09 2014 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 28 Sep 2014 20:57:09 +0000 Subject: [issue1160328] urllib2 post error when using httpproxy Message-ID: <1411937829.53.0.021141316053.issue1160328@psf.upfronthosting.co.za> Mark Lawrence added the comment: >From msg60698 "The first URL hangs for me, using Firefox. Especially if this depends on using a proxy which I do not have permission to use, I have no idea how to reproduce this." I certainly have no idea on how to reproduce this so unless someone can the only option I see is to close as "out of date". ---------- nosy: +BreamoreBoy versions: +Python 3.4, Python 3.5 -Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 23:03:38 2014 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 28 Sep 2014 21:03:38 +0000 Subject: [issue1565509] Repair or Change installation error Message-ID: <1411938218.6.0.142621200791.issue1565509@psf.upfronthosting.co.za> Mark Lawrence added the comment: I don't recall ever seeing a problem like this, but then I haven't used IE in years and don't intend using it now just for this. ---------- components: +Windows nosy: +BreamoreBoy, steve.dower, zach.ware versions: +Python 3.4, Python 3.5 -Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 23:26:41 2014 From: report at bugs.python.org (Francis MB) Date: Sun, 28 Sep 2014 21:26:41 +0000 Subject: [issue22512] 'test_distutils.test_bdist_rpm' causes creation of directory '.rpmdb' on home dir Message-ID: <1411939601.45.0.729692387398.issue22512@psf.upfronthosting.co.za> New submission from Francis MB: Running the test suite or 'test_distutils' triggers the creation of the directory '.rpmdb'. I noticed that because somehow that directory was bad formed and got errors while running the test suite: error: db5 error(-30969) from dbenv->open: BDB0091 DB_VERSION_MISMATCH: Database environment version mismatch error: cannot open Packages index using db5 - (-30969) error: cannot open Packages database in /home/ci/.rpmdb error: db5 error(-30969) from dbenv->open: BDB0091 DB_VERSION_MISMATCH: Database environment version mismatch error: cannot open Packages index using db5 - (-30969) error: cannot open Packages database in /home/ci/.rpmdb After moving that directory and running the suite again the directory reappeared (but that time, and since then, no errors occurred). It seems that 'test_distutils.test_bdist_rpm' triggers that behavior. This seems to be due 'rpm' having it so configured [1]. In my case: $ rpm -v --showrc | grep '.rpmdb' -14: _dbpath %(bash -c 'echo ~/.rpmdb') Here is a patch that confines the creation of this directory to the temporal test directory. Regards, francis ---- [1] https://bugs.launchpad.net/rpm/+bug/1069350 ---------- components: Distutils, Tests files: confine_hidden_rpmdb_dir_creation.patch keywords: patch messages: 227777 nosy: dstufft, eric.araujo, francismb priority: normal severity: normal status: open title: 'test_distutils.test_bdist_rpm' causes creation of directory '.rpmdb' on home dir type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file36750/confine_hidden_rpmdb_dir_creation.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 23:36:35 2014 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 28 Sep 2014 21:36:35 +0000 Subject: [issue678264] test_resource fails when file size is limited Message-ID: <1411940195.09.0.926256011339.issue678264@psf.upfronthosting.co.za> Mark Lawrence added the comment: Can somebody take a look at this please. See also #9917. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 28 23:54:36 2014 From: report at bugs.python.org (paul j3) Date: Sun, 28 Sep 2014 21:54:36 +0000 Subject: [issue9350] add remove_argument_group to argparse In-Reply-To: <1279893088.18.0.675631346333.issue9350@psf.upfronthosting.co.za> Message-ID: <1411941276.54.0.518683019283.issue9350@psf.upfronthosting.co.za> paul j3 added the comment: If the empty argument group has a 'description' it is displayed. For example with positionals group that I mentioned earlier: parser = argparse.ArgumentParser() parser._action_groups[0].description = 'test' parser.print_help() produces usage: ipython [-h] positional arguments: test optional arguments: -h, --help show this help message and exit So the user can fix this empty group display issue by setting this 'description' value to None. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 01:12:07 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 28 Sep 2014 23:12:07 +0000 Subject: [issue20858] Enhancements/fixes to pure-python datetime module In-Reply-To: <1394131058.9.0.404670194335.issue20858@psf.upfronthosting.co.za> Message-ID: <20140928231205.100607.25265@mail.hg.python.org> Roundup Robot added the comment: New changeset 5313b4c0bb6c by Alexander Belopolsky in branch 'default': Closes issue #20858: Enhancements/fixes to pure-python datetime module https://hg.python.org/cpython/rev/5313b4c0bb6c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 01:15:50 2014 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 28 Sep 2014 23:15:50 +0000 Subject: [issue8988] import + coding = failure (3.1.2/win32) In-Reply-To: <1276426235.15.0.873898512927.issue8988@psf.upfronthosting.co.za> Message-ID: <1411946150.59.0.386036727097.issue8988@psf.upfronthosting.co.za> Mark Lawrence added the comment: Works for me using 3.4.1 and 3.5.0a0. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 01:31:56 2014 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 28 Sep 2014 23:31:56 +0000 Subject: [issue8747] Autoconf tests in python not portably correct In-Reply-To: <1274174021.7.0.201652385814.issue8747@psf.upfronthosting.co.za> Message-ID: <1411947116.56.0.986022797447.issue8747@psf.upfronthosting.co.za> Mark Lawrence added the comment: >From msg112274 "if these platforms can't function with these preprocessor defines, the platforms need to be fixed -- not python." so I believe this can be closed. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 01:42:24 2014 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 28 Sep 2014 23:42:24 +0000 Subject: [issue10036] compiler warnings for various modules on Linux buildslaves In-Reply-To: <1286344285.28.0.174737248843.issue10036@psf.upfronthosting.co.za> Message-ID: <1411947744.25.0.69393654251.issue10036@psf.upfronthosting.co.za> Mark Lawrence added the comment: >From msg119142 "I suspect we don't really fix libffi compile warnings because ..." so it looks as if we wouldn't bother anyway, plus these compiler warnings are years old so can this be closed as "out of date"? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 01:54:50 2014 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 28 Sep 2014 23:54:50 +0000 Subject: [issue9943] TypeError message became less helpful in Python 2.7 In-Reply-To: <1285357459.53.0.518722150406.issue9943@psf.upfronthosting.co.za> Message-ID: <1411948490.91.0.929727763627.issue9943@psf.upfronthosting.co.za> Mark Lawrence added the comment: 3.4.1 and 3.5.0a0 give the same message as 2.6. I don't have 2.7 to see what it currently does. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 03:40:23 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 29 Sep 2014 01:40:23 +0000 Subject: [issue22512] 'test_distutils.test_bdist_rpm' causes creation of directory '.rpmdb' on home dir In-Reply-To: <1411939601.45.0.729692387398.issue22512@psf.upfronthosting.co.za> Message-ID: <1411954823.63.0.0488824463401.issue22512@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks for the report and patch. You should use test.support.EnvironmentVarGuard to make the environment change temporary. ---------- nosy: +r.david.murray versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 03:58:29 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 29 Sep 2014 01:58:29 +0000 Subject: [issue20858] Enhancements/fixes to pure-python datetime module In-Reply-To: <1394131058.9.0.404670194335.issue20858@psf.upfronthosting.co.za> Message-ID: <1411955909.82.0.355387972695.issue20858@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 04:20:32 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 29 Sep 2014 02:20:32 +0000 Subject: [issue9943] TypeError message became less helpful in Python 2.7 In-Reply-To: <1285357459.53.0.518722150406.issue9943@psf.upfronthosting.co.za> Message-ID: <1411957232.2.0.306526965811.issue9943@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Still TypeError: f() takes exactly 0 arguments (2 given). I consider the 2.6/3.x message better (more accurate). But at this point, I could be persuaded to leave 2.7 alone and close this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 04:57:24 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 29 Sep 2014 02:57:24 +0000 Subject: [issue9943] TypeError message became less helpful in Python 2.7 In-Reply-To: <1285357459.53.0.518722150406.issue9943@psf.upfronthosting.co.za> Message-ID: <1411959444.3.0.367638512484.issue9943@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Yes, the argument error messages for 2.x are all not very good. Note this issue was fixed once and for all in Python 3: % python3 x.py Traceback (most recent call last): File "x.py", line 3, in f("hello", keyword=True) TypeError: f() takes 0 positional arguments but 1 was given ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 07:58:57 2014 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Mon, 29 Sep 2014 05:58:57 +0000 Subject: [issue21159] configparser.InterpolationMissingOptionError is not very intuitive In-Reply-To: <1396694112.28.0.289974893208.issue21159@psf.upfronthosting.co.za> Message-ID: <1411970337.0.0.834866906746.issue21159@psf.upfronthosting.co.za> ?ukasz Langa added the comment: So the diff would look like this (please find it attached). It does two things: * changes messages on InterpolationMissingOptionError and InterpolationDepthError to be more helpful to the end user * fixes rawval to actually hold the raw value of an option and not the "rest after substitution" like before Fred, R. David, I have two questions for you: * the reliable method of getting the arguments of both exceptions is the .args attribute; this didn't change but the message did. It's unlikely anybody would be parsing the old message string, but even if there was I'm inclined to treat any code doing so as broken by design. Do you agree? * without the diff, the `rawval` argument in those exceptions holds a value that exposes internal implementation and is not generally useful for user code. It wasn't exposed directly as an attribute in those exceptions (`section`, `option` and `reference` are). That being said, fixing this is a change in logic of sorts. Do you see any danger of third-party code relying on the old behaviour? Actually, I have a hypothetical third question: * Should I make sure that those exceptions are unpicklable by older releases of Python 3? I'm asking because if there's no such expectation, we could add .rawval as a direct attribute to InterpolationMissingOptionError, and introduce `reference` to InterpolationDepthError (currently the exception message can say that "option O in section S contains an interpolation key that cannot be substituted" but it doesn't say which interpolation key). Anyway, the first two questions are most important because they basically decide whether we can change the exceptions at all at this point. I'm inclined to say "yes", Python 3 did that with a number of exceptions both built-in and in the standard library. ---------- keywords: +patch nosy: +fdrake stage: needs patch -> patch review Added file: http://bugs.python.org/file36751/issue21159.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 11:57:48 2014 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 29 Sep 2014 09:57:48 +0000 Subject: [issue6978] compiler.transformer dict key bug d[1,] = 1 In-Reply-To: <1253712935.73.0.771654753866.issue6978@psf.upfronthosting.co.za> Message-ID: <1411984668.51.0.642553593371.issue6978@psf.upfronthosting.co.za> Mark Lawrence added the comment: Can somebody set this to "patch review" and do the honours please. FWIW I don't like "tulplesub" in the patch. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 12:11:42 2014 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 29 Sep 2014 10:11:42 +0000 Subject: [issue9912] Fail when vsvarsall.bat produces stderr In-Reply-To: <1285082676.18.0.058541871992.issue9912@psf.upfronthosting.co.za> Message-ID: <1411985502.34.0.199295776981.issue9912@psf.upfronthosting.co.za> Mark Lawrence added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 12:17:45 2014 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 29 Sep 2014 10:17:45 +0000 Subject: [issue809846] bdist_wininst doesn't clean up read-only files in build dir Message-ID: <1411985865.04.0.835352840453.issue809846@psf.upfronthosting.co.za> Mark Lawrence added the comment: I understand from the experts list that tarek is no longer maintaining distutils but I can't change the "assigned to" field. As a matter of interest there are another 67 issues with tarek assigned. ---------- nosy: +BreamoreBoy, dstufft versions: +Python 3.4, Python 3.5 -Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 12:40:04 2014 From: report at bugs.python.org (John Isidore) Date: Mon, 29 Sep 2014 10:40:04 +0000 Subject: [issue22389] Generalize contextlib.redirect_stdout In-Reply-To: <1410445513.66.0.871890162607.issue22389@psf.upfronthosting.co.za> Message-ID: <1411987204.69.0.589167793411.issue22389@psf.upfronthosting.co.za> John Isidore added the comment: There is stdout_redirected() function [1] that allows to redirect a file object given as `stdout` patameter including `sys.stderr`. It works at a file descriptor level i.e. it supports redirecting subprocess' output too but it doesn't work for StringIO (no fd). [1] http://stackoverflow.com/questions/4675728/redirect-stdout-to-a-file-in-python/22434262#22434262 ---------- nosy: +John Isidore _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 12:54:59 2014 From: report at bugs.python.org (Akira Li) Date: Mon, 29 Sep 2014 10:54:59 +0000 Subject: [issue22472] OSErrors should use str and not repr on paths In-Reply-To: <1411504485.58.0.497867466453.issue22472@psf.upfronthosting.co.za> Message-ID: <1411988099.65.0.77287675586.issue22472@psf.upfronthosting.co.za> Akira Li added the comment: OSError has *filename* attribute. Could it be passed to the UI instead? ---------- nosy: +akira _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 13:02:21 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 29 Sep 2014 11:02:21 +0000 Subject: [issue21159] configparser.InterpolationMissingOptionError is not very intuitive In-Reply-To: <1396694112.28.0.289974893208.issue21159@psf.upfronthosting.co.za> Message-ID: <1411988541.11.0.421972054426.issue21159@psf.upfronthosting.co.za> R. David Murray added the comment: We never promise that the messages won't change (they are not part of the API), so that part isn't a problem. We do try to be backward compatible there when it comes to args beyond the message text. I don't think unpickleability is an issue; at least there isn't any discussion of it in PEP 3161, and I don't remember any around the implementation. I think this is fine. I don't think we should worry about someone who is actually using rawval/rest pulled out of the exception args. You could put a porting note in What's New, but my guess is that the chances of anyone being inconvenienced by this are pretty near to zero. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 14:06:51 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 29 Sep 2014 12:06:51 +0000 Subject: [issue22472] OSErrors should use str and not repr on paths In-Reply-To: <1411504485.58.0.497867466453.issue22472@psf.upfronthosting.co.za> Message-ID: <1411992411.27.0.269258690401.issue22472@psf.upfronthosting.co.za> R. David Murray added the comment: No, because I'm just logging the error message. That's the UI. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 15:12:33 2014 From: report at bugs.python.org (James Spurin) Date: Mon, 29 Sep 2014 13:12:33 +0000 Subject: [issue17835] test_io broken on PPC64 Linux In-Reply-To: <1366830173.09.0.170493348126.issue17835@psf.upfronthosting.co.za> Message-ID: <1411996353.26.0.382069678535.issue17835@psf.upfronthosting.co.za> James Spurin added the comment: With both the kernel parameters defined and undefined, I get the following output - # /local/0/opt/python-3.4.1/bin/python Python 3.4.1 (default, Sep 29 2014, 13:31:39) [GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from socket import socket, SO_SNDBUF, SOL_SOCKET >>> s = socket() >>> s.getsockopt(SOL_SOCKET, SO_SNDBUF) 16384 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 16:16:52 2014 From: report at bugs.python.org (bagrat lazaryan) Date: Mon, 29 Sep 2014 14:16:52 +0000 Subject: [issue22460] idle editor: replace all in selection In-Reply-To: <1411381735.15.0.967867369025.issue22460@psf.upfronthosting.co.za> Message-ID: <1412000212.68.0.64784803673.issue22460@psf.upfronthosting.co.za> bagrat lazaryan added the comment: replacing across multiple files is something i personally considered too fancy for idle, but that's a great feature. the same goes for smart selections like selecting multiline statements. if they don't contradict idle's simplicity ideology they are great canditates to be implemented. as to the editors currently implementing replace-in-selection, notepad++ is one. it actually does exactly what terry suggested, activating an "in selection" checkbox only if something is selected. (visual studio, and python tools for visual studio in particular, have some replacement and refactoring abilities too.) ---------------------------------------------------------------------- now, guys, i'm very sorry that i have to return to my already mentioned off-topic issue: i'm not getting emails from bugtracker. not even in spam. i was about to file a bug on the metatracker but it seems i can't even register on it because i am not receiving that confirmation email to activate my account! i don't know if http://psf.upfronthosting.co.za/roundup/meta/issue541 is related to my problem. it seems it might be. what am i to do? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 16:23:39 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 29 Sep 2014 14:23:39 +0000 Subject: [issue9104] test.support method for dual-testing accelerated code (fixes test_exceptions and other's pickle testing) In-Reply-To: <1277741892.3.0.0849773844587.issue9104@psf.upfronthosting.co.za> Message-ID: <1412000619.74.0.986671251285.issue9104@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- assignee: belopolsky -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 16:24:34 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 29 Sep 2014 14:24:34 +0000 Subject: [issue20135] FAQ need list mutation answers In-Reply-To: <1388979444.45.0.0357103143169.issue20135@psf.upfronthosting.co.za> Message-ID: <20140929142415.100039.26253@mail.hg.python.org> Roundup Robot added the comment: New changeset 138f54622841 by R David Murray in branch '3.4': #20135: FAQ entry for list mutation. (See also 6375bf34fff6.) https://hg.python.org/cpython/rev/138f54622841 New changeset 3d924bbfdcbc by R David Murray in branch 'default': Merge: #20135: FAQ entry for list mutation. (See also 90b07d422bd9.) https://hg.python.org/cpython/rev/3d924bbfdcbc New changeset 2b9db1fce82e by R David Murray in branch '2.7': #20135: FAQ entry for list mutation. https://hg.python.org/cpython/rev/2b9db1fce82e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 16:26:26 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 29 Sep 2014 14:26:26 +0000 Subject: [issue20135] FAQ need list mutation answers In-Reply-To: <1388979444.45.0.0357103143169.issue20135@psf.upfronthosting.co.za> Message-ID: <1412000786.21.0.691431952298.issue20135@psf.upfronthosting.co.za> R. David Murray added the comment: I accidentally committed the patch early to 3.4/3.5. I've now addressed Ezio's review comment per my suggestion on the review, and committed it to 2.7 as well. Thanks everyone for your contributions. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 16:34:33 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 29 Sep 2014 14:34:33 +0000 Subject: [issue21338] Silent mode for compileall In-Reply-To: <1398295772.24.0.550494832702.issue21338@psf.upfronthosting.co.za> Message-ID: <1412001273.5.0.706283375014.issue21338@psf.upfronthosting.co.za> R. David Murray added the comment: Berker: I had some review comments pending on the docs, but reitveld isn't letting me publish them for some reason (it says the patch set doesn't exist). The comments are: the method docs should probably say "``False`` or ``0`` (the default)" (and all the numbers should be marked up as code), and the versionchanged I think should say that the option was changed to a multilevel value. Otherwise the patch looks good to me, too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 16:56:35 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 29 Sep 2014 14:56:35 +0000 Subject: [issue20858] Enhancements/fixes to pure-python datetime module In-Reply-To: <1394131058.9.0.404670194335.issue20858@psf.upfronthosting.co.za> Message-ID: <1412002595.69.0.378692259619.issue20858@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: commit review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 17:14:32 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 29 Sep 2014 15:14:32 +0000 Subject: [issue22510] Faster bypass re cache when DEBUG is passed In-Reply-To: <1411911791.72.0.231619321435.issue22510@psf.upfronthosting.co.za> Message-ID: <20140929151420.100099.93623@mail.hg.python.org> Roundup Robot added the comment: New changeset 565096a32ce4 by Serhiy Storchaka in branch 'default': Issue #22510: Get rid of little overhead of testing re.DEBUG flag. https://hg.python.org/cpython/rev/565096a32ce4 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 17:26:05 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 29 Sep 2014 15:26:05 +0000 Subject: [issue17442] code.InteractiveInterpreter doesn't display the exception cause In-Reply-To: <1363468664.92.0.794606977989.issue17442@psf.upfronthosting.co.za> Message-ID: <20140929152602.1230.79063@mail.hg.python.org> Roundup Robot added the comment: New changeset 2b212a8186e0 by R David Murray in branch 'default': #17442: Add chained traceback support to InteractiveInterpreter. https://hg.python.org/cpython/rev/2b212a8186e0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 17:29:43 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 29 Sep 2014 15:29:43 +0000 Subject: [issue17442] code.InteractiveInterpreter doesn't display the exception cause In-Reply-To: <1363468664.92.0.794606977989.issue17442@psf.upfronthosting.co.za> Message-ID: <1412004583.1.0.220372899481.issue17442@psf.upfronthosting.co.za> R. David Murray added the comment: After reconsidering Terry's idle example, it seems to me that the change could adversely impact existing code that already works around the lack of chained tracebacks, even as idle does. So I committed this to 3.5 only as an enhancement. Thanks Claudiu. As an aside, isn't it a (pre-existing) bug that if an excepthook exists, it gets passed None for the traceback? ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed type: behavior -> enhancement versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 17:35:36 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 29 Sep 2014 15:35:36 +0000 Subject: [issue12006] strptime should implement %V or %u directive from libc In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za> Message-ID: <1412004936.79.0.907857486431.issue12006@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: For future reference, here is the example showing %Y %V ambiguity: >>> date(2013,12,31).strftime('%Y %V %u') '2013 01 2' >>> date(2013,1,1).strftime('%Y %V %u') '2013 01 2' which is resolved by using %G >>> date(2013,12,31).strftime('%G %V %u') '2014 01 2' >>> date(2013,1,1).strftime('%G %V %u') '2013 01 2' In other words, '2013 01 2' cannot be unambiguously parsed using '%Y %V %u' format. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 17:44:29 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 29 Sep 2014 15:44:29 +0000 Subject: [issue12006] strptime should implement %G, %V and %u directives In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za> Message-ID: <1412005468.99.0.239151103545.issue12006@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I think we need more tests showing that new directives don't violate strftime - strptime round-trip invariants. ---------- title: strptime should implement %V or %u directive from libc -> strptime should implement %G, %V and %u directives _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 17:47:42 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 29 Sep 2014 15:47:42 +0000 Subject: [issue12006] strptime should implement %G, %V and %u directives In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za> Message-ID: <1412005662.88.0.821646595224.issue12006@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Documentation should say "new in 3.5". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 18:01:03 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 29 Sep 2014 16:01:03 +0000 Subject: [issue5979] strptime() gives inconsistent exceptions In-Reply-To: <1241896450.71.0.860512052019.issue5979@psf.upfronthosting.co.za> Message-ID: <1412006463.39.0.0320040037989.issue5979@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 18:31:06 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 29 Sep 2014 16:31:06 +0000 Subject: [issue5979] strptime() gives inconsistent exceptions In-Reply-To: <1241896450.71.0.860512052019.issue5979@psf.upfronthosting.co.za> Message-ID: <1412008266.98.0.302304269242.issue5979@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: needs patch -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 18:50:54 2014 From: report at bugs.python.org (Steve Dower) Date: Mon, 29 Sep 2014 16:50:54 +0000 Subject: [issue1565509] Repair or Change installation error Message-ID: <1412009454.08.0.983319569449.issue1565509@psf.upfronthosting.co.za> Steve Dower added the comment: Newer versions of Windows Installer (this looks like an XP issue...) will preserve a copy of the original MSI in a safe place, so this problem should not occur any more. I vote to close. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 18:57:51 2014 From: report at bugs.python.org (Steve Dower) Date: Mon, 29 Sep 2014 16:57:51 +0000 Subject: [issue10007] Visual C++ cannot build _ssl and _hashlib if newer OpenSSL is placed in $(dist) directory (PCBuild) In-Reply-To: <1285944430.56.0.132893198817.issue10007@psf.upfronthosting.co.za> Message-ID: <1412009871.31.0.177207107784.issue10007@psf.upfronthosting.co.za> Steve Dower added the comment: Should be fine. Both 2.7 and default have the full OpenSSL version in pyproject.vsprops, so they'll only use the version they expect. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 19:02:10 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 29 Sep 2014 17:02:10 +0000 Subject: [issue22510] Faster bypass re cache when DEBUG is passed In-Reply-To: <1411911791.72.0.231619321435.issue22510@psf.upfronthosting.co.za> Message-ID: <1412010130.45.0.742248425055.issue22510@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Antoine for your review. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 19:19:31 2014 From: report at bugs.python.org (Ethan Furman) Date: Mon, 29 Sep 2014 17:19:31 +0000 Subject: [issue22513] grp.struct_group is not hashable Message-ID: <1412011171.66.0.600285567527.issue22513@psf.upfronthosting.co.za> New submission from Ethan Furman: First, the behavior for pwd.struct_passwd: ----------------------------------------- --> pwd.getpwuid(1000) pwd.struct_passwd(pw_name='ethan', pw_passwd='x', pw_uid=1000, pw_gid=1000, pw_gecos='Ethan Furman,,,', pw_dir='/home/ethan', pw_shell='/bin/bash') --> set(pwd.getpwuid(1000)) set(['/bin/bash', 1000, 'Ethan Furman,,,', '/home/ethan', 'ethan', 'x']) --> set([pwd.getpwuid(1000)]) set([pwd.struct_passwd(pw_name='ethan', pw_passwd='x', pw_uid=1000, pw_gid=1000, pw_gecos='Ethan Furman,,,', pw_dir='/home/ethan', pw_shell='/bin/bash')]) Now, the behavior for grp.struct_group: -------------------------------------- --> grp.getgrgid(1000) grp.struct_group(gr_name='ethan', gr_passwd='x', gr_gid=1000, gr_mem=[]) --> set(grp.getgrgid(1000)) Traceback (most recent call last): File "", line 1, in TypeError: unhashable type: 'list' --> set([grp.getgrgid(1000)]) Traceback (most recent call last): File "", line 1, in TypeError: unhashable type: 'list' At the very least the error message is wrong (it's not a list), and at the most grp.struct_group should be hashable -- i.e. we should be able to have a set of groups. ---------- messages: 227811 nosy: ethan.furman priority: normal severity: normal status: open title: grp.struct_group is not hashable type: behavior versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 19:45:51 2014 From: report at bugs.python.org (Claudiu Popa) Date: Mon, 29 Sep 2014 17:45:51 +0000 Subject: [issue17442] code.InteractiveInterpreter doesn't display the exception cause In-Reply-To: <1363468664.92.0.794606977989.issue17442@psf.upfronthosting.co.za> Message-ID: <1412012751.43.0.742240178346.issue17442@psf.upfronthosting.co.za> Claudiu Popa added the comment: Indeed, it's a preexisting bug. I'll try to come up with a patch shortly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 19:49:48 2014 From: report at bugs.python.org (Ethan Furman) Date: Mon, 29 Sep 2014 17:49:48 +0000 Subject: [issue22513] grp.struct_group is not hashable In-Reply-To: <1412011171.66.0.600285567527.issue22513@psf.upfronthosting.co.za> Message-ID: <1412012988.3.0.867450009514.issue22513@psf.upfronthosting.co.za> Ethan Furman added the comment: Test added. ---------- keywords: +patch stage: -> needs patch Added file: http://bugs.python.org/file36752/issue22513.stoneleaf.01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 20:11:49 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 29 Sep 2014 18:11:49 +0000 Subject: [issue6978] compiler.transformer dict key bug d[1,] = 1 In-Reply-To: <1253712935.73.0.771654753866.issue6978@psf.upfronthosting.co.za> Message-ID: <1412014309.47.0.0298508515171.issue6978@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I am closing this because a) Meador is correct that we do not normally patch deprecated features and b) the current emphasis on 2.7-only patches is security and keeping 2.7 working on current systems. The fix would only benefit 2.7.9+ code or 2.7.9+ and 3.x code, neither of which should be using compiler module. Benjamin, if you disagree, review and apply, as no one else will. ---------- resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 20:15:27 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 29 Sep 2014 18:15:27 +0000 Subject: [issue22460] idle editor: replace all in selection In-Reply-To: <1411381735.15.0.967867369025.issue22460@psf.upfronthosting.co.za> Message-ID: <1412014527.68.0.207594974026.issue22460@psf.upfronthosting.co.za> Terry J. Reedy added the comment: About your email problem: post to core-mentorship list and if you cannot do that, write to Ezio Melotti and/or R. David Murray directly, as they are tracker maintainers. ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 21:02:29 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 29 Sep 2014 19:02:29 +0000 Subject: [issue22513] grp.struct_group is not hashable In-Reply-To: <1412011171.66.0.600285567527.issue22513@psf.upfronthosting.co.za> Message-ID: <1412017349.12.0.299082842103.issue22513@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is because grp.struct_group contains unhashable component (a list). Same behavior with tuple: >>> tuple(grp.getgrgid(1000)) ('serhiy', 'x', 1000, []) >>> set(tuple(grp.getgrgid(1000))) Traceback (most recent call last): File "", line 1, in TypeError: unhashable type: 'list' >>> set([tuple(grp.getgrgid(1000))]) Traceback (most recent call last): File "", line 1, in TypeError: unhashable type: 'list' Instead a set of grp.struct_group, create a dict, which maps group name to grp.struct_group. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 21:16:15 2014 From: report at bugs.python.org (Ethan Furman) Date: Mon, 29 Sep 2014 19:16:15 +0000 Subject: [issue22513] grp.struct_group is not hashable In-Reply-To: <1412011171.66.0.600285567527.issue22513@psf.upfronthosting.co.za> Message-ID: <1412018175.81.0.430477347442.issue22513@psf.upfronthosting.co.za> Ethan Furman added the comment: Thanks, Serhiy. ---------- resolution: -> not a bug stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 21:17:16 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 29 Sep 2014 19:17:16 +0000 Subject: [issue22486] Add math.gcd() In-Reply-To: <1411591235.17.0.168367966743.issue22486@psf.upfronthosting.co.za> Message-ID: <1412018236.29.0.814435819449.issue22486@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 21:22:10 2014 From: report at bugs.python.org (Friedrich Spee von Langenfeld) Date: Mon, 29 Sep 2014 19:22:10 +0000 Subject: [issue22514] incomplete programming example on python.org Message-ID: <1412018530.64.0.603164389398.issue22514@psf.upfronthosting.co.za> New submission from Friedrich Spee von Langenfeld: When I open www.python.org, there are some examples to demonstrate the "look and feel" of Python. I?ve tested an example (example number 1). Online, the following is shown: # Python 3: Fibonacci series up to n >>> def fib(n): >>> a, b = 0, 1 >>> while a < n: >>> print(a, end=' ') >>> a, b = b, a+b >>> print() >>> fib(1000) 0 1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 But then I have tested the (following) code with Python 3.1: >>> def fib(n): a, b = 0, 1 while a < n: print(a, end=" ") a, b = b, a+b print() >>> fib(1000) 0 1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 As you can see, the last number(987)wasn?t shown online. Perhaps, this behavior is browser-dependent. I?ve used Mozilla Firefox 32.0.3 . I can?t estimate the priority of this issue, because I can?t imagine how many people are using or analysing the examples. Can you reproduce my findings? ---------- messages: 227818 nosy: Friedrich.Spee.von.Langenfeld priority: normal severity: normal status: open title: incomplete programming example on python.org _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 21:33:21 2014 From: report at bugs.python.org (Ram Rachum) Date: Mon, 29 Sep 2014 19:33:21 +0000 Subject: [issue22515] Implement partial order on Counter Message-ID: <1412019201.2.0.639073460867.issue22515@psf.upfronthosting.co.za> New submission from Ram Rachum: I suggest implementing `Counter.__lt__` which will be a partial order, similarly to `set.__lt__`. That is, one counter will be considered smaller-or-equal to another if for any item in the first counter, the second counter has an equal or bigger amount of that item. ---------- components: Library (Lib) messages: 227819 nosy: cool-RR priority: normal severity: normal status: open title: Implement partial order on Counter versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 21:35:50 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 29 Sep 2014 19:35:50 +0000 Subject: [issue22194] access to cdecimal / libmpdec API In-Reply-To: <1408022998.0.0.480794879626.issue22194@psf.upfronthosting.co.za> Message-ID: <1412019350.97.0.181647103773.issue22194@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 21:50:49 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 29 Sep 2014 19:50:49 +0000 Subject: [issue22437] re module: number of named groups is limited to 100 max In-Reply-To: <1411061982.07.0.646375842297.issue22437@psf.upfronthosting.co.za> Message-ID: <20140929195043.1253.16027@mail.hg.python.org> Roundup Robot added the comment: New changeset 0b85ea4bd1af by Serhiy Storchaka in branch 'default': Issue #22437: Number of capturing groups in regular expression is no longer https://hg.python.org/cpython/rev/0b85ea4bd1af ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 21:50:58 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 29 Sep 2014 19:50:58 +0000 Subject: [issue22514] incomplete programming example on python.org In-Reply-To: <1412018530.64.0.603164389398.issue22514@psf.upfronthosting.co.za> Message-ID: <1412020258.71.0.492605571709.issue22514@psf.upfronthosting.co.za> Benjamin Peterson added the comment: 987 is indeed missing. ---------- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 21:55:59 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 29 Sep 2014 19:55:59 +0000 Subject: [issue19569] Use __attribute__((deprecated)) to warn usage of deprecated functions and macros In-Reply-To: <1384348276.8.0.185765824651.issue19569@psf.upfronthosting.co.za> Message-ID: <1412020559.93.0.572019732299.issue19569@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 22:04:53 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 29 Sep 2014 20:04:53 +0000 Subject: [issue19569] Use __attribute__((deprecated)) to warn usage of deprecated functions and macros In-Reply-To: <1384348276.8.0.185765824651.issue19569@psf.upfronthosting.co.za> Message-ID: <1412021093.54.0.574395557269.issue19569@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: There is already Py_DEPRECATED in Include/pyport.h: #if defined(__GNUC__) && ((__GNUC__ >= 4) || \ (__GNUC__ == 3) && (__GNUC_MINOR__ >= 1)) #define Py_DEPRECATED(VERSION_UNUSED) __attribute__((__deprecated__)) #else #define Py_DEPRECATED(VERSION_UNUSED) #endif You can add this before '#else': #elif defined(_MSC_VER) && _MSC_VER >= 1300 #define Py_DEPRECATED(VERSION_UNUSED) __declspec(deprecated) Py_DEPRECATED is not used since Python 3.0 (it is still used in 2.7). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 22:12:22 2014 From: report at bugs.python.org (Zachary Ware) Date: Mon, 29 Sep 2014 20:12:22 +0000 Subject: [issue1565509] Repair or Change installation error Message-ID: <1412021542.38.0.523369566401.issue1565509@psf.upfronthosting.co.za> Zachary Ware added the comment: Steve Dower wrote: > I vote to close. +1, and done. ---------- assignee: loewis -> resolution: -> third party stage: test needed -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 22:15:30 2014 From: report at bugs.python.org (Steven D'Aprano) Date: Mon, 29 Sep 2014 20:15:30 +0000 Subject: [issue22515] Implement partial order on Counter In-Reply-To: <1412019201.2.0.639073460867.issue22515@psf.upfronthosting.co.za> Message-ID: <20140929201523.GT19757@ando.pearwood.info> Steven D'Aprano added the comment: On Mon, Sep 29, 2014 at 07:33:21PM +0000, Ram Rachum wrote: > I suggest implementing `Counter.__lt__` which will be a partial order, > similarly to `set.__lt__`. Since Counter is described as a multiset, this sounds reasonable to me. ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 22:15:38 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 29 Sep 2014 20:15:38 +0000 Subject: [issue22437] re module: number of named groups is limited to 100 max In-Reply-To: <1411061982.07.0.646375842297.issue22437@psf.upfronthosting.co.za> Message-ID: <1412021738.34.0.704578719684.issue22437@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Antoine for your review. To avoid discrepancy between re and regex (and other engines), I have committed only a part of dynamic patch, without adding support of backreferences with index over 99. It is unlikely to achieve this limit in hand written regular expression, and in generated regular expression you can use named groups. I found that backreference syntax is one of most discrepant thing in regular expressions. There are at least 8 different variants (\N, \gN, \g, \g{N}, \k, \k'N', \k{N}, (?P=N)), and \g in Perl have different meaning. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 22:16:38 2014 From: report at bugs.python.org (Zachary Ware) Date: Mon, 29 Sep 2014 20:16:38 +0000 Subject: [issue10007] Visual C++ cannot build _ssl and _hashlib if newer OpenSSL is placed in $(dist) directory (PCBuild) In-Reply-To: <1285944430.56.0.132893198817.issue10007@psf.upfronthosting.co.za> Message-ID: <1412021798.92.0.84201791485.issue10007@psf.upfronthosting.co.za> Zachary Ware added the comment: PCbuild/build_ssl.py in 2.7 and 3.4 look through pyproject.(vs)props for the openssl dir, and 3.5 no longer uses build_ssl.py in the regular build process, so this is in fact out of date. ---------- assignee: -> zach.ware resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 22:24:23 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 29 Sep 2014 20:24:23 +0000 Subject: [issue22515] Implement partial order on Counter In-Reply-To: <1412019201.2.0.639073460867.issue22515@psf.upfronthosting.co.za> Message-ID: <1412022263.95.0.926438274546.issue22515@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What should be result of following operations? Counter({'a': 0}) < Counter({}) Counter({}) < Counter({'a': 0}) Counter({'a': -1}) < Counter({}) Counter({}) < Counter({'a': -1}) ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 22:26:45 2014 From: report at bugs.python.org (Ram Rachum) Date: Mon, 29 Sep 2014 20:26:45 +0000 Subject: [issue22515] Implement partial order on Counter In-Reply-To: <1412019201.2.0.639073460867.issue22515@psf.upfronthosting.co.za> Message-ID: <1412022405.87.0.207700872307.issue22515@psf.upfronthosting.co.za> Ram Rachum added the comment: I suggest they be ignored like in `elements`. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 22:30:54 2014 From: report at bugs.python.org (Ram Rachum) Date: Mon, 29 Sep 2014 20:30:54 +0000 Subject: [issue22515] Implement partial order on Counter In-Reply-To: <1412019201.2.0.639073460867.issue22515@psf.upfronthosting.co.za> Message-ID: <1412022654.77.0.327853717224.issue22515@psf.upfronthosting.co.za> Ram Rachum added the comment: (I mean, the non-positive values should be ignored.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 22:33:12 2014 From: report at bugs.python.org (Francis MB) Date: Mon, 29 Sep 2014 20:33:12 +0000 Subject: [issue22512] 'test_distutils.test_bdist_rpm' causes creation of directory '.rpmdb' on home dir In-Reply-To: <1411939601.45.0.729692387398.issue22512@psf.upfronthosting.co.za> Message-ID: <1412022792.83.0.102925973698.issue22512@psf.upfronthosting.co.za> Francis MB added the comment: Why is test.support.EnvironmentVarGuard preferable over distutils.test.support.EnvironGuard (with this one I'm not getting the warnings below)? If I change the patch to (not so different (?) as in other tests using EnvironmentVarGuard): $hg diff diff -r 2b212a8186e0 Lib/distutils/tests/test_bdist_rpm.py --- a/Lib/distutils/tests/test_bdist_rpm.py Mon Sep 29 11:25:00 2014 -0400 +++ b/Lib/distutils/tests/test_bdist_rpm.py Mon Sep 29 21:11:25 2014 +0200 @@ -5,7 +5,7 @@ import os import tempfile import shutil -from test.support import run_unittest +from test.support import run_unittest, EnvironmentVarGuard from distutils.core import Distribution from distutils.command.bdist_rpm import bdist_rpm @@ -36,8 +36,11 @@ super(BuildRpmTestCase, self).setUp() self.old_location = os.getcwd() self.old_sys_argv = sys.argv, sys.argv[:] + self.env = EnvironmentVarGuard() def tearDown(self): + self.env.__exit__() + del self.env os.chdir(self.old_location) sys.argv = self.old_sys_argv[0] sys.argv[:] = self.old_sys_argv[1] @@ -54,6 +57,7 @@ def test_quiet(self): # let's create a package tmp_dir = self.mkdtemp() + self.env['HOME'] = tmp_dir # to confine dir '.rpmdb' creation pkg_dir = os.path.join(tmp_dir, 'foo') os.mkdir(pkg_dir) self.write_file((pkg_dir, 'setup.py'), SETUP_PY) @@ -96,6 +100,7 @@ def test_no_optimize_flag(self): # let's create a package that brakes bdist_rpm tmp_dir = self.mkdtemp() + self.env['HOME'] = tmp_dir # to confine dir '.rpmdb' creation pkg_dir = os.path.join(tmp_dir, 'foo') os.mkdir(pkg_dir) self.write_file((pkg_dir, 'setup.py'), SETUP_PY) I get the message: [102/390] test_distutils Warning -- threading._dangling was modified by test_distutils Using EnvironmentVarGuard as context manager gives the same warning. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 22:35:26 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 29 Sep 2014 20:35:26 +0000 Subject: [issue22515] Implement partial order on Counter In-Reply-To: <1412019201.2.0.639073460867.issue22515@psf.upfronthosting.co.za> Message-ID: <1412022926.7.0.368845040116.issue22515@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There is other definition of the <= operator for sets: "A <= B" is equivalent to "len(A - B) == 0". Extending to Counter this can mean "len(A.subtract(B).elements()) == 0". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 22:36:47 2014 From: report at bugs.python.org (J. Morton) Date: Mon, 29 Sep 2014 20:36:47 +0000 Subject: [issue22516] Windows Installer won't - even when using "just for me"option Message-ID: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za> New submission from J. Morton: Could not install 3.4.1 on Windows 7 Enterprise SP1 using the .MSI installer, even when using the ?just for me? option (our IM department has not given us the necessary rights to run the .MSI installer even in this mode). Please consider providing 3.4.1 (and all future releases) in a non ?.MSI? file so that ?admin? rights are not needed to do the install (a simple ZIP file? something similar to www.portableapps.com ?). Or as a source ?tarball? for Windows machines ? ideally one that is independent of compiler vendor (compileable using gcc, etc. instead of MSVC). ---------- components: Installation messages: 227832 nosy: NaCl, tim.golden priority: normal severity: normal status: open title: Windows Installer won't - even when using "just for me"option versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 22:42:56 2014 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 29 Sep 2014 20:42:56 +0000 Subject: [issue22516] Windows Installer won't - even when using "just for me"option In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za> Message-ID: <1412023376.94.0.11878802699.issue22516@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- components: +Windows nosy: +steve.dower, terry.reedy, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 22:43:06 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 29 Sep 2014 20:43:06 +0000 Subject: [issue22512] 'test_distutils.test_bdist_rpm' causes creation of directory '.rpmdb' on home dir In-Reply-To: <1411939601.45.0.729692387398.issue22512@psf.upfronthosting.co.za> Message-ID: <1412023386.98.0.254917396347.issue22512@psf.upfronthosting.co.za> R. David Murray added the comment: Sorry, I'm not that familiar with distutils and did not realize it had stuff for environment protection in the setUp/tearDown. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 22:48:18 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 29 Sep 2014 20:48:18 +0000 Subject: [issue22516] Windows Installer won't - even when using "just for me"option In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za> Message-ID: <1412023698.93.0.35965325334.issue22516@psf.upfronthosting.co.za> R. David Murray added the comment: The source tarball is the source tarball. You can built python yourself, but it does require MSVC. There are issues in this tracker about supporting other compilers, but for various reasons (mostly having to do with this being a volunteer community driven project) they have not gotten anywhere close to good enough for us to officially support it. For the 'no privileges' install question, I defer to Steve; otherwise I'd just close the issue. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 22:59:02 2014 From: report at bugs.python.org (paul) Date: Mon, 29 Sep 2014 20:59:02 +0000 Subject: [issue22517] BufferedRWpair doesn't clear weakrefs Message-ID: <1412024342.18.0.174047226004.issue22517@psf.upfronthosting.co.za> New submission from paul: # static void # bufferedrwpair_dealloc(rwpair *self) # { # _PyObject_GC_UNTRACK(self); # Py_CLEAR(self->reader); # Py_CLEAR(self->writer); # Py_CLEAR(self->dict); # Py_TYPE(self)->tp_free((PyObject *) self); # } # # Weakrefs to this object contain stale pointer after BufferedRWPair is freed. ---------- files: poc_brwpair_weakref.py messages: 227835 nosy: pkt priority: normal severity: normal status: open title: BufferedRWpair doesn't clear weakrefs type: crash versions: Python 3.4 Added file: http://bugs.python.org/file36753/poc_brwpair_weakref.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 23:00:33 2014 From: report at bugs.python.org (Steve Dower) Date: Mon, 29 Sep 2014 21:00:33 +0000 Subject: [issue22516] Windows Installer won't - even when using "just for me"option In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za> Message-ID: <1412024433.95.0.219647689455.issue22516@psf.upfronthosting.co.za> Steve Dower added the comment: The "just for me" option isn't really "just for me". I'll probably have a real option in 3.5, though it may still require admin rights. There's no reason sites like www.portableapps.com couldn't provide true per-user installers, and Continuum Analytics and Enthought both already do (as do others - I think Portable Python is fine, though not quite up to date). Python 3.4 probably won't be fixed. Python 3.5 might be. I don't need this issue to track it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 23:01:25 2014 From: report at bugs.python.org (paul) Date: Mon, 29 Sep 2014 21:01:25 +0000 Subject: [issue22518] integer overflow in encoding unicode Message-ID: <1412024485.39.0.908219343503.issue22518@psf.upfronthosting.co.za> New submission from paul: # static PyObject * # unicode_encode_ucs1(PyObject *unicode, # const char *errors, # unsigned int limit) # { # ... # while (pos < size) { # ... # case 4: /* xmlcharrefreplace */ # /* determine replacement size */ # for (i = collstart, repsize = 0; i < collend; ++i) { # Py_UCS4 ch = PyUnicode_READ(kind, data, i); # ... # else if (ch < 100000) # 1 repsize += 2+5+1; # ... # } # 2 requiredsize = respos+repsize+(size-collend); # if (requiredsize > ressize) { # ... # if (_PyBytes_Resize(&res, requiredsize)) # ... # } # /* generate replacement */ # for (i = collstart; i < collend; ++i) { # 3 str += sprintf(str, "&#%d;", PyUnicode_READ(kind, data, i)); # } # # 1. ch=0xffff<100000, so repsize = (number of unicode chars in string)*8 # =2^29*2^3=2^32 == 0 (mod 2^32) # 2. respos==0, collend==0, so requiredsize=repsize==0, so the destination buffer # isn't resized # 3. overwrite ---------- files: poc_encode_latin1.py messages: 227837 nosy: pkt priority: normal severity: normal status: open title: integer overflow in encoding unicode type: crash versions: Python 3.4 Added file: http://bugs.python.org/file36754/poc_encode_latin1.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 23:03:05 2014 From: report at bugs.python.org (paul) Date: Mon, 29 Sep 2014 21:03:05 +0000 Subject: [issue22519] integer overflow in computing byte's object representation Message-ID: <1412024585.59.0.0929794410107.issue22519@psf.upfronthosting.co.za> New submission from paul: # PyBytes_Repr(PyObject *obj, int smartquotes) # { # PyBytesObject* op = (PyBytesObject*) obj; # 1 Py_ssize_t i, length = Py_SIZE(op); # size_t newsize, squotes, dquotes; # ... # # /* Compute size of output string */ # newsize = 3; /* b'' */ # s = (unsigned char*)op->ob_sval; # for (i = 0; i < length; i++) { # ... # default: # if (s[i] < ' ' || s[i] >= 0x7f) # 2 newsize += 4; /* \xHH */ # else # newsize++; # } # } # ... # 3 if (newsize > (PY_SSIZE_T_MAX - sizeof(PyUnicodeObject) - 1)) { # PyErr_SetString(PyExc_OverflowError, # "bytes object is too large to make repr"); # return NULL; # } # 4 v = PyUnicode_New(newsize, 127); # ... # *p++ = 'b', *p++ = quote; # for (i = 0; i < length; i++) { # ... # 5 *p++ = c; # } # *p++ = quote; # 6 assert(_PyUnicode_CheckConsistency(v, 1)); # return v; # } # # 1. length=2^30+1=1073741825 # 2. newsize=length*4+3=7 (overflow) # 3. check is inefficient, because newsize=7 # 4. allocated buffer is too small # 5. buffer overwrite # 6. this assert will likely fail, since there is a good chance the allocated # buffer is just before the huge one, so the huge one will overwrite itself. ---------- files: poc_repr_bytes.py messages: 227838 nosy: pkt priority: normal severity: normal status: open title: integer overflow in computing byte's object representation type: crash versions: Python 3.4 Added file: http://bugs.python.org/file36755/poc_repr_bytes.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 23:04:02 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 29 Sep 2014 21:04:02 +0000 Subject: [issue22516] Windows Installer won't - even when using "just for me"option In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za> Message-ID: <1412024642.37.0.727244290615.issue22516@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- resolution: -> later stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 23:04:19 2014 From: report at bugs.python.org (paul) Date: Mon, 29 Sep 2014 21:04:19 +0000 Subject: [issue22520] integer overflow in computing unicode's object representation Message-ID: <1412024659.14.0.152968090659.issue22520@psf.upfronthosting.co.za> New submission from paul: # unicode_repr(PyObject *unicode) # { # ... # 1 isize = PyUnicode_GET_LENGTH(unicode); # idata = PyUnicode_DATA(unicode); # # /* Compute length of output, quote characters, and # maximum character */ # osize = 0; # ... # for (i = 0; i < isize; i++) { # Py_UCS4 ch = PyUnicode_READ(ikind, idata, i); # switch (ch) { # ... # default: # /* Fast-path ASCII */ # if (ch < ' ' || ch == 0x7f) # 2 osize += 4; /* \xHH */ # ... # } # } # # ... # 3 repr = PyUnicode_New(osize, max); # ... # for (i = 0, o = 1; i < isize; i++) { # Py_UCS4 ch = PyUnicode_READ(ikind, idata, i); # ... # else { # 4 PyUnicode_WRITE(okind, odata, o++, ch); # } # } # } # } # /* Closing quote already added at the beginning */ # 5 assert(_PyUnicode_CheckConsistency(repr, 1)); # return repr; # } # # 1. isize=2^30+1 # 2. osize=isize*4=4 # 3. allocated buffer is too small # 4. heap overflow # 5. this assert will likely fail, since there is a good chance the allocated # buffer is just before the huge one, so the huge one will overwrite itself. ---------- files: poc_repr_unicode.py messages: 227839 nosy: pkt priority: normal severity: normal status: open title: integer overflow in computing unicode's object representation type: crash versions: Python 3.4 Added file: http://bugs.python.org/file36756/poc_repr_unicode.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 23:06:12 2014 From: report at bugs.python.org (Francis MB) Date: Mon, 29 Sep 2014 21:06:12 +0000 Subject: [issue22512] 'test_distutils.test_bdist_rpm' causes creation of directory '.rpmdb' on home dir In-Reply-To: <1411939601.45.0.729692387398.issue22512@psf.upfronthosting.co.za> Message-ID: <1412024772.84.0.479018394961.issue22512@psf.upfronthosting.co.za> Francis MB added the comment: No problem, but is the, 3 lines, patch ok? what are the next steps, if yes? Shouldn't be the issue status now 'patch review' or similar? Thanks in advance! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 23:07:48 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 29 Sep 2014 21:07:48 +0000 Subject: [issue22512] 'test_distutils.test_bdist_rpm' causes creation of directory '.rpmdb' on home dir In-Reply-To: <1411939601.45.0.729692387398.issue22512@psf.upfronthosting.co.za> Message-ID: <1412024868.47.0.0384796603853.issue22512@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, sorry I forgot to change the stage. ---------- stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 23:13:52 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 29 Sep 2014 21:13:52 +0000 Subject: [issue22517] BufferedRWpair doesn't clear weakrefs In-Reply-To: <1412024342.18.0.174047226004.issue22517@psf.upfronthosting.co.za> Message-ID: <1412025232.76.0.80465283567.issue22517@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +benjamin.peterson, pitrou, stutzbach versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 23:15:34 2014 From: report at bugs.python.org (Ethan Furman) Date: Mon, 29 Sep 2014 21:15:34 +0000 Subject: [issue22515] Implement partial order on Counter In-Reply-To: <1412019201.2.0.639073460867.issue22515@psf.upfronthosting.co.za> Message-ID: <1412025334.99.0.386008780637.issue22515@psf.upfronthosting.co.za> Ethan Furman added the comment: What would be the result of Counter({'a':1, 'b':2}) < Counter({'a':2, 'b':1}) ? ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 23:19:07 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 29 Sep 2014 21:19:07 +0000 Subject: [issue22518] integer overflow in encoding unicode In-Reply-To: <1412024485.39.0.908219343503.issue22518@psf.upfronthosting.co.za> Message-ID: <1412025547.4.0.0455198646551.issue22518@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Looks very similar to issue22470. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 23:20:59 2014 From: report at bugs.python.org (Ram Rachum) Date: Mon, 29 Sep 2014 21:20:59 +0000 Subject: [issue22515] Implement partial order on Counter In-Reply-To: <1412019201.2.0.639073460867.issue22515@psf.upfronthosting.co.za> Message-ID: <1412025659.95.0.190919007791.issue22515@psf.upfronthosting.co.za> Ram Rachum added the comment: False, like with sets. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 23:21:14 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 29 Sep 2014 21:21:14 +0000 Subject: [issue22515] Implement partial order on Counter In-Reply-To: <1412019201.2.0.639073460867.issue22515@psf.upfronthosting.co.za> Message-ID: <1412025674.78.0.915730099538.issue22515@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Ethan. I had a feeling that this wasn't well defined but I couldn't come up with an example :) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 29 23:24:53 2014 From: report at bugs.python.org (Ram Rachum) Date: Mon, 29 Sep 2014 21:24:53 +0000 Subject: [issue22515] Implement partial order on Counter In-Reply-To: <1412019201.2.0.639073460867.issue22515@psf.upfronthosting.co.za> Message-ID: <1412025893.96.0.0233931505655.issue22515@psf.upfronthosting.co.za> Ram Rachum added the comment: David, there's nothing here that isn't well defined. It's simply a partial order, not a total order. We have the same for sets. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 00:06:02 2014 From: report at bugs.python.org (Ethan Furman) Date: Mon, 29 Sep 2014 22:06:02 +0000 Subject: [issue22515] Implement partial order on Counter In-Reply-To: <1412019201.2.0.639073460867.issue22515@psf.upfronthosting.co.za> Message-ID: <1412028362.79.0.479883928365.issue22515@psf.upfronthosting.co.za> Ethan Furman added the comment: set's don't have values, and you are wanting to implement the partial ordering based on the values. (side-note: how does partial-ordering work for sets?) > That is, one counter will be considered smaller-or-equal to another if for any > item in the first counter, the second counter has an equal or bigger amount of > that item. According to your definition, my example should have returned True, which is clearly nonsensical. Even if you changed the definition to: For every item in the first counter, that item's value is less than the corresponding item in the second counter. You have situations like: Counter({'a':1, 'b':1}) < Counter({'a':2}) I just don't think there is one interpretation that is going to be correct most of the time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 00:16:19 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Mon, 29 Sep 2014 22:16:19 +0000 Subject: [issue22515] Implement partial order on Counter In-Reply-To: <1412019201.2.0.639073460867.issue22515@psf.upfronthosting.co.za> Message-ID: <1412028979.32.0.157356689599.issue22515@psf.upfronthosting.co.za> Changes by Josh Rosenberg : ---------- nosy: +josh.rosenberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 00:30:54 2014 From: report at bugs.python.org (Ram Rachum) Date: Mon, 29 Sep 2014 22:30:54 +0000 Subject: [issue22515] Implement partial order on Counter In-Reply-To: <1412019201.2.0.639073460867.issue22515@psf.upfronthosting.co.za> Message-ID: <1412029854.14.0.881220738533.issue22515@psf.upfronthosting.co.za> Ram Rachum added the comment: Ethan, I don't understand what the problem is. I also don't understand your side note question "how does partial-ordering work for sets?" I'm not sure what you're asking. >> That is, one counter will be considered smaller-or-equal to another if for any >> item in the first counter, the second counter has an equal or bigger amount of >> that item. > According to your definition, my example should have returned True, which is clearly nonsensical. In your example the first counter had `b` twice, while the second counter had it only once. So the result is `False`. This comes pretty directly from my definition, I'm not sure where the confusion is. Regarding your new example: Since `Counter` works like a `defaultdict`, the second counter has a zero quantity of `b`. So the answer is again `False`. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 00:32:58 2014 From: report at bugs.python.org (Ram Rachum) Date: Mon, 29 Sep 2014 22:32:58 +0000 Subject: [issue22515] Implement partial order on Counter In-Reply-To: <1412019201.2.0.639073460867.issue22515@psf.upfronthosting.co.za> Message-ID: <1412029978.68.0.428262232401.issue22515@psf.upfronthosting.co.za> Ram Rachum added the comment: To put it another way: In Python sets, `a <= b` iff `b` has everything that `a` has, and possibly more. I'm proposing the exact same definition for counters. True, the implementation might be different because sets are not dicts and don't have `.values()`, but that is just the implementation, which is not the important thing here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 00:36:39 2014 From: report at bugs.python.org (Ethan Furman) Date: Mon, 29 Sep 2014 22:36:39 +0000 Subject: [issue22515] Implement partial order on Counter In-Reply-To: <1412019201.2.0.639073460867.issue22515@psf.upfronthosting.co.za> Message-ID: <1412030199.5.0.505634697681.issue22515@psf.upfronthosting.co.za> Ethan Furman added the comment: That is certainly a better definition. If you carefully reread your original post you will see that you wrote something different ('any' instead of 'every'). Also, your OP uses '__lt__' but talks about 'less-than-or-equal -- somewhat confusing. ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 00:44:47 2014 From: report at bugs.python.org (Ram Rachum) Date: Mon, 29 Sep 2014 22:44:47 +0000 Subject: [issue22515] Implement partial order on Counter In-Reply-To: <1412019201.2.0.639073460867.issue22515@psf.upfronthosting.co.za> Message-ID: <1412030687.85.0.534858587701.issue22515@psf.upfronthosting.co.za> Ram Rachum added the comment: You're right, sorry. I meant the mathematical "for any" which means "for every": https://en.wikipedia.org/wiki/List_of_mathematical_symbols (See "for any;") ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 00:51:03 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 29 Sep 2014 22:51:03 +0000 Subject: [issue22518] integer overflow in encoding unicode In-Reply-To: <1412024485.39.0.908219343503.issue22518@psf.upfronthosting.co.za> Message-ID: <1412031063.29.0.315882364548.issue22518@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 00:51:21 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 29 Sep 2014 22:51:21 +0000 Subject: [issue22518] integer overflow in encoding unicode In-Reply-To: <1412024485.39.0.908219343503.issue22518@psf.upfronthosting.co.za> Message-ID: <1412031081.0.0.0149035673327.issue22518@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 00:54:15 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 29 Sep 2014 22:54:15 +0000 Subject: [issue22515] Implement partial order on Counter In-Reply-To: <1412019201.2.0.639073460867.issue22515@psf.upfronthosting.co.za> Message-ID: <1412031255.62.0.541505261621.issue22515@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The request sounds ok to me. As in the corner case of negative values, it seems that Counter currently doesn't elide zero values, e.g.: >>> Counter({'a': 0}) == Counter({}) False Therefore, we should have: >>> Counter({'a': -1}) < Counter({'a': 0}) True but: >>> Counter({'a': -1}) < Counter({}) False (I must admit, the current semantics of Counter look a bit ad hoc and not terribly consistent... halfway between a regular mapping and a multiset) ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 00:55:13 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 29 Sep 2014 22:55:13 +0000 Subject: [issue22518] integer overflow in encoding unicode In-Reply-To: <1412024485.39.0.908219343503.issue22518@psf.upfronthosting.co.za> Message-ID: <20140929225508.23191.84774@mail.hg.python.org> Roundup Robot added the comment: New changeset b2e68274aa8e by Benjamin Peterson in branch '2.7': cleanup overflowing handling in unicode_decode_call_errorhandler and unicode_encode_ucs1 (closes #22518) https://hg.python.org/cpython/rev/b2e68274aa8e New changeset 3b7e93249700 by Benjamin Peterson in branch '2.7': add NEWS note for #22518 https://hg.python.org/cpython/rev/3b7e93249700 New changeset 3c67d19c624f by Benjamin Peterson in branch '3.3': cleanup overflowing handling in unicode_decode_call_errorhandler and unicode_encode_ucs1 (closes #22518) https://hg.python.org/cpython/rev/3c67d19c624f New changeset 88332ea4c140 by Benjamin Peterson in branch '3.3': NEWS issue for #22518 https://hg.python.org/cpython/rev/88332ea4c140 New changeset 7dab27fffff2 by Benjamin Peterson in branch '3.4': merge 3.3 (closes #22518) https://hg.python.org/cpython/rev/7dab27fffff2 New changeset f86fde20e9ce by Benjamin Peterson in branch 'default': merge 3.4 (closes #22518) https://hg.python.org/cpython/rev/f86fde20e9ce ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 00:57:00 2014 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 29 Sep 2014 22:57:00 +0000 Subject: [issue8350] Document lack of support for keyword arguments in C functions In-Reply-To: <1270764159.26.0.287104770145.issue8350@psf.upfronthosting.co.za> Message-ID: <1412031420.09.0.236769702026.issue8350@psf.upfronthosting.co.za> Mark Lawrence added the comment: Has the Argument Clinic had an impact on this or is that a different kettle of fish? ---------- nosy: +BreamoreBoy versions: +Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 00:58:16 2014 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 29 Sep 2014 22:58:16 +0000 Subject: [issue10789] Lock.acquire documentation is misleading In-Reply-To: <1293644478.45.0.40426107256.issue10789@psf.upfronthosting.co.za> Message-ID: <1412031496.34.0.585730926647.issue10789@psf.upfronthosting.co.za> Mark Lawrence added the comment: Has the Argument Clinic had an impact on this or is that a different kettle of fish? ---------- nosy: +BreamoreBoy versions: +Python 3.4, Python 3.5 -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 01:11:17 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 29 Sep 2014 23:11:17 +0000 Subject: [issue22519] integer overflow in computing byte's object representation In-Reply-To: <1412024585.59.0.0929794410107.issue22519@psf.upfronthosting.co.za> Message-ID: <20140929231112.23191.43838@mail.hg.python.org> Roundup Robot added the comment: New changeset d9cd11eda152 by Benjamin Peterson in branch '2.7': fix overflow checking in PyString_Repr (closes #22519) https://hg.python.org/cpython/rev/d9cd11eda152 New changeset f5c662a7f7e6 by Benjamin Peterson in branch '3.3': fix overflow checking in PyBytes_Repr (closes #22519) https://hg.python.org/cpython/rev/f5c662a7f7e6 New changeset ed31cdf11ac2 by Benjamin Peterson in branch '3.4': merge 3.3 (closes #22519) https://hg.python.org/cpython/rev/ed31cdf11ac2 New changeset 0ddc5fc5f395 by Benjamin Peterson in branch 'default': merge 3.4 (#22519) https://hg.python.org/cpython/rev/0ddc5fc5f395 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 01:13:24 2014 From: report at bugs.python.org (Ram Rachum) Date: Mon, 29 Sep 2014 23:13:24 +0000 Subject: [issue22515] Implement partial order on Counter In-Reply-To: <1412019201.2.0.639073460867.issue22515@psf.upfronthosting.co.za> Message-ID: <1412032404.33.0.647788645549.issue22515@psf.upfronthosting.co.za> Ram Rachum added the comment: Shall I write a patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 01:17:52 2014 From: report at bugs.python.org (Ethan Furman) Date: Mon, 29 Sep 2014 23:17:52 +0000 Subject: [issue22515] Implement partial order on Counter In-Reply-To: <1412019201.2.0.639073460867.issue22515@psf.upfronthosting.co.za> Message-ID: <1412032672.31.0.132245090976.issue22515@psf.upfronthosting.co.za> Ethan Furman added the comment: I think the final call is Raymond's (whether to accept the patch), but go ahead. Worst case scenario is you'll have your own thoroughly tested PartiallyOrderedCounter you can use in your own code. :) ---------- nosy: +rhettinger type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 01:18:37 2014 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 29 Sep 2014 23:18:37 +0000 Subject: [issue10938] Provide links to system specific strftime/ptime docs In-Reply-To: <1295378779.48.0.643087757109.issue10938@psf.upfronthosting.co.za> Message-ID: <1412032717.83.0.19073522864.issue10938@psf.upfronthosting.co.za> Mark Lawrence added the comment: @Humberto could you provide a patch for this? ---------- nosy: +BreamoreBoy versions: +Python 3.4, Python 3.5 -Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 01:20:57 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 29 Sep 2014 23:20:57 +0000 Subject: [issue22517] BufferedRWpair doesn't clear weakrefs In-Reply-To: <1412024342.18.0.174047226004.issue22517@psf.upfronthosting.co.za> Message-ID: <1412032857.21.0.00771229020716.issue22517@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 01:21:05 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 29 Sep 2014 23:21:05 +0000 Subject: [issue22518] integer overflow in encoding unicode In-Reply-To: <1412024485.39.0.908219343503.issue22518@psf.upfronthosting.co.za> Message-ID: <1412032865.54.0.394407898003.issue22518@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 01:21:12 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 29 Sep 2014 23:21:12 +0000 Subject: [issue22519] integer overflow in computing byte's object representation In-Reply-To: <1412024585.59.0.0929794410107.issue22519@psf.upfronthosting.co.za> Message-ID: <1412032872.93.0.252017188968.issue22519@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 01:21:21 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 29 Sep 2014 23:21:21 +0000 Subject: [issue22520] integer overflow in computing unicode's object representation In-Reply-To: <1412024659.14.0.152968090659.issue22520@psf.upfronthosting.co.za> Message-ID: <1412032881.26.0.70052723807.issue22520@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 01:21:30 2014 From: report at bugs.python.org (Ram Rachum) Date: Mon, 29 Sep 2014 23:21:30 +0000 Subject: [issue22515] Implement partial order on Counter In-Reply-To: <1412019201.2.0.639073460867.issue22515@psf.upfronthosting.co.za> Message-ID: <1412032890.29.0.412099376206.issue22515@psf.upfronthosting.co.za> Ram Rachum added the comment: If that's the case I'd prefer Raymond to first say whether this feature is generally welcome before spending my time on making a patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 01:25:09 2014 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 29 Sep 2014 23:25:09 +0000 Subject: [issue10937] WinPE 64 bit execution results with errors In-Reply-To: <1295378619.67.0.475043721406.issue10937@psf.upfronthosting.co.za> Message-ID: <1412033109.91.0.890568591362.issue10937@psf.upfronthosting.co.za> Mark Lawrence added the comment: In msg126496 MVL says "I'll also point out that this is not a bug: copying over an installation is not supposed to work" so can we close this as "not a bug"? ---------- nosy: +BreamoreBoy, steve.dower, tim.golden, zach.ware -brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 01:28:32 2014 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 29 Sep 2014 23:28:32 +0000 Subject: [issue2399] Patches for Tools/msi In-Reply-To: <1205858738.04.0.681248681608.issue2399@psf.upfronthosting.co.za> Message-ID: <1412033312.26.0.749387861098.issue2399@psf.upfronthosting.co.za> Mark Lawrence added the comment: Has this issue been overtaken by events? ---------- nosy: +BreamoreBoy, steve.dower, tim.golden, zach.ware versions: +Python 3.5 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 01:30:32 2014 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 29 Sep 2014 23:30:32 +0000 Subject: [issue10531] write tilted text in turtle In-Reply-To: <1290702974.67.0.695196946667.issue10531@psf.upfronthosting.co.za> Message-ID: <1412033432.69.0.0868664574485.issue10531@psf.upfronthosting.co.za> Mark Lawrence added the comment: Could this now be implemented in the turtle module? ---------- nosy: +BreamoreBoy, terry.reedy versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 01:31:14 2014 From: report at bugs.python.org (Steve Dower) Date: Mon, 29 Sep 2014 23:31:14 +0000 Subject: [issue2399] Patches for Tools/msi In-Reply-To: <1205858738.04.0.681248681608.issue2399@psf.upfronthosting.co.za> Message-ID: <1412033474.17.0.527904677913.issue2399@psf.upfronthosting.co.za> Steve Dower added the comment: I think they've all been fixed anyway, but yeah, they're not going to be relevant with my new installer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 01:37:48 2014 From: report at bugs.python.org (Brunel) Date: Mon, 29 Sep 2014 23:37:48 +0000 Subject: [issue22422] IDLE closes all when in dropdown menu In-Reply-To: <1410853910.37.0.784487772035.issue22422@psf.upfronthosting.co.za> Message-ID: <1412033868.9.0.336962304787.issue22422@psf.upfronthosting.co.za> Changes by Brunel : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 03:54:57 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 30 Sep 2014 01:54:57 +0000 Subject: [issue16662] load_tests not invoked in package/__init__.py In-Reply-To: <1355217291.85.0.41912767842.issue16662@psf.upfronthosting.co.za> Message-ID: <20140930015455.86177.30642@mail.hg.python.org> Roundup Robot added the comment: New changeset 090dc85f4226 by Benjamin Peterson in branch 'default': fix windows tests (#16662) https://hg.python.org/cpython/rev/090dc85f4226 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 04:49:43 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 30 Sep 2014 02:49:43 +0000 Subject: [issue22517] BufferedRWpair doesn't clear weakrefs In-Reply-To: <1412024342.18.0.174047226004.issue22517@psf.upfronthosting.co.za> Message-ID: <20140930024940.86183.96029@mail.hg.python.org> Roundup Robot added the comment: New changeset 9b4673d7b046 by Benjamin Peterson in branch '2.7': clear BufferedRWPair weakrefs on deallocation (closes #22517) https://hg.python.org/cpython/rev/9b4673d7b046 New changeset e834b32f0422 by Benjamin Peterson in branch '3.3': clear BufferedRWPair weakrefs on deallocation (closes #22517) https://hg.python.org/cpython/rev/e834b32f0422 New changeset e54da75100f6 by Benjamin Peterson in branch '3.4': merge 3.3 (#22517) https://hg.python.org/cpython/rev/e54da75100f6 New changeset a2add97e28b9 by Benjamin Peterson in branch 'default': merge 3.4 (#22517) https://hg.python.org/cpython/rev/a2add97e28b9 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 05:02:43 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 30 Sep 2014 03:02:43 +0000 Subject: [issue22520] integer overflow in computing unicode's object representation In-Reply-To: <1412024659.14.0.152968090659.issue22520@psf.upfronthosting.co.za> Message-ID: <1412046163.12.0.731356095361.issue22520@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- versions: +Python 3.3, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 05:03:32 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 30 Sep 2014 03:03:32 +0000 Subject: [issue22520] integer overflow in computing unicode's object representation In-Reply-To: <1412024659.14.0.152968090659.issue22520@psf.upfronthosting.co.za> Message-ID: <20140930030307.23205.28226@mail.hg.python.org> Roundup Robot added the comment: New changeset 8ba7e5f43952 by Benjamin Peterson in branch '3.3': prevent overflow in unicode_repr (closes #22520) https://hg.python.org/cpython/rev/8ba7e5f43952 New changeset 6f54dfa675eb by Benjamin Peterson in branch '3.4': merge 3.3 (#22520) https://hg.python.org/cpython/rev/6f54dfa675eb New changeset 245d9679cd5b by Benjamin Peterson in branch 'default': merge 3.4 (#22520) https://hg.python.org/cpython/rev/245d9679cd5b ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 06:42:32 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 30 Sep 2014 04:42:32 +0000 Subject: [issue2399] Patches for Tools/msi In-Reply-To: <1205858738.04.0.681248681608.issue2399@psf.upfronthosting.co.za> Message-ID: <1412052152.82.0.753681059259.issue2399@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 07:03:57 2014 From: report at bugs.python.org (Tim Golden) Date: Tue, 30 Sep 2014 05:03:57 +0000 Subject: [issue10937] WinPE 64 bit execution results with errors In-Reply-To: <1295378619.67.0.475043721406.issue10937@psf.upfronthosting.co.za> Message-ID: <1412053437.22.0.565399520517.issue10937@psf.upfronthosting.co.za> Changes by Tim Golden : ---------- resolution: -> not a bug stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 07:50:15 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 30 Sep 2014 05:50:15 +0000 Subject: [issue22422] IDLE closes all when in dropdown menu In-Reply-To: <1410853910.37.0.784487772035.issue22422@psf.upfronthosting.co.za> Message-ID: <1412056215.16.0.394382522083.issue22422@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- resolution: -> not a bug stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 08:34:37 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 30 Sep 2014 06:34:37 +0000 Subject: [issue22470] Possible integer overflow in error handlers In-Reply-To: <1411493751.43.0.689535434801.issue22470@psf.upfronthosting.co.za> Message-ID: <1412058877.23.0.627842880334.issue22470@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 08:35:51 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 30 Sep 2014 06:35:51 +0000 Subject: [issue22286] Allow backslashreplace error handler to be used on input In-Reply-To: <1409136620.65.0.397738586583.issue22286@psf.upfronthosting.co.za> Message-ID: <1412058951.04.0.045822867903.issue22286@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 08:37:15 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 30 Sep 2014 06:37:15 +0000 Subject: [issue22517] BufferedRWpair doesn't clear weakrefs In-Reply-To: <1412024342.18.0.174047226004.issue22517@psf.upfronthosting.co.za> Message-ID: <1412059035.61.0.46765994907.issue22517@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- versions: +Python 3.3, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 08:37:51 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 30 Sep 2014 06:37:51 +0000 Subject: [issue22519] integer overflow in computing byte's object representation In-Reply-To: <1412024585.59.0.0929794410107.issue22519@psf.upfronthosting.co.za> Message-ID: <1412059071.7.0.689231187159.issue22519@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- versions: +Python 2.7, Python 3.3, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 09:43:27 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 30 Sep 2014 07:43:27 +0000 Subject: [issue22207] Test for integer overflow on Py_ssize_t: explicitly cast to size_t In-Reply-To: <1408140199.72.0.115939936455.issue22207@psf.upfronthosting.co.za> Message-ID: <1412063007.92.0.193588073386.issue22207@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Gregory just has committed an equivalent of unicode_2.patch in a404bf4db6a6. ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 09:52:16 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 30 Sep 2014 07:52:16 +0000 Subject: [issue22207] Test for integer overflow on Py_ssize_t: explicitly cast to size_t In-Reply-To: <1408140199.72.0.115939936455.issue22207@psf.upfronthosting.co.za> Message-ID: <1412063536.56.0.322692001021.issue22207@psf.upfronthosting.co.za> Gregory P. Smith added the comment: modify it as you see fit, i hadn't noticed this issue; just the warnings. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 10:12:15 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 30 Sep 2014 08:12:15 +0000 Subject: [issue22207] Test for integer overflow on Py_ssize_t: explicitly cast to size_t In-Reply-To: <1412063536.56.0.322692001021.issue22207@psf.upfronthosting.co.za> Message-ID: <1913213.ZQfXc74H0R@raxxla> Serhiy Storchaka added the comment: Yes, these warning annoyed me too. But Victor's patch is purposed to check input data of public C API functions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 10:29:59 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 30 Sep 2014 08:29:59 +0000 Subject: [issue22207] Test for integer overflow on Py_ssize_t: explicitly cast to size_t In-Reply-To: <1408140199.72.0.115939936455.issue22207@psf.upfronthosting.co.za> Message-ID: <1412065799.43.0.715156337392.issue22207@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is original Victor's patch synchronized with the tip. ---------- Added file: http://bugs.python.org/file36757/issue22207_unicode_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 11:23:14 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 30 Sep 2014 09:23:14 +0000 Subject: [issue4093] add gc/memory management tests to pybench In-Reply-To: <1223583671.55.0.378027083511.issue4093@psf.upfronthosting.co.za> Message-ID: <1412068994.52.0.379733212538.issue4093@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: I think it's better to keep pybench speed performance oriented and rather use a new tool for memory performance tests. I've recently done a lightning talk at PyCon UK on the subject and found the current tools we have for memory testing a bit underdeveloped: http://www.egenix.com/library/presentations/PyCon-UK-2014-When-performance-matters/ As s result, I wrote some support helpers for this, which can be found in perftools.py on: https://github.com/egenix/when-performance-matters Perhaps this will some day turn into a pymembench :-) For now, I'm closing the ticket. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 11:43:41 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 30 Sep 2014 09:43:41 +0000 Subject: [issue22207] Test for integer overflow on Py_ssize_t: explicitly cast to size_t In-Reply-To: <1408140199.72.0.115939936455.issue22207@psf.upfronthosting.co.za> Message-ID: <1412070221.76.0.675060859681.issue22207@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I have reviewed the patch and found only few checks which looks good to me. Also I found two possible overflows (not fixed by the patch). All other changes looks redundant to me and just churn a code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 12:13:30 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 30 Sep 2014 10:13:30 +0000 Subject: [issue22448] call_at/call_later with Timer cancellation can result in (practically) unbounded memory usage. In-Reply-To: <1411172040.41.0.974691283228.issue22448@psf.upfronthosting.co.za> Message-ID: <1412072010.6.0.717103962211.issue22448@psf.upfronthosting.co.za> STINNER Victor added the comment: Sorry, I'm coming later after the review and the commit, but I worry about performances of _run_once() since it's the core of asyncio. Yury proposed to only iterate once on self._scheduled when removing delayed calls, and I have the same concern. Here is a patch which change _run_once() to only iterate once. IMO the change is obvious, the current iterates twice and makes the same check twice (check the _cancelled attribute of handles). ---------- keywords: +patch resolution: fixed -> status: closed -> open Added file: http://bugs.python.org/file36758/asyncio_remove_delayed.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 12:36:20 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 30 Sep 2014 10:36:20 +0000 Subject: [issue22396] AIX posix_fadvise and posix_fallocate In-Reply-To: <1410546003.27.0.984640019214.issue22396@psf.upfronthosting.co.za> Message-ID: <20140930103612.23209.7501@mail.hg.python.org> Roundup Robot added the comment: New changeset 8e5e19b3cd4e by Victor Stinner in branch '3.4': Issue #22396: On 32-bit AIX platform, don't expose os.posix_fadvise() nor https://hg.python.org/cpython/rev/8e5e19b3cd4e New changeset 5ade1061fa3d by Victor Stinner in branch 'default': (Merge 3.4) Issue #22396: On 32-bit AIX platform, don't expose https://hg.python.org/cpython/rev/5ade1061fa3d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 12:41:09 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 30 Sep 2014 10:41:09 +0000 Subject: [issue22396] AIX posix_fadvise and posix_fallocate In-Reply-To: <1410546003.27.0.984640019214.issue22396@psf.upfronthosting.co.za> Message-ID: <1412073669.48.0.149714687942.issue22396@psf.upfronthosting.co.za> STINNER Victor added the comment: > Or can we simply keep the function and skip the test? Usually, we prefer to not provide the function in Python if it is known to be broken. Other examples: - HAVE_BROKEN_POLL: don't declare select.poll() - HAVE_BROKEN_PTHREAD_SIGMASK: don't declare signal.pthread_sigmask() There are also HAVE_BROKEN_NICE and HAVE_BROKEN_UNSETENV. Sorry, I'm too lazy to hack configure.ac, so I used a simple #ifdef in Modules/posixmodule.c to define "POSIX_FADVISE_AIX_BUG". If you feel more confortable with autotools, don't hesitate to propose a better patch :-) I consider that the issue is now fixed. @David: You should check with IBM why they don't fix the issue. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 12:57:16 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 30 Sep 2014 10:57:16 +0000 Subject: [issue5309] distutils doesn't parallelize extension module compilation In-Reply-To: <1235007592.93.0.0598331575131.issue5309@psf.upfronthosting.co.za> Message-ID: <1412074636.66.0.375750763433.issue5309@psf.upfronthosting.co.za> STINNER Victor added the comment: It looks like compilation of Python 3.5 fails on FreeBSD 6.4 because of the changeset bbe57429eba0a9ec21fb0f1178f409f1bba44c22: http://buildbot.python.org/all/builders/x86%20FreeBSD%206.4%203.x/builds/5061 Compile log: --- building '_ctypes' extension creating build/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi creating build/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src creating build/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src/x86 gcc -pthread -fPIC -fno-strict-aliasing -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -Ibuild/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/libffi/include -Ibuild/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/libffi -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src -I./Include -I. -IInclude -I/usr/local/include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build -c /usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/_ctypes.c -o build/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/_ctypes.o -Wall -fexceptions gcc -pthread -fPIC -fno-strict-aliasing -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -Ibuild/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/libffi/include -Ibuild/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/libffi -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src -I./Include -I. -IInclude -I/usr/local/include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build -c /usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/callbacks.c -o build/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/callbacks.o -Wall -fexceptions gcc -pthread -fPIC -fno-strict-aliasing -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -Ibuild/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/libffi/include -Ibuild/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/libffi -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src -I./Include -I. -IInclude -I/usr/local/include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build -c /usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/callproc.c -o build/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/callproc.o -Wall -fexceptions /usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/callproc.c: In function `py_dl_open': /usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/callproc.c:1336: warning: initialization discards qualifiers from pointer target type gcc -pthread -fPIC -fno-strict-aliasing -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -Ibuild/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/libffi/include -Ibuild/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/libffi -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src -I./Include -I. -IInclude -I/usr/local/include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build -c /usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/stgdict.c -o build/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/stgdict.o -Wall -fexceptions gcc -pthread -fPIC -fno-strict-aliasing -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -Ibuild/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/libffi/include -Ibuild/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/libffi -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src -I./Include -I. -IInclude -I/usr/local/include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build -c /usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/cfield.c -o build/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/cfield.o -Wall -fexceptions gcc -pthread -fPIC -fno-strict-aliasing -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -Ibuild/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/libffi/include -Ibuild/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/libffi -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src -I./Include -I. -IInclude -I/usr/local/include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build -c /usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src/prep_cif.c -o build/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src/prep_cif.o -Wall -fexceptions gcc -pthread -fPIC -fno-strict-aliasing -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -Ibuild/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/libffi/include -Ibuild/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/libffi -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src -I./Include -I. -IInclude -I/usr/local/include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build -c /usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src/closures.c -o build/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src/closures.o -Wall -fexceptions gcc -pthread -fPIC -fno-strict-aliasing -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -Ibuild/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/libffi/include -Ibuild/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/libffi -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src -I./Include -I. -IInclude -I/usr/local/include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build -c /usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src/x86/ffi.c -o build/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src/x86/ffi.o -Wall -fexceptions gcc -pthread -fPIC -fno-strict-aliasing -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -Ibuild/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/libffi/include -Ibuild/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/libffi -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src -I./Include -I. -IInclude -I/usr/local/include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build -c /usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src/x86/freebsd.S -o build/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src/x86/freebsd.o -Wall -fexceptions gcc -pthread -shared build/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/_ctypes.o build/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/callbacks.o build/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/callproc.o build/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/stgdict.o build/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/cfield.o build/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src/prep_cif.o build/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src/closures.o build/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src/x86/freebsd.o -L/usr/local/lib -o build/lib.freebsd-6.4-RELEASE-i386-3.5-pydebug/_ctypes.so *** WARNING: renaming "_ssl" since importing it failed: build/lib.freebsd-6.4-RELEASE-i386-3.5-pydebug/_ssl.so: Undefined symbol "X509_check_ca" *** WARNING: renaming "_ctypes" since importing it failed: build/lib.freebsd-6.4-RELEASE-i386-3.5-pydebug/_ctypes.so: Undefined symbol "ffi_call_win32" error: [Errno 2] No such file or directory: 'build/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/_ctypes.o' *** Error code 1 --- Before: --- building '_ctypes' extension gcc -pthread -fPIC -fno-strict-aliasing -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -Ibuild/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/libffi/include -Ibuild/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/libffi -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src -I./Include -I. -IInclude -I/usr/local/include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build -c /usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/_ctypes.c -o build/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/_ctypes.o -Wall -fexceptions gcc -pthread -fPIC -fno-strict-aliasing -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -Ibuild/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/libffi/include -Ibuild/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/libffi -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src -I./Include -I. -IInclude -I/usr/local/include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build -c /usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/callbacks.c -o build/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/callbacks.o -Wall -fexceptions gcc -pthread -fPIC -fno-strict-aliasing -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -Ibuild/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/libffi/include -Ibuild/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/libffi -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src -I./Include -I. -IInclude -I/usr/local/include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build -c /usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/callproc.c -o build/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/callproc.o -Wall -fexceptions /usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/callproc.c: In function `py_dl_open': /usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/callproc.c:1336: warning: initialization discards qualifiers from pointer target type gcc -pthread -fPIC -fno-strict-aliasing -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -Ibuild/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/libffi/include -Ibuild/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/libffi -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src -I./Include -I. -IInclude -I/usr/local/include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build -c /usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/stgdict.c -o build/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/stgdict.o -Wall -fexceptions gcc -pthread -fPIC -fno-strict-aliasing -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -Ibuild/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/libffi/include -Ibuild/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/libffi -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src -I./Include -I. -IInclude -I/usr/local/include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build -c /usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/cfield.c -o build/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/cfield.o -Wall -fexceptions gcc -pthread -fPIC -fno-strict-aliasing -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -Ibuild/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/libffi/include -Ibuild/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/libffi -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src -I./Include -I. -IInclude -I/usr/local/include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build -c /usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src/prep_cif.c -o build/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src/prep_cif.o -Wall -fexceptions gcc -pthread -fPIC -fno-strict-aliasing -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -Ibuild/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/libffi/include -Ibuild/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/libffi -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src -I./Include -I. -IInclude -I/usr/local/include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build -c /usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src/closures.c -o build/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src/closures.o -Wall -fexceptions gcc -pthread -fPIC -fno-strict-aliasing -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -Ibuild/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/libffi/include -Ibuild/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/libffi -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src -I./Include -I. -IInclude -I/usr/local/include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build -c /usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src/x86/ffi.c -o build/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src/x86/ffi.o -Wall -fexceptions gcc -pthread -fPIC -fno-strict-aliasing -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -Ibuild/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/libffi/include -Ibuild/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/libffi -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src -I./Include -I. -IInclude -I/usr/local/include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build -c /usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src/x86/freebsd.S -o build/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src/x86/freebsd.o -Wall -fexceptions gcc -pthread -shared build/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/_ctypes.o build/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/callbacks.o build/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/callproc.o build/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/stgdict.o build/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/cfield.o build/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src/prep_cif.o build/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src/closures.o build/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.freebsd-6.4-RELEASE-i386-3.5-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src/x86/freebsd.o -L/usr/local/lib -o build/lib.freebsd-6.4-RELEASE-i386-3.5-pydebug/_ctypes.so *** WARNING: renaming "_ctypes" since importing it failed: build/lib.freebsd-6.4-RELEASE-i386-3.5-pydebug/_ctypes.so: Undefined symbol "ffi_call_win32" --- ---------- nosy: +haypo resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 13:15:10 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 30 Sep 2014 11:15:10 +0000 Subject: [issue22521] ctypes compilation fails on FreeBSD: Undefined symbol "ffi_call_win32" Message-ID: <1412075710.94.0.470127563443.issue22521@psf.upfronthosting.co.za> New submission from STINNER Victor: On buildbots FreeBSD 6.4 and 7.2, the compilation of the ctypes module fails because the function "ffi_call_win32" is missing. I don't understand why a "win32" function would be needed on FreeBSD!? http://buildbot.python.org/all/builders/x86%20FreeBSD%207.2%203.x/builds/5618/steps/test/logs/stdio http://buildbot.python.org/all/builders/x86%20FreeBSD%206.4%203.x/builds/5060/steps/compile/logs/stdio *** WARNING: renaming "_ctypes" since importing it failed: build/lib.freebsd-6.4-RELEASE-i386-3.5-pydebug/_ctypes.so: Undefined symbol "ffi_call_win32" ---------- messages: 227878 nosy: haypo, koobs priority: normal severity: normal status: open title: ctypes compilation fails on FreeBSD: Undefined symbol "ffi_call_win32" type: compile error versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 13:15:15 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 30 Sep 2014 11:15:15 +0000 Subject: [issue22521] ctypes compilation fails on FreeBSD: Undefined symbol "ffi_call_win32" In-Reply-To: <1412075710.94.0.470127563443.issue22521@psf.upfronthosting.co.za> Message-ID: <1412075715.91.0.0373994485504.issue22521@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- components: +ctypes keywords: +buildbot _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 13:15:45 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 30 Sep 2014 11:15:45 +0000 Subject: [issue11406] There is no os.listdir() equivalent returning generator instead of list In-Reply-To: <1299320278.86.0.403600489598.issue11406@psf.upfronthosting.co.za> Message-ID: <1412075745.58.0.612512843716.issue11406@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I haven't really followed, but now that the PEP is accepted, what is the progress on this one? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 13:17:54 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 30 Sep 2014 11:17:54 +0000 Subject: [issue22521] ctypes compilation fails on FreeBSD: Undefined symbol "ffi_call_win32" In-Reply-To: <1412075710.94.0.470127563443.issue22521@psf.upfronthosting.co.za> Message-ID: <1412075874.63.0.830923804735.issue22521@psf.upfronthosting.co.za> STINNER Victor added the comment: > I don't understand why a "win32" function would be needed on FreeBSD!? I see the function defined in libffi, but I don't see it used in the ctypes module. Note: the system libffi is not used, these buildbots compile the embedded version of libffi: "checking for --with-system-ffi... no" in configure logs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 13:28:59 2014 From: report at bugs.python.org (Claudiu Popa) Date: Tue, 30 Sep 2014 11:28:59 +0000 Subject: [issue22522] sys.excepthook doesn't receive the traceback when called from code.InteractiveInterpreter Message-ID: <1412076539.24.0.326910714196.issue22522@psf.upfronthosting.co.za> New submission from Claudiu Popa: It seems that sys.excepthook doesn't receive the traceback when an error occurs during a code.InteractiveInterpreter run. The problem is here: https://hg.python.org/cpython/file/5ade1061fa3d/Lib/code.py#l168. last_tb was previously set to None right before. The attached patch passes sys.last_traceback to sys.excepthook. ---------- components: Library (Lib) files: code_excepthook_traceback.patch keywords: patch messages: 227881 nosy: Claudiu.Popa, r.david.murray priority: normal severity: normal status: open title: sys.excepthook doesn't receive the traceback when called from code.InteractiveInterpreter type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file36759/code_excepthook_traceback.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 13:59:29 2014 From: report at bugs.python.org (Ben Hoyt) Date: Tue, 30 Sep 2014 11:59:29 +0000 Subject: [issue11406] There is no os.listdir() equivalent returning generator instead of list In-Reply-To: <1299320278.86.0.403600489598.issue11406@psf.upfronthosting.co.za> Message-ID: <1412078369.87.0.419823313365.issue11406@psf.upfronthosting.co.za> Ben Hoyt added the comment: Yes, PEP 471 has been accepted, and I've got a mostly-finished C implementation of os.scandir() for CPython 3.5, as well as tests and docs. If you want a sneak preview, see posixmodule_scandir*.c, test/test_scandir.py, and os.rst here: https://github.com/benhoyt/scandir It's working well on Windows, but the Linux version has a couple of tiny issues yet (core dumps ;-). Given that os.scandir() will solve this issue (as well as the bigger performance problem due to listdir throwing away file type info), can we close this issue and open another one to track the implementation of os.scandir() / PEP 471? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 14:04:45 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 30 Sep 2014 12:04:45 +0000 Subject: [issue5309] distutils doesn't parallelize extension module compilation In-Reply-To: <1235007592.93.0.0598331575131.issue5309@psf.upfronthosting.co.za> Message-ID: <1412078685.71.0.805947716882.issue5309@psf.upfronthosting.co.za> STINNER Victor added the comment: There is a similar error on OpenIndiana buildbot, Python cannot be compiled since this build: http://buildbot.python.org/all/builders/AMD64%20OpenIndiana%203.x/builds/8664/steps/compile/logs/stdio gcc -fPIC -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -I/usr/local/include/ncursesw -m64 -Werror=declaration-after-statement -Ibuild/temp.solaris-2.11-i86pc.64bit-3.5-pydebug/libffi/include -Ibuild/temp.solaris-2.11-i86pc.64bit-3.5-pydebug/libffi -I/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Modules/_ctypes/libffi/src -I./Include -I. -IInclude -I/usr/local/include -I/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Include -I/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build -c /export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Modules/_ctypes/libffi/src/x86/sysv.S -o build/temp.solaris-2.11-i86pc.64bit-3.5-pydebug/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Modules/_ctypes/libffi/src/x86/sysv.o -Wall -fexceptions gcc -fPIC -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -I/usr/local/include/ncursesw -m64 -Werror=declaration-after-statement -Ibuild/temp.solaris-2.11-i86pc.64bit-3.5-pydebug/libffi/include -Ibuild/temp.solaris-2.11-i86pc.64bit-3.5-pydebug/libffi -I/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Modules/_ctypes/libffi/src -I./Include -I. -IInclude -I/usr/local/include -I/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Include -I/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build -c /export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Modules/_ctypes/libffi/src/x86/win32.S -o build/temp.solaris-2.11-i86pc.64bit-3.5-pydebug/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Modules/_ctypes/libffi/src/x86/win32.o -Wall -fexceptions /var/tmp//ccqBa4n2.s: Assembler messages: /var/tmp//ccqBa4n2.s:8: Error: suffix or operands invalid for `push' /var/tmp//ccqBa4n2.s:17: Error: suffix or operands invalid for `push' /var/tmp//ccqBa4n2.s:18: Error: suffix or operands invalid for `push' /var/tmp//ccqBa4n2.s:79: Error: suffix or operands invalid for `jmp' /var/tmp//ccqBa4n2.s:138: Error: suffix or operands invalid for `pop' /var/tmp//ccqBa4n2.s:147: Error: suffix or operands invalid for `push' /var/tmp//ccqBa4n2.s:155: Error: suffix or operands invalid for `push' /var/tmp//ccqBa4n2.s:156: Error: suffix or operands invalid for `push' /var/tmp//ccqBa4n2.s:163: Error: suffix or operands invalid for `push' /var/tmp//ccqBa4n2.s:176: Error: suffix or operands invalid for `pop' /var/tmp//ccqBa4n2.s:210: Error: suffix or operands invalid for `jmp' /var/tmp//ccqBa4n2.s:251: Error: suffix or operands invalid for `pop' /var/tmp//ccqBa4n2.s:261: Error: suffix or operands invalid for `pop' /var/tmp//ccqBa4n2.s:268: Error: suffix or operands invalid for `push' /var/tmp//ccqBa4n2.s:272: Error: suffix or operands invalid for `push' /var/tmp//ccqBa4n2.s:315: Error: suffix or operands invalid for `jmp' /var/tmp//ccqBa4n2.s:358: Error: suffix or operands invalid for `pop' /var/tmp//ccqBa4n2.s:359: Error: suffix or operands invalid for `pop' /var/tmp//ccqBa4n2.s:370: Error: suffix or operands invalid for `push' /var/tmp//ccqBa4n2.s:383: Error: suffix or operands invalid for `pop' /var/tmp//ccqBa4n2.s:416: Error: suffix or operands invalid for `jmp' /var/tmp//ccqBa4n2.s:459: Error: suffix or operands invalid for `pop' /var/tmp//ccqBa4n2.s:460: Error: suffix or operands invalid for `pop' /var/tmp//ccqBa4n2.s:461: Error: suffix or operands invalid for `pop' /var/tmp//ccqBa4n2.s:471: Error: suffix or operands invalid for `jmp' *** WARNING: renaming "_curses" since importing it failed: ld.so.1: python: fatal: relocation error: file build/lib.solaris-2.11-i86pc.64bit-3.5-pydebug/_curses.so: symbol newscr: referenced symbol not found *** WARNING: renaming "_curses_panel" since importing it failed: No module named '_curses' error: [Errno 2] No such file or directory: 'build/temp.solaris-2.11-i86pc.64bit-3.5-pydebug/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Modules/_decimal/_decimal.o' make: *** [sharedmods] Error 1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 14:06:15 2014 From: report at bugs.python.org (Mathieu Dupuy) Date: Tue, 30 Sep 2014 12:06:15 +0000 Subject: [issue2202] urllib2 fails against IIS 6.0 (No support for MD5-sess auth) In-Reply-To: <1204223194.19.0.670418970441.issue2202@psf.upfronthosting.co.za> Message-ID: <1412078775.27.0.274615396307.issue2202@psf.upfronthosting.co.za> Mathieu Dupuy added the comment: But I think md5-sess should really be integrated. It's a standard mechanism described by a RFC (https://www.ietf.org/rfc/rfc2617.txt), and people need it, however insecure it may be (aren't other method (md5) insecure too ?). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 14:09:31 2014 From: report at bugs.python.org (Georg Brandl) Date: Tue, 30 Sep 2014 12:09:31 +0000 Subject: [issue16038] ftplib: unlimited readline() from connection In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za> Message-ID: <1412078970.99.0.652297770986.issue16038@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- versions: -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 14:11:34 2014 From: report at bugs.python.org (Georg Brandl) Date: Tue, 30 Sep 2014 12:11:34 +0000 Subject: [issue18747] Re-seed OpenSSL's PRNG after fork In-Reply-To: <1376570101.71.0.249202475923.issue18747@psf.upfronthosting.co.za> Message-ID: <1412079094.13.0.086616880339.issue18747@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- versions: -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 14:17:11 2014 From: report at bugs.python.org (Georg Brandl) Date: Tue, 30 Sep 2014 12:17:11 +0000 Subject: [issue16042] smtplib: unlimited readline() from connection In-Reply-To: <1348569609.82.0.499861906556.issue16042@psf.upfronthosting.co.za> Message-ID: <1412079431.09.0.10740339659.issue16042@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- versions: -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 14:21:48 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 30 Sep 2014 12:21:48 +0000 Subject: [issue5309] distutils doesn't parallelize extension module compilation In-Reply-To: <1235007592.93.0.0598331575131.issue5309@psf.upfronthosting.co.za> Message-ID: <1412079708.04.0.0665909698827.issue5309@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks for noticing this. Looking at an old build, the ctypes and curses compile errors under OpenIndiana are not new: http://buildbot.python.org/all/builders/AMD64%20OpenIndiana%203.x/builds/8658/steps/compile/logs/stdio Simply, it seems that a ctypes compile error is now interpreted as a failure of the compilation build step. I'll try to fix that. (the problem looks similar on the FreeBSD 6.4 buildbot) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 14:23:13 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 30 Sep 2014 12:23:13 +0000 Subject: [issue22521] ctypes compilation fails on FreeBSD: Undefined symbol "ffi_call_win32" In-Reply-To: <1412075710.94.0.470127563443.issue22521@psf.upfronthosting.co.za> Message-ID: <1412079793.01.0.806677985423.issue22521@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Those FreeBSD versions are totally obsolete, perhaps we should simply ignore any failures on them. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 14:24:40 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 30 Sep 2014 12:24:40 +0000 Subject: [issue5309] distutils doesn't parallelize extension module compilation In-Reply-To: <1235007592.93.0.0598331575131.issue5309@psf.upfronthosting.co.za> Message-ID: <1412079880.71.0.610739761143.issue5309@psf.upfronthosting.co.za> STINNER Victor added the comment: > the ctypes and curses compile errors under OpenIndiana are not new FYI the compilation error of curses on OpenIndiana is *old*, at least 3 years old :-( http://bugs.python.org/issue13552 I just opened the issue #22521 for the compilation error of ctypes on FreeBSD. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 14:25:06 2014 From: report at bugs.python.org (Jonas Wagner) Date: Tue, 30 Sep 2014 12:25:06 +0000 Subject: [issue5309] distutils doesn't parallelize extension module compilation In-Reply-To: <1235007592.93.0.0598331575131.issue5309@psf.upfronthosting.co.za> Message-ID: <1412079906.32.0.920758282089.issue5309@psf.upfronthosting.co.za> Jonas Wagner added the comment: I don't understand where this error comes from... The compilation commands are exactly the same in both the "before" and "after" logs. The order of commands is also the same. The only difference is this message: *** WARNING: renaming "_ssl" since importing it failed: build/lib.freebsd-6.4-RELEASE-i386-3.5-pydebug/_ssl.so: Undefined symbol "X509_check_ca" This message probably occurs because _ssl.so is now built in parallel with _ctypes. In the logs, one can see that the command to build _ctypes.o is executed; because of that, I wonder why the file is missing. Maybe we could check for wrong dependency tracking in the _ctypes makefile (similar to http://bugs.python.org/issue22359) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 14:37:24 2014 From: report at bugs.python.org (Georg Brandl) Date: Tue, 30 Sep 2014 12:37:24 +0000 Subject: [issue16041] poplib: unlimited readline() from connection In-Reply-To: <1348569563.2.0.69634867698.issue16041@psf.upfronthosting.co.za> Message-ID: <1412080644.15.0.672232153071.issue16041@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- versions: -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 14:47:28 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 30 Sep 2014 12:47:28 +0000 Subject: [issue16038] ftplib: unlimited readline() from connection In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za> Message-ID: <20140930124656.23217.24055@mail.hg.python.org> Roundup Robot added the comment: New changeset 783e7b4375ac by Georg Brandl in branch '3.2': Issue #16038: CVE-2013-1752: ftplib: Limit amount of data read by https://hg.python.org/cpython/rev/783e7b4375ac ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 14:47:28 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 30 Sep 2014 12:47:28 +0000 Subject: [issue16037] httplib: header parsing is unlimited In-Reply-To: <1348568722.91.0.654032066819.issue16037@psf.upfronthosting.co.za> Message-ID: <20140930124656.23217.39609@mail.hg.python.org> Roundup Robot added the comment: New changeset deee87d61436 by Georg Brandl in branch '3.2': Issue #16037: HTTPMessage.readheaders() raises an HTTPException when more than https://hg.python.org/cpython/rev/deee87d61436 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 14:47:29 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 30 Sep 2014 12:47:29 +0000 Subject: [issue16042] smtplib: unlimited readline() from connection In-Reply-To: <1348569609.82.0.499861906556.issue16042@psf.upfronthosting.co.za> Message-ID: <20140930124655.23217.49684@mail.hg.python.org> Roundup Robot added the comment: New changeset 0f362676460d by Georg Brandl in branch '3.2': Issue #16042: CVE-2013-1752: smtplib: Limit amount of data read by https://hg.python.org/cpython/rev/0f362676460d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 14:47:29 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 30 Sep 2014 12:47:29 +0000 Subject: [issue16041] poplib: unlimited readline() from connection In-Reply-To: <1348569563.2.0.69634867698.issue16041@psf.upfronthosting.co.za> Message-ID: <20140930124655.23217.67540@mail.hg.python.org> Roundup Robot added the comment: New changeset 76be07730f8d by Georg Brandl in branch '3.2': Issue #16041: CVE-2013-1752: poplib: Limit maximum line lengths to 2048 to https://hg.python.org/cpython/rev/76be07730f8d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 14:47:30 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 30 Sep 2014 12:47:30 +0000 Subject: [issue18709] SSL module fails to handle NULL bytes inside subjectAltNames general names (CVE-2013-4238) In-Reply-To: <1376307172.38.0.0558370001214.issue18709@psf.upfronthosting.co.za> Message-ID: <20140930124655.23217.83841@mail.hg.python.org> Roundup Robot added the comment: New changeset 386b0f478117 by Georg Brandl in branch '3.2': Issue #18709: Fix CVE-2013-4238. The SSL module now handles NULL bytes https://hg.python.org/cpython/rev/386b0f478117 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 14:47:30 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 30 Sep 2014 12:47:30 +0000 Subject: [issue18747] Re-seed OpenSSL's PRNG after fork In-Reply-To: <1376570101.71.0.249202475923.issue18747@psf.upfronthosting.co.za> Message-ID: <20140930124655.23217.40864@mail.hg.python.org> Roundup Robot added the comment: New changeset bdf73458df5f by Christian Heimes in branch '3.2': Issue #18747: document issue with OpenSSL's CPRNG state and fork https://hg.python.org/cpython/rev/bdf73458df5f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 14:47:58 2014 From: report at bugs.python.org (Georg Brandl) Date: Tue, 30 Sep 2014 12:47:58 +0000 Subject: [issue18709] SSL module fails to handle NULL bytes inside subjectAltNames general names (CVE-2013-4238) In-Reply-To: <1376307172.38.0.0558370001214.issue18709@psf.upfronthosting.co.za> Message-ID: <1412081278.46.0.588001399281.issue18709@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 14:49:13 2014 From: report at bugs.python.org (Georg Brandl) Date: Tue, 30 Sep 2014 12:49:13 +0000 Subject: [issue17997] ssl.match_hostname(): sub string wildcard should not match IDNA prefix In-Reply-To: <1368799493.86.0.504478450601.issue17997@psf.upfronthosting.co.za> Message-ID: <1412081353.96.0.792631528535.issue17997@psf.upfronthosting.co.za> Georg Brandl added the comment: Since it's been out in 3.2.x for so long, I won't apply this for 3.2 since at this point a behavior change might do more harm than good. ---------- resolution: -> fixed status: open -> closed versions: +Python 3.3, Python 3.4 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 14:49:29 2014 From: report at bugs.python.org (Georg Brandl) Date: Tue, 30 Sep 2014 12:49:29 +0000 Subject: [issue16038] ftplib: unlimited readline() from connection In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za> Message-ID: <1412081369.46.0.754662367645.issue16038@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 14:49:38 2014 From: report at bugs.python.org (Georg Brandl) Date: Tue, 30 Sep 2014 12:49:38 +0000 Subject: [issue18747] Re-seed OpenSSL's PRNG after fork In-Reply-To: <1376570101.71.0.249202475923.issue18747@psf.upfronthosting.co.za> Message-ID: <1412081378.56.0.0940338626045.issue18747@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 14:49:47 2014 From: report at bugs.python.org (Georg Brandl) Date: Tue, 30 Sep 2014 12:49:47 +0000 Subject: [issue16041] poplib: unlimited readline() from connection In-Reply-To: <1348569563.2.0.69634867698.issue16041@psf.upfronthosting.co.za> Message-ID: <1412081387.17.0.752842498738.issue16041@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- versions: -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 14:49:52 2014 From: report at bugs.python.org (Georg Brandl) Date: Tue, 30 Sep 2014 12:49:52 +0000 Subject: [issue16042] smtplib: unlimited readline() from connection In-Reply-To: <1348569609.82.0.499861906556.issue16042@psf.upfronthosting.co.za> Message-ID: <1412081392.96.0.75686013818.issue16042@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- versions: -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 14:50:04 2014 From: report at bugs.python.org (Georg Brandl) Date: Tue, 30 Sep 2014 12:50:04 +0000 Subject: [issue16037] httplib: header parsing is unlimited In-Reply-To: <1348568722.91.0.654032066819.issue16037@psf.upfronthosting.co.za> Message-ID: <1412081404.04.0.132361924719.issue16037@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 14:50:56 2014 From: report at bugs.python.org (Matthias Klose) Date: Tue, 30 Sep 2014 12:50:56 +0000 Subject: [issue22523] [regression] Lib/ssl.py still references _ssl.sslwrap Message-ID: <1412081456.12.0.536748620506.issue22523@psf.upfronthosting.co.za> New submission from Matthias Klose: the backport in issue #21308 caused this regression. _ssl.sslwrap is still referenced in some files. ---------- components: Library (Lib) messages: 227896 nosy: alex, benjamin.peterson, christian.heimes, doko, dstufft, giampaolo.rodola, janssen, pitrou priority: release blocker severity: normal status: open title: [regression] Lib/ssl.py still references _ssl.sslwrap versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 14:51:37 2014 From: report at bugs.python.org (Matthias Klose) Date: Tue, 30 Sep 2014 12:51:37 +0000 Subject: [issue21308] PEP 466: backport ssl changes In-Reply-To: <9f606957-c0fc-42fe-b0e1-52ea1cb44333@email.android.com> Message-ID: <1412081497.84.0.1599454734.issue21308@psf.upfronthosting.co.za> Matthias Klose added the comment: causing #22523, still referencing _ssl.sslwrap. ---------- nosy: +doko _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 14:53:52 2014 From: report at bugs.python.org (Matthias Troffaes) Date: Tue, 30 Sep 2014 12:53:52 +0000 Subject: [issue20218] Add methods to `pathlib.Path`: `write_text`, `read_text`, `write_bytes`, `read_bytes` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1412081632.19.0.840272378289.issue20218@psf.upfronthosting.co.za> Matthias Troffaes added the comment: Chiming in here: Sphinx's testing framework does include a feature that allows easily read/write files into/from text/bytes directly from path-like objects. There is thus a demand out there. If this feature were to make it into stdlib, it would be loved at least by Sphinx testers and sphinx extension module testers. Current implementation in Sphinx: https://bitbucket.org/birkenfeld/sphinx/src/f87ae5c0272e7384dc976414d091aa8b175827cd/tests/path.py?at=default#cl-129 Discussion to move to pathlib on Sphinx tracker: https://bitbucket.org/birkenfeld/sphinx/issue/1241/move-test-utilities-into-a-sphinx#comment-12645576 Some code examples of how this is typically used in Sphinx: https://bitbucket.org/tk0miya/sphinx-testing/src/ee89298fa8f848b7c3ca93656df5330db85b4291/README.rst?at=default https://github.com/mcmtroffaes/sphinxcontrib-bibtex/commit/0a0bf07a34e6f7e3c66ddacc0da02b4a2caba794 ---------- nosy: +matthiastroffaes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 14:55:31 2014 From: report at bugs.python.org (Matthias Klose) Date: Tue, 30 Sep 2014 12:55:31 +0000 Subject: [issue22523] [regression] Lib/ssl.py still references _ssl.sslwrap In-Reply-To: <1412081456.12.0.536748620506.issue22523@psf.upfronthosting.co.za> Message-ID: <1412081731.49.0.491342178921.issue22523@psf.upfronthosting.co.za> Matthias Klose added the comment: forwarded from https://bugs.debian.org/762010 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 14:57:32 2014 From: report at bugs.python.org (Ram Rachum) Date: Tue, 30 Sep 2014 12:57:32 +0000 Subject: [issue20218] Add methods to `pathlib.Path`: `write_text`, `read_text`, `write_bytes`, `read_bytes` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1412081852.1.0.700782328352.issue20218@psf.upfronthosting.co.za> Ram Rachum added the comment: Matthias: Do you prefer having both `write_bytes` and `write_text` instead of just `write` with a `binary` option? Do you prefer `append` and `exclusive` modes to be allowed or not? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 14:58:50 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 30 Sep 2014 12:58:50 +0000 Subject: [issue458343] distutils should zap .o as well as .so Message-ID: <20140930125828.23219.38259@mail.hg.python.org> Roundup Robot added the comment: New changeset 94af1af93670 by Antoine Pitrou in branch 'default': Remove pointless "vile hack" that can cause the build step to fail when some extension modules can't be imported. https://hg.python.org/cpython/rev/94af1af93670 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 14:58:50 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 30 Sep 2014 12:58:50 +0000 Subject: [issue5309] distutils doesn't parallelize extension module compilation In-Reply-To: <1235007592.93.0.0598331575131.issue5309@psf.upfronthosting.co.za> Message-ID: <20140930125828.23219.67665@mail.hg.python.org> Roundup Robot added the comment: New changeset 94af1af93670 by Antoine Pitrou in branch 'default': Remove pointless "vile hack" that can cause the build step to fail when some extension modules can't be imported. https://hg.python.org/cpython/rev/94af1af93670 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 14:59:10 2014 From: report at bugs.python.org (anupama srinivas murthy) Date: Tue, 30 Sep 2014 12:59:10 +0000 Subject: [issue22456] __base__ undocumented In-Reply-To: <1411340067.19.0.0232279983568.issue22456@psf.upfronthosting.co.za> Message-ID: <1412081950.7.0.478046895834.issue22456@psf.upfronthosting.co.za> anupama srinivas murthy added the comment: I have documented the function in object.rst file. I do not know the use of the function and have not mentioned that. My documentation is based on what I understood from the comments below and the explanation here: http://code.activestate.com/lists/python-list/334282/ ---------- keywords: +patch nosy: +anupama.srinivas.murthy Added file: http://bugs.python.org/file36760/function-documentation.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 14:59:27 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 30 Sep 2014 12:59:27 +0000 Subject: [issue22517] BufferedRWpair doesn't clear weakrefs In-Reply-To: <1412024342.18.0.174047226004.issue22517@psf.upfronthosting.co.za> Message-ID: <20140930125915.23203.89057@mail.hg.python.org> Roundup Robot added the comment: New changeset 4fa5239624b8 by Georg Brandl in branch '3.2': Issue #22517: When a io.BufferedRWPair object is deallocated, clear its https://hg.python.org/cpython/rev/4fa5239624b8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 14:59:27 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 30 Sep 2014 12:59:27 +0000 Subject: [issue22419] wsgiref request length In-Reply-To: <1410804386.26.0.756558523053.issue22419@psf.upfronthosting.co.za> Message-ID: <20140930125915.23203.52850@mail.hg.python.org> Roundup Robot added the comment: New changeset 0d115d14adfd by Georg Brandl in branch '3.2': Issue #22419: Limit the length of incoming HTTP request in wsgiref server to https://hg.python.org/cpython/rev/0d115d14adfd ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 15:01:04 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 30 Sep 2014 13:01:04 +0000 Subject: [issue5309] distutils doesn't parallelize extension module compilation In-Reply-To: <1235007592.93.0.0598331575131.issue5309@psf.upfronthosting.co.za> Message-ID: <1412082064.4.0.163758479508.issue5309@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The change I just pushed should fix the failures, waiting for the buildbots to compile now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 15:04:24 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 30 Sep 2014 13:04:24 +0000 Subject: [issue5309] distutils doesn't parallelize extension module compilation In-Reply-To: <1235007592.93.0.0598331575131.issue5309@psf.upfronthosting.co.za> Message-ID: <1412082264.63.0.421321899783.issue5309@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Looks ok on OpenIndiana, closing now. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 15:05:37 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 30 Sep 2014 13:05:37 +0000 Subject: [issue22518] integer overflow in encoding unicode In-Reply-To: <1412024485.39.0.908219343503.issue22518@psf.upfronthosting.co.za> Message-ID: <1412082337.72.0.528666306159.issue22518@psf.upfronthosting.co.za> STINNER Victor added the comment: > New changeset f86fde20e9ce by Benjamin Peterson in branch 'default': > merge 3.4 (closes #22518) > https://hg.python.org/cpython/rev/f86fde20e9ce This changeset added ">>>> other". It looks like you commited a conflict. - if (requiredsize<2*outsize) + if (outsize <= PY_SSIZE_T_MAX/2 && requiredsize < 2*outsize) requiredsize = 2*outsize; I'm not sure that this change is correct. Why not raising an exception on overflow? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 15:05:55 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 30 Sep 2014 13:05:55 +0000 Subject: [issue20218] Add methods to `pathlib.Path`: `write_text`, `read_text`, `write_bytes`, `read_bytes` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1412082355.05.0.237448897467.issue20218@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +georg.brandl resolution: rejected -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 15:08:40 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 30 Sep 2014 13:08:40 +0000 Subject: [issue22519] integer overflow in computing byte's object representation In-Reply-To: <1412024585.59.0.0929794410107.issue22519@psf.upfronthosting.co.za> Message-ID: <1412082520.26.0.892288532885.issue22519@psf.upfronthosting.co.za> STINNER Victor added the comment: It would be nice to have a "bigmem" test checking that repr(b'\x00'*(2**30+1)) doesn't crash anymore. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 15:09:21 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 30 Sep 2014 13:09:21 +0000 Subject: [issue22518] integer overflow in encoding unicode In-Reply-To: <1412024485.39.0.908219343503.issue22518@psf.upfronthosting.co.za> Message-ID: <1412082561.48.0.824731387495.issue22518@psf.upfronthosting.co.za> STINNER Victor added the comment: It would be nice to add a bigmem test to check that repr('\x00'*(2**30+1)) doesn't crash anymore. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 15:11:14 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 30 Sep 2014 13:11:14 +0000 Subject: [issue22520] integer overflow in computing unicode's object representation In-Reply-To: <1412024659.14.0.152968090659.issue22520@psf.upfronthosting.co.za> Message-ID: <1412082674.68.0.970915053563.issue22520@psf.upfronthosting.co.za> STINNER Victor added the comment: It would be nice to add a bigmem test to check that repr('\x00'*(2**30+1)) doesn't crash anymore. ---------- nosy: +haypo resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 15:11:29 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 30 Sep 2014 13:11:29 +0000 Subject: [issue22519] integer overflow in computing byte's object representation In-Reply-To: <1412024585.59.0.0929794410107.issue22519@psf.upfronthosting.co.za> Message-ID: <1412082689.46.0.573032480445.issue22519@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 15:13:37 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 30 Sep 2014 13:13:37 +0000 Subject: [issue22518] integer overflow in encoding unicode In-Reply-To: <1412024485.39.0.908219343503.issue22518@psf.upfronthosting.co.za> Message-ID: <1412082817.02.0.161591652859.issue22518@psf.upfronthosting.co.za> STINNER Victor added the comment: > It would be nice to add a bigmem test to check that repr('\x00'*(2**30+1)) doesn't crash anymore. Ooops, wrong issue, the test is : ("\uffff" * (2**29)).encode("latin1", errors="xmlcharrefreplace"). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 15:13:47 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 30 Sep 2014 13:13:47 +0000 Subject: [issue22518] integer overflow in encoding unicode In-Reply-To: <1412024485.39.0.908219343503.issue22518@psf.upfronthosting.co.za> Message-ID: <1412082827.57.0.906251668627.issue22518@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 15:17:53 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 30 Sep 2014 13:17:53 +0000 Subject: [issue16037] httplib: header parsing is unlimited In-Reply-To: <1348568722.91.0.654032066819.issue16037@psf.upfronthosting.co.za> Message-ID: <1412083073.2.0.913949956322.issue16037@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 15:20:17 2014 From: report at bugs.python.org (Georg Brandl) Date: Tue, 30 Sep 2014 13:20:17 +0000 Subject: [issue20218] Add methods to `pathlib.Path`: `write_text`, `read_text`, `write_bytes`, `read_bytes` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1412083217.14.0.688284453048.issue20218@psf.upfronthosting.co.za> Georg Brandl added the comment: Note that these methods were already part of Jason's path.py when I imported it for use by Sphinx. I think these convenience methods are useful indeed, so if it is fine with your philosophy for pathlib, I'd be happy to see them there. The write_text/write_bytes style would be preferred for me, and I agree that too many options, e.g. append and exclusive, are not as helpful. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 15:27:02 2014 From: report at bugs.python.org (Matthias Troffaes) Date: Tue, 30 Sep 2014 13:27:02 +0000 Subject: [issue20218] Add methods to `pathlib.Path`: `write_text`, `read_text`, `write_bytes`, `read_bytes` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1412083622.17.0.41475007559.issue20218@psf.upfronthosting.co.za> Matthias Troffaes added the comment: Thanks for the quick response. I agree with Georg on all points, i.e. longer function names and no extra options. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 15:30:17 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 30 Sep 2014 13:30:17 +0000 Subject: [issue22518] integer overflow in encoding unicode In-Reply-To: <1412082337.72.0.528666306159.issue22518@psf.upfronthosting.co.za> Message-ID: <1913239.7U1YMLyDmn@raxxla> Serhiy Storchaka added the comment: > I'm not sure that this change is correct. Why not raising an exception on > overflow? This is correct. This check prevents overflow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 15:38:44 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 30 Sep 2014 13:38:44 +0000 Subject: [issue2399] Patches for Tools/msi In-Reply-To: <1205858738.04.0.681248681608.issue2399@psf.upfronthosting.co.za> Message-ID: <1412084324.78.0.809673935786.issue2399@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: needs patch -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 15:39:24 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 30 Sep 2014 13:39:24 +0000 Subject: [issue22518] integer overflow in encoding unicode In-Reply-To: <1412024485.39.0.908219343503.issue22518@psf.upfronthosting.co.za> Message-ID: <1412084364.73.0.608966187299.issue22518@psf.upfronthosting.co.za> STINNER Victor added the comment: > This is correct. This check prevents overflow. Oh, I didn't understand that "requiredsize = 2*outsize;" is only used for performances, to overallocate the buffer. So I agree that it's fine to not overallocate if it would overflow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 15:39:45 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 30 Sep 2014 13:39:45 +0000 Subject: [issue22421] securing pydoc server In-Reply-To: <1410808618.63.0.0937681366512.issue22421@psf.upfronthosting.co.za> Message-ID: <1412084385.48.0.619231822544.issue22421@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 15:40:35 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 30 Sep 2014 13:40:35 +0000 Subject: [issue21831] integer overflow in 'buffer' type allows reading memory In-Reply-To: <1403579483.71.0.894080875478.issue21831@psf.upfronthosting.co.za> Message-ID: <1412084435.77.0.781542241654.issue21831@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 15:41:39 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 30 Sep 2014 13:41:39 +0000 Subject: [issue22518] integer overflow in encoding unicode In-Reply-To: <1412024485.39.0.908219343503.issue22518@psf.upfronthosting.co.za> Message-ID: <1412084499.52.0.566217649644.issue22518@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- type: crash -> security _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 15:41:47 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 30 Sep 2014 13:41:47 +0000 Subject: [issue22517] BufferedRWpair doesn't clear weakrefs In-Reply-To: <1412024342.18.0.174047226004.issue22517@psf.upfronthosting.co.za> Message-ID: <1412084507.44.0.350406992891.issue22517@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- type: crash -> security _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 15:41:58 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 30 Sep 2014 13:41:58 +0000 Subject: [issue22519] integer overflow in computing byte's object representation In-Reply-To: <1412024585.59.0.0929794410107.issue22519@psf.upfronthosting.co.za> Message-ID: <1412084518.61.0.760695841118.issue22519@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- type: crash -> security _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 15:42:08 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 30 Sep 2014 13:42:08 +0000 Subject: [issue22520] integer overflow in computing unicode's object representation In-Reply-To: <1412024659.14.0.152968090659.issue22520@psf.upfronthosting.co.za> Message-ID: <1412084528.19.0.19452695346.issue22520@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- type: crash -> security _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 15:46:56 2014 From: report at bugs.python.org (Georg Brandl) Date: Tue, 30 Sep 2014 13:46:56 +0000 Subject: [issue22518] integer overflow in encoding unicode In-Reply-To: <1412024485.39.0.908219343503.issue22518@psf.upfronthosting.co.za> Message-ID: <1412084816.65.0.140798069535.issue22518@psf.upfronthosting.co.za> Georg Brandl added the comment: Benjamin, could you make a patch for 3.2 as well? ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 15:48:38 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 30 Sep 2014 13:48:38 +0000 Subject: [issue22421] securing pydoc server In-Reply-To: <1410808618.63.0.0937681366512.issue22421@psf.upfronthosting.co.za> Message-ID: <20140930134833.40029.50170@mail.hg.python.org> Roundup Robot added the comment: New changeset 02dae04b3e2b by Georg Brandl in branch '3.2': Issue #22421 - Secure pydoc server run. Bind it to localhost instead of all interfaces. https://hg.python.org/cpython/rev/02dae04b3e2b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 15:49:42 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 30 Sep 2014 13:49:42 +0000 Subject: [issue22448] call_at/call_later with Timer cancellation can result in (practically) unbounded memory usage. In-Reply-To: <1411172040.41.0.974691283228.issue22448@psf.upfronthosting.co.za> Message-ID: <1412084982.03.0.545557875135.issue22448@psf.upfronthosting.co.za> Yury Selivanov added the comment: Victor, During the code review we tried the single loop approach. At the end Joshua wrote a small benchmark to test if it's really faster to do it in one loop or not. Turned out that single loop approach is not faster than loop+comprehension (but it's not much slower either, I'd say they are about the same in terms of speed). One loop approach might work faster on PyPy, but unfortunately, they still don't support 3.3 to test. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 15:51:44 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 30 Sep 2014 13:51:44 +0000 Subject: [issue22448] call_at/call_later with Timer cancellation can result in (practically) unbounded memory usage. In-Reply-To: <1411172040.41.0.974691283228.issue22448@psf.upfronthosting.co.za> Message-ID: <1412085104.92.0.540271328746.issue22448@psf.upfronthosting.co.za> STINNER Victor added the comment: > Turned out that single loop approach is not faster than loop+comprehension IMO it makes the code simpler and easier to understand. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 15:55:19 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 30 Sep 2014 13:55:19 +0000 Subject: [issue22448] call_at/call_later with Timer cancellation can result in (practically) unbounded memory usage. In-Reply-To: <1411172040.41.0.974691283228.issue22448@psf.upfronthosting.co.za> Message-ID: <1412085319.71.0.702513649069.issue22448@psf.upfronthosting.co.za> Yury Selivanov added the comment: > IMO it makes the code simpler and easier to understand. But it's a tad slower, like 2-3% ;) You can test it yourself, we only tested it on huge tasks list of 1M items. FWIW, I'm not opposed to your patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 15:59:38 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 30 Sep 2014 13:59:38 +0000 Subject: [issue22517] BufferedRWpair doesn't clear weakrefs In-Reply-To: <1412024342.18.0.174047226004.issue22517@psf.upfronthosting.co.za> Message-ID: <1412085578.68.0.980953920003.issue22517@psf.upfronthosting.co.za> Antoine Pitrou added the comment: It's an actual crash, AFAIK. ---------- type: security -> crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 16:01:31 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 30 Sep 2014 14:01:31 +0000 Subject: [issue22518] integer overflow in encoding unicode In-Reply-To: <1412082817.02.0.161591652859.issue22518@psf.upfronthosting.co.za> Message-ID: <5935568.oArXzhuMVC@raxxla> Serhiy Storchaka added the comment: > Ooops, wrong issue, the test is : ("\uffff" * (2**29)).encode("latin1", > errors="xmlcharrefreplace"). ("\uffff" * (sys.maxsize//8+1)).encode("latin1", errors="xmlcharrefreplace") or ("\xff" * (sys.maxsize//6+1)).encode("ascii", errors="xmlcharrefreplace") ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 16:01:40 2014 From: report at bugs.python.org (Georg Brandl) Date: Tue, 30 Sep 2014 14:01:40 +0000 Subject: [issue20994] Disable TLS Compression In-Reply-To: <1395323616.33.0.927638655451.issue20994@psf.upfronthosting.co.za> Message-ID: <1412085700.97.0.671460387833.issue20994@psf.upfronthosting.co.za> Georg Brandl added the comment: I wouldn't consider this important enough for 3.2; since it lacks the means to do the opt-back-in. ---------- nosy: +georg.brandl versions: -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 16:02:26 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 30 Sep 2014 14:02:26 +0000 Subject: [issue16039] imaplib: unlimited readline() from connection In-Reply-To: <1348569370.53.0.568109495954.issue16039@psf.upfronthosting.co.za> Message-ID: <20140930140217.23199.52439@mail.hg.python.org> Roundup Robot added the comment: New changeset 5d1c03316af7 by Georg Brandl in branch '3.2': Issue #16039: CVE-2013-1752: Change use of readline in imaplib module to limit https://hg.python.org/cpython/rev/5d1c03316af7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 16:04:41 2014 From: report at bugs.python.org (Georg Brandl) Date: Tue, 30 Sep 2014 14:04:41 +0000 Subject: [issue16039] imaplib: unlimited readline() from connection In-Reply-To: <1348569370.53.0.568109495954.issue16039@psf.upfronthosting.co.za> Message-ID: <1412085881.18.0.272190124657.issue16039@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- versions: -Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 16:09:21 2014 From: report at bugs.python.org (Georg Brandl) Date: Tue, 30 Sep 2014 14:09:21 +0000 Subject: [issue20218] Add methods to `pathlib.Path`: `write_text`, `read_text`, `write_bytes`, `read_bytes` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1412086161.44.0.0419028090054.issue20218@psf.upfronthosting.co.za> Georg Brandl added the comment: Next try. ---------- Added file: http://bugs.python.org/file36761/pathlib_readwrite_v5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 16:11:08 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 30 Sep 2014 14:11:08 +0000 Subject: [issue16039] imaplib: unlimited readline() from connection In-Reply-To: <1348569370.53.0.568109495954.issue16039@psf.upfronthosting.co.za> Message-ID: <1412086268.15.0.131629363815.issue16039@psf.upfronthosting.co.za> STINNER Victor added the comment: > New changeset 5d1c03316af7 by Georg Brandl in branch '3.2': > Issue #16039: CVE-2013-1752: Change use of readline in imaplib module to limit > https://hg.python.org/cpython/rev/5d1c03316af7 I'm not sure that this change is correct, the test failed on Windows. Or maybe, it's just an issue with test test? http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/5168/steps/test/logs/stdio ====================================================================== ERROR: test_connect (test.test_smtpnet.SmtpSSLTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_smtpnet.py", line 16, in test_connect server = smtplib.SMTP_SSL(self.testServer, self.remotePort) File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\smtplib.py", line 862, in __init__ SMTP.__init__(self, host, port, local_hostname, timeout) File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\smtplib.py", line 260, in __init__ (code, msg) = self.connect(host, port) File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\smtplib.py", line 321, in connect (code, msg) = self.getreply() File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\smtplib.py", line 367, in getreply line = self.file.readline(_MAXLINE + 1) TypeError: readline() takes exactly 1 positional argument (2 given) ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 16:14:12 2014 From: report at bugs.python.org (Georg Brandl) Date: Tue, 30 Sep 2014 14:14:12 +0000 Subject: [issue16039] imaplib: unlimited readline() from connection In-Reply-To: <1348569370.53.0.568109495954.issue16039@psf.upfronthosting.co.za> Message-ID: <1412086452.49.0.717537166245.issue16039@psf.upfronthosting.co.za> Georg Brandl added the comment: Let me check that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 16:19:08 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 30 Sep 2014 14:19:08 +0000 Subject: [issue11406] There is no os.listdir() equivalent returning generator instead of list In-Reply-To: <1299320278.86.0.403600489598.issue11406@psf.upfronthosting.co.za> Message-ID: <1412086748.43.0.380878999453.issue11406@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Given that os.scandir() will solve this issue (as well as the bigger performance problem due to listdir throwing away file type info), can we close this issue and open another one to track the implementation of os.scandir() / PEP 471? This makes sense. Can you do it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 16:22:56 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 30 Sep 2014 14:22:56 +0000 Subject: [issue20939] test_geturl of test_urllibnet fails with 'https://www.python.org/' != 'http://www.python.org/' In-Reply-To: <1394912477.16.0.0678033428019.issue20939@psf.upfronthosting.co.za> Message-ID: <20140930142222.74989.67659@mail.hg.python.org> Roundup Robot added the comment: New changeset 97c329849ef3 by Ned Deily in branch '3.2': Issue #20939: Use www.example.com instead of www.python.org to avoid test https://hg.python.org/cpython/rev/97c329849ef3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 16:24:12 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 30 Sep 2014 14:24:12 +0000 Subject: [issue16039] imaplib: unlimited readline() from connection In-Reply-To: <1348569370.53.0.568109495954.issue16039@psf.upfronthosting.co.za> Message-ID: <1412087052.49.0.450620770719.issue16039@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: This error is rather related to issue #16042, not issue #16039. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 16:28:15 2014 From: report at bugs.python.org (Georg Brandl) Date: Tue, 30 Sep 2014 14:28:15 +0000 Subject: [issue16039] imaplib: unlimited readline() from connection In-Reply-To: <1348569370.53.0.568109495954.issue16039@psf.upfronthosting.co.za> Message-ID: <1412087295.05.0.227390427395.issue16039@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 16:31:00 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 30 Sep 2014 14:31:00 +0000 Subject: [issue14156] argparse.FileType for '-' doesn't work for a mode of 'rb' In-Reply-To: <1330513271.31.0.437438851478.issue14156@psf.upfronthosting.co.za> Message-ID: <1412087460.21.0.0907200180325.issue14156@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: -> test needed type: crash -> behavior versions: -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 16:37:07 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 30 Sep 2014 14:37:07 +0000 Subject: [issue16042] smtplib: unlimited readline() from connection In-Reply-To: <1348569609.82.0.499861906556.issue16042@psf.upfronthosting.co.za> Message-ID: <1412087827.65.0.0164266232283.issue16042@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: New changeset 4065c4539fcb by Georg Brandl in branch '3.2': Fix-up for 0f362676460d: add missing size argument to SSLFakeFile.readline(), as in 2.6 backport https://hg.python.org/cpython/rev/4065c4539fcb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 16:42:42 2014 From: report at bugs.python.org (Ben Hoyt) Date: Tue, 30 Sep 2014 14:42:42 +0000 Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning function Message-ID: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za> New submission from Ben Hoyt: Opening this to track the implementation of PEP 471: os.scandir() [1]. This supercedes Issue #11406 (and possibly others)? The implementation is most of the way there, but not yet done as a CPythono 3.5 patch. Before I have a proper patch, it's available on GitHub [2] -- see posixmodule_scandir*.c, test/test_scandir.py, and os.rst. [1] http://legacy.python.org/dev/peps/pep-0471/ [2] https://github.com/benhoyt/scandir ---------- components: Library (Lib) messages: 227933 nosy: benhoyt, haypo, mmarkk, pitrou, tim.golden priority: normal severity: normal status: open title: PEP 471 implementation: os.scandir() directory scanning function type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 16:43:33 2014 From: report at bugs.python.org (Ben Hoyt) Date: Tue, 30 Sep 2014 14:43:33 +0000 Subject: [issue11406] There is no os.listdir() equivalent returning generator instead of list In-Reply-To: <1299320278.86.0.403600489598.issue11406@psf.upfronthosting.co.za> Message-ID: <1412088213.25.0.315130812071.issue11406@psf.upfronthosting.co.za> Ben Hoyt added the comment: Okay, I've opened http://bugs.python.org/issue22524, but I don't have the permissions to close this one, so could someone with bugs.python.org superpowers please do that? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 16:44:24 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 30 Sep 2014 14:44:24 +0000 Subject: [issue19529] Fix unicode_aswidechar() with 4byte unicode and 2byte wchar_t, for AIX In-Reply-To: <1383924879.95.0.72869375832.issue19529@psf.upfronthosting.co.za> Message-ID: <1412088264.84.0.2572798117.issue19529@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Georg, what is your decision? ---------- nosy: +serhiy.storchaka stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 16:47:15 2014 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 30 Sep 2014 14:47:15 +0000 Subject: [issue11406] There is no os.listdir() equivalent returning generator instead of list In-Reply-To: <1299320278.86.0.403600489598.issue11406@psf.upfronthosting.co.za> Message-ID: <1412088435.67.0.0508865969055.issue11406@psf.upfronthosting.co.za> Nick Coghlan added the comment: This approach has been rejected in favour of the accepted PEP 471 proposal to add os.scandir() (issue #22524) ---------- resolution: -> rejected stage: needs patch -> resolved status: open -> closed superseder: -> PEP 471 implementation: os.scandir() directory scanning function _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 16:50:15 2014 From: report at bugs.python.org (Georg Brandl) Date: Tue, 30 Sep 2014 14:50:15 +0000 Subject: [issue19529] Fix unicode_aswidechar() with 4byte unicode and 2byte wchar_t, for AIX In-Reply-To: <1383924879.95.0.72869375832.issue19529@psf.upfronthosting.co.za> Message-ID: <1412088615.71.0.347555407216.issue19529@psf.upfronthosting.co.za> Georg Brandl added the comment: Looks obvious and is potentially a security fix, so it can/should go in. Please add a NEWS entry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 16:53:57 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 30 Sep 2014 14:53:57 +0000 Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning function In-Reply-To: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za> Message-ID: <1412088837.9.0.765055473065.issue22524@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 16:54:55 2014 From: report at bugs.python.org (Akira Li) Date: Tue, 30 Sep 2014 14:54:55 +0000 Subject: [issue22472] OSErrors should use str and not repr on paths In-Reply-To: <1411504485.58.0.497867466453.issue22472@psf.upfronthosting.co.za> Message-ID: <1412088895.18.0.212221165841.issue22472@psf.upfronthosting.co.za> Akira Li added the comment: I meant, in general, repr() is better for an error message because it should be unambigous unlike str() but in your particular case you could use filename attribute to format the way you like it for your UI. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 16:56:45 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 30 Sep 2014 14:56:45 +0000 Subject: [issue19529] Fix unicode_aswidechar() with 4byte unicode and 2byte wchar_t, for AIX In-Reply-To: <1383924879.95.0.72869375832.issue19529@psf.upfronthosting.co.za> Message-ID: <1412089005.84.0.715350488407.issue19529@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 16:56:50 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 30 Sep 2014 14:56:50 +0000 Subject: [issue22472] OSErrors should use str and not repr on paths In-Reply-To: <1411504485.58.0.497867466453.issue22472@psf.upfronthosting.co.za> Message-ID: <1412089010.9.0.738321629123.issue22472@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Also, the repr() makes it easier to copy-paste in Python code (e.g. on the prompt). ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 16:56:51 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 30 Sep 2014 14:56:51 +0000 Subject: [issue22448] call_at/call_later with Timer cancellation can result in (practically) unbounded memory usage. In-Reply-To: <1411172040.41.0.974691283228.issue22448@psf.upfronthosting.co.za> Message-ID: <1412089011.17.0.917271060123.issue22448@psf.upfronthosting.co.za> Yury Selivanov added the comment: Victor, I've done some additional testing. Here's a test that Joshua wrote for the code review: https://gist.github.com/1st1/b38ac6785cb01a679722 It appears that single loop approach works a bit faster for smaller collections of tasks. On a list of 10000 tasks it's on average faster 2-3%, on a list of 1000000 tasks it's slower for 2-3%. I'm not sure what's the average number of tasks for an "average" asyncio application, but something tells me it's not going to be in range of millions. I think you can fix the code to have a single loop. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 16:57:19 2014 From: report at bugs.python.org (Behdad Esfahbod) Date: Tue, 30 Sep 2014 14:57:19 +0000 Subject: [issue22525] ast.literal_eval() doesn't do what the documentation says Message-ID: <1412089039.94.0.626035759284.issue22525@psf.upfronthosting.co.za> New submission from Behdad Esfahbod: The documentation says: """ Safely evaluate an expression node or a string containing a Python expression. The string or node provided may only consist of the following Python literal structures: strings, bytes, numbers, tuples, lists, dicts, sets, booleans, and None. This can be used for safely evaluating strings containing Python expressions from untrusted sources without the need to parse the values oneself. """ This makes me to believe that this is a useful replacement for eval() that is safe. However, it fails to make it clear that it parses **one literal**, NOT an expression. Ie. it can't handle "2*2". Weirdly enough, at least with my Python 3.2.3, it does handle "2+2" with no problem. This seriously limits the usefulness of this function. Is there really no equivalent that parses simple expressions of literals? ---------- messages: 227941 nosy: Behdad.Esfahbod priority: normal severity: normal status: open title: ast.literal_eval() doesn't do what the documentation says _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 16:57:51 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 30 Sep 2014 14:57:51 +0000 Subject: [issue21909] PyLong_FromString drops const In-Reply-To: <1404371359.19.0.197887236946.issue21909@psf.upfronthosting.co.za> Message-ID: <1412089071.89.0.777634626808.issue21909@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: PyLong_FromString() is consistent with standard C functions strtol(), strtod(), etc. Changing pend's type to "const char**" is backward incompatible. ---------- nosy: +serhiy.storchaka resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 16:58:21 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 30 Sep 2014 14:58:21 +0000 Subject: [issue22448] call_at/call_later with Timer cancellation can result in (practically) unbounded memory usage. In-Reply-To: <1411172040.41.0.974691283228.issue22448@psf.upfronthosting.co.za> Message-ID: <1412089101.24.0.125346417261.issue22448@psf.upfronthosting.co.za> STINNER Victor added the comment: "... on average faster 2-3% ... slower for 2-3%" 3% is meaningless. On a microbenchmark, you can say that it's faster or slower if the difference is at least 10%. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 17:00:44 2014 From: report at bugs.python.org (David Edelsohn) Date: Tue, 30 Sep 2014 15:00:44 +0000 Subject: [issue22397] test_socket failure on AIX In-Reply-To: <1410547453.79.0.287492326275.issue22397@psf.upfronthosting.co.za> Message-ID: <1412089244.67.0.986612643278.issue22397@psf.upfronthosting.co.za> Changes by David Edelsohn : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 17:11:51 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 30 Sep 2014 15:11:51 +0000 Subject: [issue22397] test_socket failure on AIX In-Reply-To: <1410547453.79.0.287492326275.issue22397@psf.upfronthosting.co.za> Message-ID: <1412089911.31.0.949926456213.issue22397@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. ---------- nosy: +serhiy.storchaka stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 17:17:20 2014 From: report at bugs.python.org (Georg Brandl) Date: Tue, 30 Sep 2014 15:17:20 +0000 Subject: [issue19855] uuid._find_mac fails if an executable not in /sbin or /usr/sbin In-Reply-To: <1385910768.71.0.356029979861.issue19855@psf.upfronthosting.co.za> Message-ID: <1412090240.56.0.174456566395.issue19855@psf.upfronthosting.co.za> Georg Brandl added the comment: Serhiy, would you make a patch for 3.2 too? ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 17:19:10 2014 From: report at bugs.python.org (Evgeny Kapun) Date: Tue, 30 Sep 2014 15:19:10 +0000 Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning function In-Reply-To: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za> Message-ID: <1412090350.22.0.127596288634.issue22524@psf.upfronthosting.co.za> Changes by Evgeny Kapun : ---------- nosy: +abacabadabacaba _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 17:42:29 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 30 Sep 2014 15:42:29 +0000 Subject: [issue16555] Add es_cu to locale aliases In-Reply-To: <1353900143.47.0.688085135262.issue16555@psf.upfronthosting.co.za> Message-ID: <1412091749.77.0.618383514086.issue16555@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This issue is superseded by issue20079. ---------- nosy: +serhiy.storchaka status: open -> pending superseder: -> Add support for glibc supported locales _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 17:43:43 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 30 Sep 2014 15:43:43 +0000 Subject: [issue20076] Add UTF-8 locale aliases In-Reply-To: <1388100548.94.0.295897364372.issue20076@psf.upfronthosting.co.za> Message-ID: <1412091823.75.0.866870705613.issue20076@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 17:45:29 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 30 Sep 2014 15:45:29 +0000 Subject: [issue20087] Mismatch between glibc and X11 locale.alias In-Reply-To: <1388222989.89.0.773650778168.issue20087@psf.upfronthosting.co.za> Message-ID: <1412091929.44.0.384478766369.issue20087@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 17:45:48 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 30 Sep 2014 15:45:48 +0000 Subject: [issue20079] Add support for glibc supported locales In-Reply-To: <1388139147.62.0.637898307439.issue20079@psf.upfronthosting.co.za> Message-ID: <1412091948.11.0.801560050404.issue20079@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 17:48:04 2014 From: report at bugs.python.org (Ram Rachum) Date: Tue, 30 Sep 2014 15:48:04 +0000 Subject: [issue20218] Add methods to `pathlib.Path`: `write_text`, `read_text`, `write_bytes`, `read_bytes` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1412092084.88.0.799563235868.issue20218@psf.upfronthosting.co.za> Ram Rachum added the comment: What do you think about changing the signature to something like this: def read_text(self, *, encoding=None, errors=None): This is to avoid these arguments being used positionally, which eases future backwards compatibility changes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 17:54:32 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 30 Sep 2014 15:54:32 +0000 Subject: [issue22397] test_socket failure on AIX In-Reply-To: <1410547453.79.0.287492326275.issue22397@psf.upfronthosting.co.za> Message-ID: <1412092472.65.0.576247658732.issue22397@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See also issue11192. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 17:56:47 2014 From: report at bugs.python.org (Georg Brandl) Date: Tue, 30 Sep 2014 15:56:47 +0000 Subject: [issue20218] Add methods to `pathlib.Path`: `write_text`, `read_text`, `write_bytes`, `read_bytes` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1412092607.91.0.0421287036259.issue20218@psf.upfronthosting.co.za> Changes by Georg Brandl : Added file: http://bugs.python.org/file36762/pathlib_readwrite_v6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 18:10:51 2014 From: report at bugs.python.org (Jakub Mateusz Kowalski) Date: Tue, 30 Sep 2014 16:10:51 +0000 Subject: [issue22526] file iteration crashes for huge lines (2GiB+) Message-ID: <1412093451.75.0.0583026923325.issue22526@psf.upfronthosting.co.za> New submission from Jakub Mateusz Kowalski: File /tmp/2147483648zeros is 2^31 (2GiB) zero-bytes ('\0'). Readline method works fine: >>> fh = open('/tmp/2147483648zeros', 'rb') >>> line = fh.readline() >>> len(line) 2147483648 However when I try to iterate over the file: >>> fh = open('/tmp/2147483648zeros', 'rb') >>> for line in fh: ... print len(line) SystemError Traceback (most recent call last) /home/jkowalski/ in () ----> 1 for line in fh: 2 print len(line) 3 SystemError: Negative size passed to PyString_FromStringAndSize Same is for greater files (issue discovered for 2243973120 B). For a shorter file iteration works as expected. File /tmp/2147483647zeros is 2^31 - 1 (< 2GiB) zero-bytes. >>> fh = open('/tmp/2147483647zeros', 'rb') >>> for line in fh: ... print len(line) 2147483647 I guess the variable used for size is of 32bit signed type. I am using Python 2.7.3 (default, Feb 27 2014, 19:58:35) with IPython 0.12.1 on Ubuntu 12.04.5 LTS. ---------- components: IO messages: 227949 nosy: Jakub.Mateusz.Kowalski priority: normal severity: normal status: open title: file iteration crashes for huge lines (2GiB+) type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 18:11:49 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 30 Sep 2014 16:11:49 +0000 Subject: [issue22448] call_at/call_later with Timer cancellation can result in (practically) unbounded memory usage. In-Reply-To: <1411172040.41.0.974691283228.issue22448@psf.upfronthosting.co.za> Message-ID: <20140930161142.75011.40425@mail.hg.python.org> Roundup Robot added the comment: New changeset b85ed8bb7523 by Victor Stinner in branch '3.4': Issue #22448: asyncio, cleanup _run_once(), only iterate once to remove delayed https://hg.python.org/cpython/rev/b85ed8bb7523 New changeset 8e9df3414185 by Victor Stinner in branch 'default': (Merge 3.4) Issue #22448: asyncio, cleanup _run_once(), only iterate once to https://hg.python.org/cpython/rev/8e9df3414185 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 18:12:11 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 30 Sep 2014 16:12:11 +0000 Subject: [issue22526] file iteration crashes for huge lines (2GiB+) In-Reply-To: <1412093451.75.0.0583026923325.issue22526@psf.upfronthosting.co.za> Message-ID: <1412093531.65.0.290131439718.issue22526@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 18:39:31 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 30 Sep 2014 16:39:31 +0000 Subject: [issue22525] ast.literal_eval() doesn't do what the documentation says In-Reply-To: <1412089039.94.0.626035759284.issue22525@psf.upfronthosting.co.za> Message-ID: <1412095171.54.0.862726632697.issue22525@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 18:57:23 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 30 Sep 2014 16:57:23 +0000 Subject: [issue19855] uuid._find_mac fails if an executable not in /sbin or /usr/sbin In-Reply-To: <1385910768.71.0.356029979861.issue19855@psf.upfronthosting.co.za> Message-ID: <1412096243.5.0.0371442318567.issue19855@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There was other bug fixes not applied to 3.2. Here is cumulated patch for issue16102, issue18784, issue11508, and issue19855. They have same severity as this issue. There is also issue22131 (not applied to 3.3) and issue9678 (in progress). ---------- Added file: http://bugs.python.org/file36763/uuid-3.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 19:08:24 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 30 Sep 2014 17:08:24 +0000 Subject: [issue22448] call_at/call_later with Timer cancellation can result in (practically) unbounded memory usage. In-Reply-To: <1411172040.41.0.974691283228.issue22448@psf.upfronthosting.co.za> Message-ID: <1412096904.94.0.608451039355.issue22448@psf.upfronthosting.co.za> Yury Selivanov added the comment: Victor, Here's an updated benchmark results: NUMBER_OF_TASKS 10000 ITERATIONS -> 2000 out of 2000 2 loops: 0.004267875499863294 1 loop: 0.007916624497738667 TOTAL_BENCH_TIME 15.975227117538452 NUMBER_OF_TASKS 100000 ITERATIONS -> 2000 out of 2000 2 loops: 0.04882345050100412 1 loop: 0.09141454550081107 TOTAL_BENCH_TIME 180.64003109931946 2 loops is always about 30-40% slower. I've updated the benchmark I used: https://gist.github.com/1st1/b38ac6785cb01a679722 Now it incorporates a call to heapify, and should yield more stable results. Please check it out, as I'm maybe doing something wrong there, but if it's alright, I think that you need to revert your commits. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 19:16:21 2014 From: report at bugs.python.org (Chris Adams) Date: Tue, 30 Sep 2014 17:16:21 +0000 Subject: [issue20164] Undocumented KeyError from os.path.expanduser In-Reply-To: <1389111327.1.0.12442170212.issue20164@psf.upfronthosting.co.za> Message-ID: <1412097381.22.0.767121386578.issue20164@psf.upfronthosting.co.za> Chris Adams added the comment: I agree that making the code match the docs would be preferable ? an unexpected KeyError might be easier to track down that way but it'd still surprise most developers. re:pwd docs, the formatting in https://hg.python.org/cpython/file/8e9df3414185/Doc/library/pwd.rst makes it easy to miss the KeyError note ? it's at the end of a paragraph after a table and since "entry" is a generic term it's possible to misread it as applying to fields within the record rather than the record itself. I think it would at least be worth adding a newline and perhaps explicitly noting that it applies to any function which returns a password database entry. Given that there are only two functions which it applies to, it might be best to simply add a note to each of them for people who use "pydoc pwd.getpwduid" or an IDE and don't see the module-level docs but that's getting a bit contrived. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 19:17:44 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 30 Sep 2014 17:17:44 +0000 Subject: [issue20374] Failure to compile with readline-6.3-rc1 In-Reply-To: <1390537610.1.0.747015129006.issue20374@psf.upfronthosting.co.za> Message-ID: <1412097464.68.0.983380890965.issue20374@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The readline module no longer compiled in 3.2. May be we should apply these patches to 3.2. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 19:29:30 2014 From: report at bugs.python.org (Ned Deily) Date: Tue, 30 Sep 2014 17:29:30 +0000 Subject: [issue20374] Failure to compile with readline-6.3-rc1 In-Reply-To: <1390537610.1.0.747015129006.issue20374@psf.upfronthosting.co.za> Message-ID: <1412098170.92.0.496616390124.issue20374@psf.upfronthosting.co.za> Ned Deily added the comment: This isn't a security issue and in general we do not make changes to branches in security-fix mode to support new releases of external components or operating system releases. There are plenty of other fixes that should be ported to 3.2 if we go down that path. So I'm closing this again unless Georg disagrees. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 19:29:54 2014 From: report at bugs.python.org (Georg Brandl) Date: Tue, 30 Sep 2014 17:29:54 +0000 Subject: [issue22525] ast.literal_eval() doesn't do what the documentation says In-Reply-To: <1412089039.94.0.626035759284.issue22525@psf.upfronthosting.co.za> Message-ID: <1412098194.27.0.896828717597.issue22525@psf.upfronthosting.co.za> Georg Brandl added the comment: I agree that the wording can be improved. The term "expression" is used here loosely, but should be clarified. "a+b" with numbers a, b must be handled in order to evaluate complex literals as in "1+1j". Allowing operator expressions with literals is possible, but much more complex than the current implementation. A simple implementation is not safe: you can induce basically unbounded CPU and memory usage with no effort (try "9**9**9" or "[None] * 9**9"). As for the usefulness, this function is useful to "read back" literal values and containers as stringified by repr(). This can for example be used for serialization in a format that is similar to but more powerful than JSON. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 19:34:49 2014 From: report at bugs.python.org (Georg Brandl) Date: Tue, 30 Sep 2014 17:34:49 +0000 Subject: [issue19855] uuid._find_mac fails if an executable not in /sbin or /usr/sbin In-Reply-To: <1385910768.71.0.356029979861.issue19855@psf.upfronthosting.co.za> Message-ID: <1412098489.15.0.368379809187.issue19855@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 19:34:51 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 30 Sep 2014 17:34:51 +0000 Subject: [issue18784] minor uuid.py loading optimization In-Reply-To: <1376934568.82.0.658591354908.issue18784@psf.upfronthosting.co.za> Message-ID: <20140930173445.23205.20170@mail.hg.python.org> Roundup Robot added the comment: New changeset f9cd915410d2 by Georg Brandl in branch '3.2': Issue #19855: uuid.getnode() on Unix now looks on the PATH for the https://hg.python.org/cpython/rev/f9cd915410d2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 19:34:51 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 30 Sep 2014 17:34:51 +0000 Subject: [issue11508] Virtual Interfaces cause uuid._find_mac to raise a ValueError under Linux In-Reply-To: <1300134691.76.0.567990674923.issue11508@psf.upfronthosting.co.za> Message-ID: <20140930173445.23205.27880@mail.hg.python.org> Roundup Robot added the comment: New changeset f9cd915410d2 by Georg Brandl in branch '3.2': Issue #19855: uuid.getnode() on Unix now looks on the PATH for the https://hg.python.org/cpython/rev/f9cd915410d2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 19:34:51 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 30 Sep 2014 17:34:51 +0000 Subject: [issue16102] uuid._netbios_getnode() is outdated In-Reply-To: <1349112809.97.0.499056156586.issue16102@psf.upfronthosting.co.za> Message-ID: <20140930173445.23205.83029@mail.hg.python.org> Roundup Robot added the comment: New changeset f9cd915410d2 by Georg Brandl in branch '3.2': Issue #19855: uuid.getnode() on Unix now looks on the PATH for the https://hg.python.org/cpython/rev/f9cd915410d2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 19:34:51 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 30 Sep 2014 17:34:51 +0000 Subject: [issue19855] uuid._find_mac fails if an executable not in /sbin or /usr/sbin In-Reply-To: <1385910768.71.0.356029979861.issue19855@psf.upfronthosting.co.za> Message-ID: <20140930173445.23205.16940@mail.hg.python.org> Roundup Robot added the comment: New changeset f9cd915410d2 by Georg Brandl in branch '3.2': Issue #19855: uuid.getnode() on Unix now looks on the PATH for the https://hg.python.org/cpython/rev/f9cd915410d2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 19:35:09 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 30 Sep 2014 17:35:09 +0000 Subject: [issue20374] Failure to compile with readline-6.3-rc1 In-Reply-To: <1390537610.1.0.747015129006.issue20374@psf.upfronthosting.co.za> Message-ID: <1412098509.38.0.946300844561.issue20374@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: +1 for backporting build fixes for major platforms (e.g. fix for this issue). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 19:37:15 2014 From: report at bugs.python.org (Behdad Esfahbod) Date: Tue, 30 Sep 2014 17:37:15 +0000 Subject: [issue22525] ast.literal_eval() doesn't do what the documentation says In-Reply-To: <1412089039.94.0.626035759284.issue22525@psf.upfronthosting.co.za> Message-ID: <1412098635.39.0.140201793271.issue22525@psf.upfronthosting.co.za> Behdad Esfahbod added the comment: I think it should be made much more clear that this is not a blanket "safe eval() replacement". Re complex literals, note that Python 2.7.x only implemented the binary plus operator if the second argument was complex. This seems to have been relaxed in Python 3. Regarding DoS attack with a safe eval(), I understand the concern, but that's still a huge improvement over security risks of eval(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 19:37:57 2014 From: report at bugs.python.org (Georg Brandl) Date: Tue, 30 Sep 2014 17:37:57 +0000 Subject: [issue20374] Failure to compile with readline-6.3-rc1 In-Reply-To: <1390537610.1.0.747015129006.issue20374@psf.upfronthosting.co.za> Message-ID: <1412098676.99.0.901121667476.issue20374@psf.upfronthosting.co.za> Georg Brandl added the comment: I agree with Ned. 3.2 is not maintained anymore, we only provide security fixes. (Exceptions prove the rule. One exception I committed today was to stop test_urllibnet from failing, so that I could better see real failures on the buildbots.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 19:40:31 2014 From: report at bugs.python.org (Georg Brandl) Date: Tue, 30 Sep 2014 17:40:31 +0000 Subject: [issue22525] ast.literal_eval() doesn't do what the documentation says In-Reply-To: <1412089039.94.0.626035759284.issue22525@psf.upfronthosting.co.za> Message-ID: <1412098831.08.0.82619239068.issue22525@psf.upfronthosting.co.za> Georg Brandl added the comment: The function is still called literal_eval(), not safe_eval(). I'm not saying a safe eval() isn't useful. But an implementation that is only partly safe is not going to help anyone. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 19:44:25 2014 From: report at bugs.python.org (Georg Brandl) Date: Tue, 30 Sep 2014 17:44:25 +0000 Subject: [issue22525] ast.literal_eval() doesn't do what the documentation says In-Reply-To: <1412089039.94.0.626035759284.issue22525@psf.upfronthosting.co.za> Message-ID: <1412099065.66.0.508005111777.issue22525@psf.upfronthosting.co.za> Georg Brandl added the comment: Attaching proposed doc change. ---------- keywords: +patch Added file: http://bugs.python.org/file36764/ast_literal_eval_clarify.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 19:47:32 2014 From: report at bugs.python.org (Behdad Esfahbod) Date: Tue, 30 Sep 2014 17:47:32 +0000 Subject: [issue22525] ast.literal_eval() doesn't do what the documentation says In-Reply-To: <1412089039.94.0.626035759284.issue22525@psf.upfronthosting.co.za> Message-ID: <1412099252.53.0.4739406377.issue22525@psf.upfronthosting.co.za> Behdad Esfahbod added the comment: Thanks. In your proposed text: + Safely evaluate an expression node or a string containing a Python literal or container display. I suggest changing it to "...containing a single Python literal or..." Ie, adding "single". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 20:23:44 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 30 Sep 2014 18:23:44 +0000 Subject: [issue22448] call_at/call_later with Timer cancellation can result in (practically) unbounded memory usage. In-Reply-To: <1411172040.41.0.974691283228.issue22448@psf.upfronthosting.co.za> Message-ID: <1412101424.83.0.75328524029.issue22448@psf.upfronthosting.co.za> Yury Selivanov added the comment: typo: > 2 loops is always about 30-40% slower. 2 loops is always about 30-40% faster. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 20:30:53 2014 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 30 Sep 2014 18:30:53 +0000 Subject: [issue9417] Declaring a class creates circular references In-Reply-To: <1280413185.92.0.0897116981748.issue9417@psf.upfronthosting.co.za> Message-ID: <1412101853.21.0.610308809011.issue9417@psf.upfronthosting.co.za> Mark Lawrence added the comment: Does anyone wish to take this forward, is it simply dead in the water or what? You might like to note that msg111963 refers to #812369 which was superseded by #18214 which was fixed in 3.4. ---------- nosy: +BreamoreBoy versions: +Python 3.5 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 20:35:19 2014 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 30 Sep 2014 18:35:19 +0000 Subject: [issue993766] bdist_dumb and --relative on Windows fails Message-ID: <1412102119.28.0.0485009888814.issue993766@psf.upfronthosting.co.za> Mark Lawrence added the comment: Is this still a problem? Normally I'd be perfectly happy to try something on Windows but the mere mention of distutils sends shivers down my spine :( ---------- components: +Windows nosy: +BreamoreBoy, dstufft, eric.araujo versions: +Python 3.4, Python 3.5 -Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 20:39:04 2014 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 30 Sep 2014 18:39:04 +0000 Subject: [issue8041] No documentation for Py_TPFLAGS_HAVE_STACKLESS_EXTENSION or Py_TPFLAGS_HAVE_VERSION_TAG. In-Reply-To: <1267544098.65.0.440493208051.issue8041@psf.upfronthosting.co.za> Message-ID: <1412102344.0.0.072558211615.issue8041@psf.upfronthosting.co.za> Mark Lawrence added the comment: @Daniel could you supply a patch for this? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 20:44:44 2014 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 30 Sep 2014 18:44:44 +0000 Subject: [issue17873] _ctypes/libffi missing bits for aarch64 support In-Reply-To: <1367276723.56.0.050997158172.issue17873@psf.upfronthosting.co.za> Message-ID: <1412102684.6.0.610175847485.issue17873@psf.upfronthosting.co.za> Mark Lawrence added the comment: The patch is a one line addition to fficonfig.py.in, could someone glance at it please. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 20:49:23 2014 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 30 Sep 2014 18:49:23 +0000 Subject: [issue18675] Daemon Threads can seg fault In-Reply-To: <1375867396.76.0.697227657582.issue18675@psf.upfronthosting.co.za> Message-ID: <1412102963.45.0.689745242911.issue18675@psf.upfronthosting.co.za> Mark Lawrence added the comment: @Thomas can you provide a patch for this issue? ---------- nosy: +BreamoreBoy versions: -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 20:51:16 2014 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 30 Sep 2014 18:51:16 +0000 Subject: [issue18711] Add PyErr_FormatV In-Reply-To: <1376311803.97.0.992272560955.issue18711@psf.upfronthosting.co.za> Message-ID: <1412103076.85.0.739425589407.issue18711@psf.upfronthosting.co.za> Mark Lawrence added the comment: Just a gentle reminder guys. ---------- nosy: +BreamoreBoy versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 20:51:34 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 30 Sep 2014 18:51:34 +0000 Subject: [issue22448] call_at/call_later with Timer cancellation can result in (practically) unbounded memory usage. In-Reply-To: <1412101424.83.0.75328524029.issue22448@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Hum you don't reset start between the two benchmarks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 20:55:18 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 30 Sep 2014 18:55:18 +0000 Subject: [issue22448] call_at/call_later with Timer cancellation can result in (practically) unbounded memory usage. In-Reply-To: <1411172040.41.0.974691283228.issue22448@psf.upfronthosting.co.za> Message-ID: <1412103318.49.0.25122400997.issue22448@psf.upfronthosting.co.za> Yury Selivanov added the comment: Eh, I knew something was wrong. Thanks. NUMBER_OF_TASKS 100000 ITERATIONS -> 2000 out of 2000 2 loops: 0.045037232999675325 1 loop: 0.045182990999819594 TOTAL_BENCH_TIME 91.36706805229187 Please commit your change to the tulip repo too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 20:56:36 2014 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 30 Sep 2014 18:56:36 +0000 Subject: [issue18729] In unittest.TestLoader.discover doc select the name of load_tests function In-Reply-To: <1376418287.73.0.835584535115.issue18729@psf.upfronthosting.co.za> Message-ID: <1412103396.47.0.703215771865.issue18729@psf.upfronthosting.co.za> Mark Lawrence added the comment: The patch simply adds backticks markup around load_tests. ---------- nosy: +BreamoreBoy versions: +Python 3.5 -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 20:58:08 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 30 Sep 2014 18:58:08 +0000 Subject: [issue22448] call_at/call_later with Timer cancellation can result in (practically) unbounded memory usage. In-Reply-To: <1411172040.41.0.974691283228.issue22448@psf.upfronthosting.co.za> Message-ID: <1412103488.3.0.830988839756.issue22448@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 21:01:41 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 30 Sep 2014 19:01:41 +0000 Subject: [issue22527] Documentation warnings Message-ID: <1412103701.09.0.111850399137.issue22527@psf.upfronthosting.co.za> New submission from Antoine Pitrou: I get the following warnings when building the doc: $ make html sphinx-build -b html -d build/doctrees -D latex_paper_size= . build/html Running Sphinx v1.2.1 loading pickled environment... done building [html]: targets for 65 source files that are out of date updating environment: 1 added, 66 changed, 0 removed reading sources... [100%] whatsnew/changelog /home/antoine/cpython/default/Doc/library/compileall.rst:23: WARNING: Malformed option description u'directory ...', should look like "-opt args", "--opt args" or "/opt args" /home/antoine/cpython/default/Doc/library/compileall.rst:23: WARNING: Malformed option description u'file ...', should look like "-opt args", "--opt args" or "/opt args" /home/antoine/cpython/default/Doc/library/json.rst:593: WARNING: Malformed option description u'infile', should look like "-opt args", "--opt args" or "/opt args" /home/antoine/cpython/default/Doc/library/json.rst:611: WARNING: Malformed option description u'outfile', should look like "-opt args", "--opt args" or "/opt args" /home/antoine/cpython/default/Doc/tutorial/appendix.rst:69: WARNING: duplicate label tut-startup, other instance in /home/antoine/cpython/default/Doc/tutorial/interpreter.rst /home/antoine/cpython/default/Doc/tutorial/appendix.rst:16: WARNING: duplicate label tut-error, other instance in /home/antoine/cpython/default/Doc/tutorial/interpreter.rst /home/antoine/cpython/default/Doc/tutorial/appendix.rst:102: WARNING: duplicate label tut-customize, other instance in /home/antoine/cpython/default/Doc/tutorial/interpreter.rst /home/antoine/cpython/default/Doc/tutorial/appendix.rst:38: WARNING: duplicate label tut-scripts, other instance in /home/antoine/cpython/default/Doc/tutorial/interpreter.rst /home/antoine/cpython/default/Doc/using/cmdline.rst:167: WARNING: Malformed option description u'-?', should look like "-opt args", "--opt args" or "/opt args" ---------- assignee: docs at python components: Documentation messages: 227978 nosy: docs at python, pitrou priority: normal severity: normal status: open title: Documentation warnings type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 21:16:53 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 30 Sep 2014 19:16:53 +0000 Subject: [issue18711] Add PyErr_FormatV In-Reply-To: <1376311803.97.0.992272560955.issue18711@psf.upfronthosting.co.za> Message-ID: <20140930191633.74987.3372@mail.hg.python.org> Roundup Robot added the comment: New changeset 5629481cd26d by Antoine Pitrou in branch 'default': Issue #18711: Add a new `PyErr_FormatV` function, similar to `PyErr_Format` but accepting a `va_list` argument. https://hg.python.org/cpython/rev/5629481cd26d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 21:21:24 2014 From: report at bugs.python.org (Georg Brandl) Date: Tue, 30 Sep 2014 19:21:24 +0000 Subject: [issue22527] Documentation warnings In-Reply-To: <1412103701.09.0.111850399137.issue22527@psf.upfronthosting.co.za> Message-ID: <1412104884.91.0.679941290971.issue22527@psf.upfronthosting.co.za> Georg Brandl added the comment: These are a bug in Sphinx 1.2.1 and fixed in 1.2.2. ---------- nosy: +georg.brandl resolution: -> third party status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 21:22:00 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 30 Sep 2014 19:22:00 +0000 Subject: [issue16038] ftplib: unlimited readline() from connection In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za> Message-ID: <1412104920.83.0.389863437417.issue16038@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 21:22:31 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 30 Sep 2014 19:22:31 +0000 Subject: [issue18747] Re-seed OpenSSL's PRNG after fork In-Reply-To: <1376570101.71.0.249202475923.issue18747@psf.upfronthosting.co.za> Message-ID: <1412104951.52.0.923910687647.issue18747@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: commit review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 21:24:26 2014 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 30 Sep 2014 19:24:26 +0000 Subject: [issue19133] Transient test failure: test_with_statement (test_ftplib) In-Reply-To: <1380533250.94.0.739399137718.issue19133@psf.upfronthosting.co.za> Message-ID: <1412105066.2.0.7104534031.issue19133@psf.upfronthosting.co.za> Mark Lawrence added the comment: I'm not sure what machine I'm meant to be looking at but is this still a problem one year on? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 21:26:52 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 30 Sep 2014 19:26:52 +0000 Subject: [issue22472] OSErrors should use str and not repr on paths In-Reply-To: <1411504485.58.0.497867466453.issue22472@psf.upfronthosting.co.za> Message-ID: <1412105212.0.0.440206083525.issue22472@psf.upfronthosting.co.za> R. David Murray added the comment: OK, so I have to add a filter to my logger that looks for a filename attribute on exceptions and and if it finds one...does what? How do I reconstruct an arbitrary OSError error message using the filename parameter? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 21:27:00 2014 From: report at bugs.python.org (Thomas Guettler) Date: Tue, 30 Sep 2014 19:27:00 +0000 Subject: [issue18675] Daemon Threads can seg fault In-Reply-To: <1375867396.76.0.697227657582.issue18675@psf.upfronthosting.co.za> Message-ID: <1412105220.24.0.219918488339.issue18675@psf.upfronthosting.co.za> Thomas Guettler added the comment: What kind of patch do you want? Documentation patch or fixing the bug in the interpreter? I am not a native speaker, that's why I avoid documentation patches. For me, the issue is solved. It is documented in stackoverflow and here. Since Python2 will be gone sooner or later, I don't want to invest hours into fixing this at interpreter level. Should I close the issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 21:29:23 2014 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 30 Sep 2014 19:29:23 +0000 Subject: [issue19071] Documentation on what self is for module-level functions is misleading/wrong. In-Reply-To: <1379849996.18.0.35390897499.issue19071@psf.upfronthosting.co.za> Message-ID: <1412105363.29.0.0467227373091.issue19071@psf.upfronthosting.co.za> Mark Lawrence added the comment: At this stage is this something that we'd want to back port or fix in 2.7 or would a doc change suffice? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 21:30:52 2014 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 30 Sep 2014 19:30:52 +0000 Subject: [issue19113] duplicate test names in Lib/ctypes/test/test_functions.py In-Reply-To: <1380385419.52.0.767012097586.issue19113@psf.upfronthosting.co.za> Message-ID: <1412105452.92.0.148586462925.issue19113@psf.upfronthosting.co.za> Mark Lawrence added the comment: @Xavier can you provide a patch for this issue? ---------- nosy: +BreamoreBoy versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 21:33:20 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 30 Sep 2014 19:33:20 +0000 Subject: [issue22525] ast.literal_eval() doesn't do what the documentation says In-Reply-To: <1412089039.94.0.626035759284.issue22525@psf.upfronthosting.co.za> Message-ID: <1412105600.02.0.956038671831.issue22525@psf.upfronthosting.co.za> R. David Murray added the comment: It should probably also say "or a container display containing only literals". (That's a lot of "contain" :) (I had the same confusion the first time I read these docs, BTW). ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 21:35:10 2014 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 30 Sep 2014 19:35:10 +0000 Subject: [issue17219] cross add Python's library directory when building python standard extensions In-Reply-To: <1361119360.59.0.341690353599.issue17219@psf.upfronthosting.co.za> Message-ID: <1412105710.9.0.64732278335.issue17219@psf.upfronthosting.co.za> Mark Lawrence added the comment: The patch is a one line change to distutils/command/build_ext.py. Can we have the stage set and a patch review done please, distutils is black magic to me. ---------- components: +Distutils nosy: +BreamoreBoy, dstufft, eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 21:35:13 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 30 Sep 2014 19:35:13 +0000 Subject: [issue22526] file iteration SystemError for huge lines (2GiB+) In-Reply-To: <1412093451.75.0.0583026923325.issue22526@psf.upfronthosting.co.za> Message-ID: <1412105713.28.0.928569325778.issue22526@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- title: file iteration crashes for huge lines (2GiB+) -> file iteration SystemError for huge lines (2GiB+) type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 21:40:24 2014 From: report at bugs.python.org (Georg Brandl) Date: Tue, 30 Sep 2014 19:40:24 +0000 Subject: [issue22525] ast.literal_eval() doesn't do what the documentation says In-Reply-To: <1412089039.94.0.626035759284.issue22525@psf.upfronthosting.co.za> Message-ID: <1412106024.27.0.68880969701.issue22525@psf.upfronthosting.co.za> Georg Brandl added the comment: Sure, feel free to reword. An example or two might also be helpful. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 21:45:40 2014 From: report at bugs.python.org (Friedrich Spee von Langenfeld) Date: Tue, 30 Sep 2014 19:45:40 +0000 Subject: [issue22528] Missing hint to source code Message-ID: <1412106340.24.0.431957287455.issue22528@psf.upfronthosting.co.za> New submission from Friedrich Spee von Langenfeld: Nearly every module entry in the documentation has a headline with the pattern , followed (in the second line) by . In the entry concerning pdb (https://docs.python.org/3/library/pdb.html), there is no hint where the source code is located. This is especially annoying, because the user of the Python Debugger is explicitely invented to extend the module?s capabilities ("The debugger is extensible ? it is actually defined as the class Pdb. This is currently undocumented but easily understood by reading the source."). A link to the source code should be added as the second line. The same thing should done for symtable, compileall and perhaps some other modules, which I haven?t checked by now. ---------- assignee: docs at python components: Documentation messages: 227989 nosy: Friedrich.Spee.von.Langenfeld, docs at python priority: normal severity: normal status: open title: Missing hint to source code _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 21:53:28 2014 From: report at bugs.python.org (Friedrich Spee von Langenfeld) Date: Tue, 30 Sep 2014 19:53:28 +0000 Subject: [issue22529] Why copyright only 1990-2013 and not 2014 Message-ID: <1412106808.33.0.959231434867.issue22529@psf.upfronthosting.co.za> New submission from Friedrich Spee von Langenfeld: In the legal statements (https://www.python.org/about/legal) you can read the following sentence: "[...] the contents of this website are copyright ? 1990-2013, Python Software Foundation, [...]". Why is the year 2014 not covered? The message "Copyright ? 1990-2013" is shown at the bottom of all pages which I?ve read as yet in the Issue Tracker. Only on the main website (www.python.org), the website with the Legal Statements mentioned before and perhaps some other sides, the copyright notice includes the year 2014 ---------- messages: 227990 nosy: Friedrich.Spee.von.Langenfeld priority: normal severity: normal status: open title: Why copyright only 1990-2013 and not 2014 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 21:56:34 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 30 Sep 2014 19:56:34 +0000 Subject: [issue18711] Add PyErr_FormatV In-Reply-To: <1376311803.97.0.992272560955.issue18711@psf.upfronthosting.co.za> Message-ID: <1412106993.99.0.723795447922.issue18711@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks for the reminder. Pushed! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 21:59:37 2014 From: report at bugs.python.org (Patrice LACOUTURE) Date: Tue, 30 Sep 2014 19:59:37 +0000 Subject: [issue993766] bdist_dumb and --relative on Windows fails Message-ID: <1412107177.27.0.9124584042.issue993766@psf.upfronthosting.co.za> Patrice LACOUTURE added the comment: I don't have any Windows box around to check, but I can see that there has been no change since then in this portion of code in branches 2.4, 2.7 and 3.4. Therefore, this issue is very likely still there. ---------- nosy: +PatriceL _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 22:02:39 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 30 Sep 2014 20:02:39 +0000 Subject: [issue22528] Missing hint to source code In-Reply-To: <1412106340.24.0.431957287455.issue22528@psf.upfronthosting.co.za> Message-ID: <20140930200231.23199.30926@mail.hg.python.org> Roundup Robot added the comment: New changeset 04f82abdfb6d by Benjamin Peterson in branch '3.4': add link to pdb source (closes #22528) https://hg.python.org/cpython/rev/04f82abdfb6d New changeset d49b9c8ee8ed by Benjamin Peterson in branch '2.7': add link to pdb source (closes #22528) https://hg.python.org/cpython/rev/d49b9c8ee8ed New changeset 26b767fec7e2 by Benjamin Peterson in branch 'default': merge 3.4 (#22528) https://hg.python.org/cpython/rev/26b767fec7e2 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 22:26:07 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 30 Sep 2014 20:26:07 +0000 Subject: [issue21963] 2.7.8 backport of Issue1856 (avoid daemon thread problems at shutdown) breaks ceph In-Reply-To: <1405112765.87.0.0636941236839.issue21963@psf.upfronthosting.co.za> Message-ID: <1412108767.79.0.927019171435.issue21963@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I would favour reverting. The crashiness of daemon threads is not new, so fixing it late in the 2.7 cycle wasn't really necessary IMO. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 22:28:55 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 30 Sep 2014 20:28:55 +0000 Subject: [issue21963] 2.7.8 backport of Issue1856 (avoid daemon thread problems at shutdown) breaks ceph In-Reply-To: <1405112765.87.0.0636941236839.issue21963@psf.upfronthosting.co.za> Message-ID: <1412108935.77.0.928114013939.issue21963@psf.upfronthosting.co.za> Antoine Pitrou added the comment: As a sidenote, I wonder if the Ceph issue would also occur on 3.x. I guess we won't know until Ceph is ported (is it?). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 22:32:48 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 30 Sep 2014 20:32:48 +0000 Subject: [issue21963] 2.7.8 backport of Issue1856 (avoid daemon thread problems at shutdown) breaks ceph In-Reply-To: <1405112765.87.0.0636941236839.issue21963@psf.upfronthosting.co.za> Message-ID: <1412109168.31.0.0689236560033.issue21963@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Note that this may very well be a bug in Ceph... Is any of the Ceph authors nosied here? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 22:58:01 2014 From: report at bugs.python.org (Ned Deily) Date: Tue, 30 Sep 2014 20:58:01 +0000 Subject: [issue22529] Why copyright only 1990-2013 and not 2014 In-Reply-To: <1412106808.33.0.959231434867.issue22529@psf.upfronthosting.co.za> Message-ID: <1412110681.64.0.814013116944.issue22529@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the report. However, as noted on the python.org web site help page, https://www.python.org/about/help/, the place to report web site problems is here: https://github.com/python/pythondotorg/issues/. Please check the issue tracker there and open an issue as necessary. ---------- nosy: +ned.deily resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 23:06:16 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 30 Sep 2014 21:06:16 +0000 Subject: [issue17873] _ctypes/libffi missing bits for aarch64 support In-Reply-To: <1367276723.56.0.050997158172.issue17873@psf.upfronthosting.co.za> Message-ID: <1412111176.66.0.426548290336.issue17873@psf.upfronthosting.co.za> STINNER Victor added the comment: The patch should be sent upstream: https://sourceware.org/libffi/ ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 23:07:42 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 30 Sep 2014 21:07:42 +0000 Subject: [issue17873] _ctypes/libffi missing bits for aarch64 support In-Reply-To: <1367276723.56.0.050997158172.issue17873@psf.upfronthosting.co.za> Message-ID: <1412111262.65.0.23936518406.issue17873@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +amaury.forgeotdarc, belopolsky, meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 23:12:54 2014 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 30 Sep 2014 21:12:54 +0000 Subject: [issue7436] Define 'object with assignable attributes' In-Reply-To: <1259961781.03.0.33355289278.issue7436@psf.upfronthosting.co.za> Message-ID: <1412111574.91.0.769182101504.issue7436@psf.upfronthosting.co.za> Mark Lawrence added the comment: @Terry can you pick this one up? ---------- nosy: +BreamoreBoy versions: +Python 3.4, Python 3.5 -Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 23:13:04 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 30 Sep 2014 21:13:04 +0000 Subject: [issue22397] test_socket failure on AIX In-Reply-To: <1410547453.79.0.287492326275.issue22397@psf.upfronthosting.co.za> Message-ID: <1412111584.01.0.145530977153.issue22397@psf.upfronthosting.co.za> STINNER Victor added the comment: Current test_socket failures on PPC64 AIX 3.x buildbot: http://buildbot.python.org/all/builders/PPC64%20AIX%203.x/builds/2672/steps/test/logs/stdio ====================================================================== ERROR: testFDPassSeparateMinSpace (test.test_socket.RecvmsgSCMRightsStreamTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 266, in _tearDown raise exc File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 278, in clientRun test_func() File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 2778, in _testFDPassSeparateMinSpace array.array("i", [fd1]))]), File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 1896, in sendmsgToServer *(args + self.sendmsg_to_server_defaults[len(args):])) OSError: [Errno 22] Invalid argument ====================================================================== ERROR: testFDPassSeparate (test.test_socket.RecvmsgIntoSCMRightsStreamTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 266, in _tearDown raise exc File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 278, in clientRun test_func() File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 2754, in _testFDPassSeparate array.array("i", [fd1]))]), File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 1896, in sendmsgToServer *(args + self.sendmsg_to_server_defaults[len(args):])) OSError: [Errno 22] Invalid argument ====================================================================== ERROR: testFDPassSeparateMinSpace (test.test_socket.RecvmsgIntoSCMRightsStreamTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 266, in _tearDown raise exc File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 278, in clientRun test_func() File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 2778, in _testFDPassSeparateMinSpace array.array("i", [fd1]))]), File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 1896, in sendmsgToServer *(args + self.sendmsg_to_server_defaults[len(args):])) OSError: [Errno 22] Invalid argument ====================================================================== FAIL: testIPv4toString (test.test_socket.GeneralModuleTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 976, in testIPv4toString assertInvalid(f, '0.0.0.') File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 968, in (OSError, ValueError), func, a AssertionError: (, ) not raised by inet_aton ====================================================================== FAIL: testIPv6toString (test.test_socket.GeneralModuleTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 1033, in testIPv6toString assertInvalid('1:2:3:4:5:6:7:8:') File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 1011, in (OSError, ValueError), f, a AssertionError: (, ) not raised by ====================================================================== FAIL: testFDPassSeparate (test.test_socket.RecvmsgSCMRightsStreamTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 2742, in testFDPassSeparate maxcmsgs=2) File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 2669, in checkRecvmsgFDs self.assertEqual(msg, MSG) AssertionError: b'' != b'Michael Gilfix was here\xe1\x88\xb4\r\n' ====================================================================== FAIL: testFDPassSeparateMinSpace (test.test_socket.RecvmsgSCMRightsStreamTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 2766, in testFDPassSeparateMinSpace maxcmsgs=2, ignoreflags=socket.MSG_CTRUNC) File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 2669, in checkRecvmsgFDs self.assertEqual(msg, MSG) AssertionError: b'' != b'Michael Gilfix was here\xe1\x88\xb4\r\n' ====================================================================== FAIL: testFDPassSeparate (test.test_socket.RecvmsgIntoSCMRightsStreamTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 2742, in testFDPassSeparate maxcmsgs=2) File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 2669, in checkRecvmsgFDs self.assertEqual(msg, MSG) AssertionError: b'' != b'Michael Gilfix was here\xe1\x88\xb4\r\n' ====================================================================== FAIL: testFDPassSeparateMinSpace (test.test_socket.RecvmsgIntoSCMRightsStreamTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 2766, in testFDPassSeparateMinSpace maxcmsgs=2, ignoreflags=socket.MSG_CTRUNC) File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 2669, in checkRecvmsgFDs self.assertEqual(msg, MSG) AssertionError: b'' != b'Michael Gilfix was here\xe1\x88\xb4\r\n' Ran 528 tests in 35.259s FAILED (failures=6, errors=4, skipped=94) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 23:14:19 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 30 Sep 2014 21:14:19 +0000 Subject: [issue17873] _ctypes/libffi missing bits for aarch64 support In-Reply-To: <1367276723.56.0.050997158172.issue17873@psf.upfronthosting.co.za> Message-ID: <1412111659.51.0.648081957292.issue17873@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I don't think fficonfig.py.in is from upstream. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 23:16:31 2014 From: report at bugs.python.org (Andreas Schwab) Date: Tue, 30 Sep 2014 21:16:31 +0000 Subject: [issue17873] _ctypes/libffi missing bits for aarch64 support In-Reply-To: <1367276723.56.0.050997158172.issue17873@psf.upfronthosting.co.za> Message-ID: <1412111791.43.0.971404491347.issue17873@psf.upfronthosting.co.za> Andreas Schwab added the comment: fficonfig.py.in isn't part of upstream. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 23:18:58 2014 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 30 Sep 2014 21:18:58 +0000 Subject: [issue11023] pep 227 missing text In-Reply-To: <1296134235.25.0.738218358402.issue11023@psf.upfronthosting.co.za> Message-ID: <1412111938.11.0.863417969876.issue11023@psf.upfronthosting.co.za> Mark Lawrence added the comment: PEP 227 (Not 277 as wrongly quoted in one place) is about Statically Nested Scopes. There are several XXX place holders in the current doc. For all I know it would be possible to simply remove all of them, but who is best placed to give a definitive answer? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 23:29:42 2014 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 30 Sep 2014 21:29:42 +0000 Subject: [issue7574] PyUnicode_FromFormat broken and not documented for 2.x In-Reply-To: <1261655681.25.0.454963458841.issue7574@psf.upfronthosting.co.za> Message-ID: <1412112582.11.0.161025192021.issue7574@psf.upfronthosting.co.za> Mark Lawrence added the comment: With Stage "resolved" and Resolution "duplicate" surely this can be closed? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 23:33:34 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 30 Sep 2014 21:33:34 +0000 Subject: [issue22397] test_socket failure on AIX In-Reply-To: <1410547453.79.0.287492326275.issue22397@psf.upfronthosting.co.za> Message-ID: <1412112814.06.0.458470847223.issue22397@psf.upfronthosting.co.za> STINNER Victor added the comment: Failing tests: * testFDPassSeparateMinSpace (test.test_socket.RecvmsgSCMRightsStreamTest) * testFDPassSeparate (test.test_socket.RecvmsgIntoSCMRightsStreamTest) * testFDPassSeparateMinSpace (test.test_socket.RecvmsgIntoSCMRightsStreamTest) * testFDPassSeparate (test.test_socket.RecvmsgSCMRightsStreamTest) * testFDPassSeparateMinSpace (test.test_socket.RecvmsgSCMRightsStreamTest) * testFDPassSeparate (test.test_socket.RecvmsgIntoSCMRightsStreamTest) * testFDPassSeparateMinSpace (test.test_socket.RecvmsgIntoSCMRightsStreamTest) It looks like the failure come from code like: self.sendmsgToServer([MSG], [(socket.SOL_SOCKET, socket.SCM_RIGHTS, array.array("i", [fd0])), and self.doRecvmsg(self.serv_sock, len(MSG), socket.CMSG_SPACE(SIZEOF_INT) + socket.CMSG_LEN(SIZEOF_INT)), In clear, there are errors on tests sending file descriptors through UNIX sockets. So this issue is a duplicate of #20718, but we may keep this one for AIX, and #20718 for OpenBSD. It looks possible to send a file descriptor between processes but using a pipe with I_SENDFD and I_RECVFD ioctl. See: http://www-01.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.commtrf2/I_SENDFD.htm http://www-01.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.commtrf2/I_RECVFD.htm http://search.cpan.org/~fractal/AnyEvent-FDpasser-0.3.0/lib/AnyEvent/FDpasser.pm ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 23:33:44 2014 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 30 Sep 2014 21:33:44 +0000 Subject: [issue10384] SyntaxError should contain exact location of the invalid character in identifier In-Reply-To: <1289439285.11.0.506002899946.issue10384@psf.upfronthosting.co.za> Message-ID: <1412112824.63.0.324497310835.issue10384@psf.upfronthosting.co.za> Mark Lawrence added the comment: #10382 has been closed in favour of #2382. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 23:38:01 2014 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 30 Sep 2014 21:38:01 +0000 Subject: [issue10349] Error in Module/python.c when building on OpenBSD 4.8 In-Reply-To: <1289199143.28.0.506984185363.issue10349@psf.upfronthosting.co.za> Message-ID: <1412113081.72.0.330492759384.issue10349@psf.upfronthosting.co.za> Mark Lawrence added the comment: Is this out of date as the only buildbot I could find is running OpenBSD 5.5? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 23:44:00 2014 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 30 Sep 2014 21:44:00 +0000 Subject: [issue6320] Standard string encodings should include GSM0.38 In-Reply-To: <1245612481.83.0.685402230855.issue6320@psf.upfronthosting.co.za> Message-ID: <1412113440.76.0.633149445519.issue6320@psf.upfronthosting.co.za> Mark Lawrence added the comment: @jwishnie can you provide a patch for this, as without it the issue goes nowhere? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 23:45:28 2014 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 30 Sep 2014 21:45:28 +0000 Subject: [issue5843] Normalization error in urlunparse In-Reply-To: <1240686759.57.0.0410680082249.issue5843@psf.upfronthosting.co.za> Message-ID: <1412113528.89.0.948837797599.issue5843@psf.upfronthosting.co.za> Mark Lawrence added the comment: Slipped under the radar guys? ---------- nosy: +BreamoreBoy versions: +Python 3.4, Python 3.5 -Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 30 23:47:20 2014 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 30 Sep 2014 21:47:20 +0000 Subject: [issue10328] re.sub[n] doesn't seem to handle /Z replacements correctly in all cases In-Reply-To: <1288967628.79.0.550964963089.issue10328@psf.upfronthosting.co.za> Message-ID: <1412113640.94.0.320709729222.issue10328@psf.upfronthosting.co.za> Mark Lawrence added the comment: @Serhiy can you take a look at this as I recall you've been doing some regex work? ---------- nosy: +BreamoreBoy, serhiy.storchaka versions: +Python 3.4, Python 3.5 -Python 3.1 _______________________________________ Python tracker _______________________________________