From report at bugs.python.org Wed Aug 1 00:00:54 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 31 Jul 2012 22:00:54 +0000 Subject: [issue15510] textwrap.wrap('') returns empty list In-Reply-To: <1343697979.41.0.629576632811.issue15510@psf.upfronthosting.co.za> Message-ID: <1343772054.62.0.636291507613.issue15510@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Actually, here is a slightly more benign version of the patch. This patch makes the change in the wrap() method and leaves _wrap_chunks() alone. This is less intrusive because it doesn't change the behavior of _wrap_chunks(), which some people might be calling if they are subclassing TextWrapper and accessing the private API directly. ---------- Added file: http://bugs.python.org/file26630/issue-15510-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 00:08:23 2012 From: report at bugs.python.org (Taihyun Hwang) Date: Tue, 31 Jul 2012 22:08:23 +0000 Subject: [issue15517] Minor trimming for ASDL parser Message-ID: <1343772503.75.0.788965811369.issue15517@psf.upfronthosting.co.za> New submission from Taihyun Hwang: Attached patch enables ASDL parser to construct fields in the right order. It resolves the issue below in Parser/asdl.py # XXX can't I just construct things in the right order? We can safely use left-recursive grammar since Parser/spark.py implements Earley parser. The patch doesn't affect Python-ast.[ch] as expected. $ make Include/Python-ast.h Python/Python-ast.c $ diff -s ~/test/Python-ast.h Include/Python-ast.h Files /home/xenosoz/test/Python-ast.h and Include/Python-ast.h are identical $ diff -s ~/test/Python-ast.c Python/Python-ast.c Files /home/xenosoz/test/Python-ast.c and Python/Python-ast.c are identical Time consumption before/after the patch: -- before patch -- time make Include/Python-ast.h real 0m0.578s \ user 0m0.500s \ sys 0m0.060s time make Python/Python-ast.c real 0m0.687s \ user 0m0.620s \ sys 0m0.050s -- after patch -- $ time make Include/Python-ast.h real 0m0.588s \ user 0m0.510s \ sys 0m0.060s $ time make Python/Python-ast.c real 0m0.677s \ user 0m0.630s \ sys 0m0.030s It touches: Misc/ACKS Parser/asdl.py ---------- components: Interpreter Core files: asdl1.patch keywords: patch messages: 167056 nosy: taihyun.hwang priority: normal severity: normal status: open title: Minor trimming for ASDL parser type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file26631/asdl1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 00:09:28 2012 From: report at bugs.python.org (Stefan Krah) Date: Tue, 31 Jul 2012 22:09:28 +0000 Subject: [issue8847] crash appending list and namedtuple In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za> Message-ID: <1343772568.37.0.883579120867.issue8847@psf.upfronthosting.co.za> Stefan Krah added the comment: New patches with tests for 3.2 and 3.3. For 3.2 I determined empirically that EnableCOMDATFolding="1" (and not "0") turns on NOICF. If anyone can confirm that this is the case or has a pointer to the relevant vcproj docs, I'd be thrilled. ---------- Added file: http://bugs.python.org/file26632/issue8847-3.3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 00:09:47 2012 From: report at bugs.python.org (Stefan Krah) Date: Tue, 31 Jul 2012 22:09:47 +0000 Subject: [issue8847] crash appending list and namedtuple In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za> Message-ID: <1343772587.78.0.537680121344.issue8847@psf.upfronthosting.co.za> Changes by Stefan Krah : Added file: http://bugs.python.org/file26633/issue8847-3.2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 00:10:13 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 31 Jul 2012 22:10:13 +0000 Subject: [issue15517] Minor trimming for ASDL parser In-Reply-To: <1343772503.75.0.788965811369.issue15517@psf.upfronthosting.co.za> Message-ID: <1343772613.5.0.0441679621338.issue15517@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Thanks for the patch. I'll look at this. ---------- assignee: -> benjamin.peterson nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 00:12:04 2012 From: report at bugs.python.org (Stefan Krah) Date: Tue, 31 Jul 2012 22:12:04 +0000 Subject: [issue8847] crash appending list and namedtuple In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za> Message-ID: <1343772724.91.0.124137613171.issue8847@psf.upfronthosting.co.za> Changes by Stefan Krah : Removed file: http://bugs.python.org/file26632/issue8847-3.3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 00:12:40 2012 From: report at bugs.python.org (Stefan Krah) Date: Tue, 31 Jul 2012 22:12:40 +0000 Subject: [issue8847] crash appending list and namedtuple In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za> Message-ID: <1343772760.15.0.537026798976.issue8847@psf.upfronthosting.co.za> Changes by Stefan Krah : Added file: http://bugs.python.org/file26634/issue8847-3.3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 00:18:18 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 31 Jul 2012 22:18:18 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1343758075.72.0.519164571184.issue14814@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: Yes, the module docs should have the provisional notice. Good catch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 00:25:08 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 31 Jul 2012 22:25:08 +0000 Subject: [issue15231] update PyPI upload doc to say --no-raw passed to rst2html.py In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za> Message-ID: <1343773508.18.0.40093645332.issue15231@psf.upfronthosting.co.za> ?ric Araujo added the comment: Please backport and leave open for distutils2. I much prefer that bugs stay open for months rather than porting to d2 be forgotten. Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 00:27:04 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 31 Jul 2012 22:27:04 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343764300.78.0.600412700354.issue15502@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: I would largely use Brett's proposed interface for MetaPathFinder (but keep the path argument optional) and his PathImporter interface for PathEntryHandler. Finder can then just become a legacy alias for MetaPathFinder. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 00:39:19 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 31 Jul 2012 22:39:19 +0000 Subject: [issue8847] crash appending list and namedtuple In-Reply-To: <20120731194650.GA27974@sleipnir.bytereef.org> Message-ID: <20120801003917.Horde.fyiAWklCcOxQGF6VTryybAA@webmail.df.eu> Martin v. L?wis added the comment: > Also, the only person to run the tests with the PGO build will probably > be Martin just before the releases. :) We could set up a buildbot slave which does PGO builds, provided somebody volunteered an installation (including VS Pro), and somebody contributed a build script that deviates from the regular build (perhaps including some training on the PGI). This is a separate issue, of course. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 00:43:56 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 31 Jul 2012 22:43:56 +0000 Subject: [issue8847] crash appending list and namedtuple In-Reply-To: <1343772568.37.0.883579120867.issue8847@psf.upfronthosting.co.za> Message-ID: <20120801004353.Horde.HmaET0lCcOxQGF_pNeSif5A@webmail.df.eu> Martin v. L?wis added the comment: > If anyone can confirm that this is the case or has a pointer to > the relevant vcproj docs, I'd be thrilled. http://msdn.microsoft.com/de-de/library/microsoft.visualstudio.vcprojectengine.vclinkertool.enablecomdatfolding(v=vs.90).aspx http://msdn.microsoft.com/de-de/library/microsoft.visualstudio.vcprojectengine.optfoldingtype(v=vs.90).aspx While the actual values for the XML schema aren't documented, I expect that they have the numeric values that they have in C++ (i.e. optFoldingDefault=0, optNoFolding=1, optFolding=2) To confirm, just look up the setting in the UI. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 00:52:41 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 31 Jul 2012 22:52:41 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343775161.04.0.485945539712.issue15502@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 00:56:46 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 31 Jul 2012 22:56:46 +0000 Subject: [issue15471] importlib's __import__() argument style nit In-Reply-To: <1343623185.67.0.579780091954.issue15471@psf.upfronthosting.co.za> Message-ID: <20120731185642.07176243@limelight.wooz.org> Barry A. Warsaw added the comment: On Jul 30, 2012, at 04:39 AM, Meador Inge wrote: >Meador Inge added the comment: > >How about the attached? What about something like: globals = ({} if globals is None else globals) and similarly for locals? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 02:18:34 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 01 Aug 2012 00:18:34 +0000 Subject: [issue8847] crash appending list and namedtuple In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za> Message-ID: <1343780314.49.0.451675961038.issue8847@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 02:24:42 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 01 Aug 2012 00:24:42 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343780682.23.0.238254048074.issue15502@psf.upfronthosting.co.za> Eric Snow added the comment: I'm working up a patch. My intention is to match up the names to those that Barry has pushed out to the updated glossary: MetaPathFinder and PathEntryFinder. I'll also include doc changes. I'm going to toy with not having any inheritance between the 3, but I'm not going to bother if it's not simple. Brett made some good points that I'll have to cover. Otherwise I'll likely go with Nick's recommendation. I'm in favor of deprecating Finder sooner rather than later. Also, I plan on registering importlib.machinery.PathFinder against MetaPathFinder and importlib.machinery.FileFinder against PathEntryFinder. One last thing: with Barry's use of "path importer" in the docs, I'd like to change the name of importlib.machinery.PathFinder to PathImporter (and leave in a deprecated legacy alias like with importlib.abc.Finder). This would line up with the docs and would also match the naming of the other two default importers. If Brett has strong feelings on this I'll let it go. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 02:40:34 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 01 Aug 2012 00:40:34 +0000 Subject: [issue15500] Python should support naming threads In-Reply-To: <1343650770.87.0.181202709436.issue15500@psf.upfronthosting.co.za> Message-ID: <1343781634.06.0.374199950501.issue15500@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 02:51:20 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 01 Aug 2012 00:51:20 +0000 Subject: [issue15488] Closed files keep their buffer alive In-Reply-To: <1343584592.55.0.343269676926.issue15488@psf.upfronthosting.co.za> Message-ID: <1343782280.25.0.189811658597.issue15488@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 02:52:19 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 01 Aug 2012 00:52:19 +0000 Subject: [issue15489] Correct __sizeof__ support for BytesIO In-Reply-To: <1343591287.44.0.516337828305.issue15489@psf.upfronthosting.co.za> Message-ID: <1343782339.53.0.579989326956.issue15489@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 02:56:12 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 01 Aug 2012 00:56:12 +0000 Subject: [issue15490] Correct __sizeof__ support for StringIO In-Reply-To: <1343591617.54.0.289047671129.issue15490@psf.upfronthosting.co.za> Message-ID: <1343782572.82.0.55459708099.issue15490@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 03:07:52 2012 From: report at bugs.python.org (Ned Batchelder) Date: Wed, 01 Aug 2012 01:07:52 +0000 Subject: [issue14803] Add feature to allow code execution prior to __main__ invocation In-Reply-To: <1336981419.55.0.280530546632.issue14803@psf.upfronthosting.co.za> Message-ID: <1343783272.61.0.443024548378.issue14803@psf.upfronthosting.co.za> Ned Batchelder added the comment: I agree with Antoine: I don't see why this should be a feature of virtualenvs. It's easy to use environment variables in a tightly-controlled way. We don't worry that any of the other environment variables that affect Python execution will somehow escape into the wild and change how Mercurial (or anything else) works. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 03:36:25 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 01 Aug 2012 01:36:25 +0000 Subject: [issue14918] Incorrect TypeError message for wrong function arguments In-Reply-To: <1337962864.62.0.211953440829.issue14918@psf.upfronthosting.co.za> Message-ID: <1343784985.72.0.858813731099.issue14918@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 03:45:04 2012 From: report at bugs.python.org (Atsuo Ishimoto) Date: Wed, 01 Aug 2012 01:45:04 +0000 Subject: [issue13119] Newline for print() is \n on Windows, and not \r\n as expected In-Reply-To: <1317934788.08.0.425265217585.issue13119@psf.upfronthosting.co.za> Message-ID: <1343785504.1.0.648133171715.issue13119@psf.upfronthosting.co.za> Atsuo Ishimoto added the comment: I found 'more' command in Windows7 requires \r\n. Python 2.7.3: C:\>python -c "for i in range(5):print(i)"|more 0 1 2 3 4 Python 3.3(trunk): c:\src\cpython\PCbuild>python -c "for i in range(5):print(i)"|more ????? ---------- nosy: +ishimoto _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 03:57:48 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 01 Aug 2012 01:57:48 +0000 Subject: [issue15499] Sleep is hardcoded in webbrowser.UnixBrowser In-Reply-To: <1343647122.66.0.223275733233.issue15499@psf.upfronthosting.co.za> Message-ID: <1343786268.63.0.532900156571.issue15499@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Thanks. Applying to 3.3. ---------- assignee: -> jcea nosy: +jcea versions: +Python 3.3 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 03:58:10 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Aug 2012 01:58:10 +0000 Subject: [issue15499] Sleep is hardcoded in webbrowser.UnixBrowser In-Reply-To: <1343647122.66.0.223275733233.issue15499@psf.upfronthosting.co.za> Message-ID: <3WmyMz2CKTzPc5@mail.python.org> Roundup Robot added the comment: New changeset a16403affccd by Jesus Cea in branch 'default': Closes #15499: Sleep is hardcoded in webbrowser.UnixBrowser http://hg.python.org/cpython/rev/a16403affccd ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 04:02:13 2012 From: report at bugs.python.org (Chris Calloway) Date: Wed, 01 Aug 2012 02:02:13 +0000 Subject: [issue15518] Provide test coverage for filecmp.dircmp.report methods. Message-ID: <1343786533.33.0.657671203467.issue15518@psf.upfronthosting.co.za> New submission from Chris Calloway: The filecmp module has no tests for the following methods of the dircmp class: report() report_partial_closure() report_full_closure() The attached patch provides those tests. This issue was suggested in issue 15454. Future plans for these tests are provided in that issue. ---------- components: Tests files: test_filecmp-1.patch keywords: patch messages: 167070 nosy: cbc priority: normal severity: normal status: open title: Provide test coverage for filecmp.dircmp.report methods. versions: Python 3.3 Added file: http://bugs.python.org/file26635/test_filecmp-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 04:06:07 2012 From: report at bugs.python.org (Chris Calloway) Date: Wed, 01 Aug 2012 02:06:07 +0000 Subject: [issue15518] Provide test coverage for filecmp.dircmp.report methods. In-Reply-To: <1343786533.33.0.657671203467.issue15518@psf.upfronthosting.co.za> Message-ID: <1343786767.7.0.0499900072619.issue15518@psf.upfronthosting.co.za> Changes by Chris Calloway : ---------- nosy: +cjerdonek type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 04:08:57 2012 From: report at bugs.python.org (Chris Calloway) Date: Wed, 01 Aug 2012 02:08:57 +0000 Subject: [issue15454] Allow dircmp.report() output stream to be customized In-Reply-To: <1343288932.25.0.229744443043.issue15454@psf.upfronthosting.co.za> Message-ID: <1343786937.1.0.6481453913.issue15454@psf.upfronthosting.co.za> Chris Calloway added the comment: Thank you and the issue to add report method tests is issue 15518. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 04:19:54 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 01 Aug 2012 02:19:54 +0000 Subject: [issue15518] Provide test coverage for filecmp.dircmp.report methods. In-Reply-To: <1343786533.33.0.657671203467.issue15518@psf.upfronthosting.co.za> Message-ID: <1343787594.04.0.851758920078.issue15518@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Thanks, Chris. A couple high-level comments. I know this isn't the prevailing style of the existing tests, but it's generally better if each unit test tests just one thing. That way, for example, if a test fails you know more precisely what is not working. Would it be possible to structure things so that you have tests like test_report(), test_report_partial_closure(), etc? Also, is there any reason you need to be using a regular expression as opposed to an exact string match? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 04:20:15 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 01 Aug 2012 02:20:15 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343787615.64.0.535362875529.issue15502@psf.upfronthosting.co.za> Nick Coghlan added the comment: (With the draft docs now comitted, this issue is the home for thrashing out the terminology. I'm not going to propose taking this to import-sig or python-dev, because the bikeshed would end up being fuschia or pink-with-yellow-polkadots or something) However this turns out, the names in the glossary and the ABCs in importlib should match for 3.3b2. I wouldn't bother with programmatic deprecation here (it's a PITA), just note them as deprecated aliases in the docs. However, I also think we need to take into account the naming precedents established (or endorsed) by importlib and think carefully about whether which ones we want to change. 1. importlib currently uses "importer" to mean an object that is both a finder *and* a loader (hence BuiltinImporter, FrozenImporter as meta path hooks). This is the original meaning of the term as defined in PEP 302 2. importlib uses the "PathFinder" term for what Barry has proposed to call the "path importer". If we go with this change in terminology, then we should change the general term "meta path finders" to "meta path importers", as that would make the usage of the term "importer" consistent across the three default meta path hooks. There would no longer be a special term to denote an importer that returned itself as the module loader. However, I'm now -1 on making this change: I'd prefer to preserve the distinction that an importer is a finder that returns itself as the loader, which means the path finder doesn't qualify. 3. I still find it confusing to have two different kinds of "finder". If the meta path finders keep their name (as I now prefer), then it is the path entry finders that need to move. While "handler" is a ridiculously generic term, the chain "path finder"->"path hook"->"path entry handler"->"module loader" strikes me as being easier to follow than "path finder"->"path hook"->"path entry finder"->"module loader". The only name change required for this adjustment in terminology would be that importlib.FileFinder would become importlib.DirectoryHandler 4. There would be a slight tweak to the definition of "importer" to mean objects that are either a meta path finder and module loader (i.e. BuiltinImporter, FrozenImporter) or else a path entry handler and module loader (i.e. zipimport.zipimporter) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 04:29:28 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 01 Aug 2012 02:29:28 +0000 Subject: [issue15519] finish exposing WindowsRegistryImporter in importlib Message-ID: <1343788168.67.0.343499108562.issue15519@psf.upfronthosting.co.za> New submission from Eric Snow: 1. add to importlib.machinery 2. register on importlib.abc.Finder patch in a moment. ---------- components: Interpreter Core keywords: needs review messages: 167074 nosy: brett.cannon, eric.snow, loewis priority: normal severity: normal stage: patch review status: open title: finish exposing WindowsRegistryImporter in importlib versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 04:32:00 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 01 Aug 2012 02:32:00 +0000 Subject: [issue15519] finish exposing WindowsRegistryImporter in importlib In-Reply-To: <1343788168.67.0.343499108562.issue15519@psf.upfronthosting.co.za> Message-ID: <1343788320.09.0.428309426177.issue15519@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- keywords: +patch Added file: http://bugs.python.org/file26636/issue15519_expose_importer.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 04:36:19 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 01 Aug 2012 02:36:19 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343788579.24.0.901677411611.issue15502@psf.upfronthosting.co.za> Nick Coghlan added the comment: Further thoughts: 1. Let's keep Finder as a generic base class for "things which find module loaders", with its current implementation but an updated docstring and documentation. 2. The reason both the MetaPathFinder and PathEntryHander ABCs need to preserve the Finder API for find_module is for backwards compatibility with third party reimplementations of the PEP 302 protocol. 3. importlib changes: - add MetaPathFinder and PathEntryHandler - inherit from MetaPathFinder or PathEntryHandler as appropriate (instead of directly from Finder) - rename FileFinder to DirectoryHandler (keeping the former as a legacy alias) 4. Longer term, we should deprecate find_module() completely, and add a meta-path appropriate find_loader(fullname, path) definition that allows multiple meta path finders to contribute to a namespace package. Finder would effectively become an empty categorisation ABC. This plan should be elaborated in a PEP for 3.4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 04:38:43 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 01 Aug 2012 02:38:43 +0000 Subject: [issue15519] finish exposing WindowsRegistryImporter in importlib In-Reply-To: <1343788168.67.0.343499108562.issue15519@psf.upfronthosting.co.za> Message-ID: <1343788723.35.0.509982480065.issue15519@psf.upfronthosting.co.za> Changes by Eric Snow : Removed file: http://bugs.python.org/file26636/issue15519_expose_importer.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 04:39:14 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 01 Aug 2012 02:39:14 +0000 Subject: [issue15519] finish exposing WindowsRegistryImporter in importlib In-Reply-To: <1343788168.67.0.343499108562.issue15519@psf.upfronthosting.co.za> Message-ID: <1343788754.96.0.45528285468.issue15519@psf.upfronthosting.co.za> Changes by Eric Snow : Added file: http://bugs.python.org/file26637/issue15519_expose_importer.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 04:45:36 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 01 Aug 2012 02:45:36 +0000 Subject: [issue15488] Closed files keep their buffer alive In-Reply-To: <1343584592.55.0.343269676926.issue15488@psf.upfronthosting.co.za> Message-ID: <1343789136.79.0.64151997455.issue15488@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: I take care of this. ---------- assignee: -> jcea hgrepos: +143 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 04:47:53 2012 From: report at bugs.python.org (Chris Calloway) Date: Wed, 01 Aug 2012 02:47:53 +0000 Subject: [issue15518] Provide test coverage for filecmp.dircmp.report methods. In-Reply-To: <1343786533.33.0.657671203467.issue15518@psf.upfronthosting.co.za> Message-ID: <1343789273.99.0.26780173203.issue15518@psf.upfronthosting.co.za> Chris Calloway added the comment: > Would it be possible to structure things so that you have tests like test_report(), test_report_partial_closure(), etc? Yes, I would prefer that structure. I was just being consistent, as you said, with the prevailing style of the existing tests. I will provide another patch with tests separated into report method concerns as you suggest and I agree. > Also, is there any reason you need to be using a regular expression as opposed to an exact string match? Yes, the setUp method uses tempfile-generated directory names (and that's actually one of the few good things about the existing tests). The tempfile-generated directory names are part of the report method output and are not known in advance. So we cannot construct an exact string match in advance. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 05:07:27 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 01 Aug 2012 03:07:27 +0000 Subject: [issue15488] Closed files keep their buffer alive In-Reply-To: <1343584592.55.0.343269676926.issue15488@psf.upfronthosting.co.za> Message-ID: <1343790447.83.0.861364412899.issue15488@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 05:09:32 2012 From: report at bugs.python.org (Mike Castle) Date: Wed, 01 Aug 2012 03:09:32 +0000 Subject: [issue15453] ctype with packed bitfields does not match native compiler In-Reply-To: <1343287497.79.0.127552089432.issue15453@psf.upfronthosting.co.za> Message-ID: <1343790572.67.0.375722081565.issue15453@psf.upfronthosting.co.za> Mike Castle added the comment: I did read through all of those before posting this one. As far as I can remember, none of those addressed the use of pack, which is the sole problem I'm facing here. Now maybe when all is said and done and all of these bitfield bugs are worked out, this one and that one will both be fixed. But I wasn't sure if this example would clarify or cloud those issues. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 05:09:55 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 01 Aug 2012 03:09:55 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343790595.33.0.41220997539.issue15502@psf.upfronthosting.co.za> Nick Coghlan added the comment: Reading through What's New, I withdraw the suggestion of changing the "path entry finder" term. It's just not worth the hassle. That also simplifies things a lot. All that needs to change to make things consistent: 1. Switch the docs over to using "path finder" instead of "path importer" 2. Add the MetaPathFinder and PathEntryFinder ABCs (with only the latter have find_loader() defined) 3. Adjust the inheritance in importlib to use the appropriate parent rather than inheriting from Finder directly ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 05:17:10 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 01 Aug 2012 03:17:10 +0000 Subject: [issue15488] Closed files keep their buffer alive In-Reply-To: <1343584592.55.0.343269676926.issue15488@psf.upfronthosting.co.za> Message-ID: <1343791030.19.0.794543573601.issue15488@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : Added file: http://bugs.python.org/file26638/a16403affccd _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 05:18:12 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 01 Aug 2012 03:18:12 +0000 Subject: [issue15488] Closed files keep their buffer alive In-Reply-To: <1343584592.55.0.343269676926.issue15488@psf.upfronthosting.co.za> Message-ID: <1343791092.17.0.912706813534.issue15488@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Please, review patch ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 06:11:53 2012 From: report at bugs.python.org (Meador Inge) Date: Wed, 01 Aug 2012 04:11:53 +0000 Subject: [issue15488] Closed files keep their buffer alive In-Reply-To: <1343584592.55.0.343269676926.issue15488@psf.upfronthosting.co.za> Message-ID: <1343794313.61.0.919802358255.issue15488@psf.upfronthosting.co.za> Meador Inge added the comment: The test should go in the 'SizeofTest' class and maybe a better test would be a variant of the test already in that class: @support.cpython_only def test_buffer_freeing(self) : bufsize = 4096 rawio = self.MockRawIO() bufio = self.tp(rawio, buffer_size=bufsize) size = sys.getsizeof(bufio) - bufsize bufio.close() self.assertEqual(sys.getsizeof(bufio), size) Otherwise, LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 06:30:14 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 01 Aug 2012 04:30:14 +0000 Subject: [issue15518] Provide test coverage for filecmp.dircmp.report methods. In-Reply-To: <1343786533.33.0.657671203467.issue15518@psf.upfronthosting.co.za> Message-ID: <1343795414.04.0.380737218992.issue15518@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > The tempfile-generated directory names are part of the report method output and are not known in advance. There are at least two ways you could deal with this. You could change the working directory to the temp directory in setUp() and change it back in tearDown(). This is a common pattern in the tests, and there is even a temp_cwd() context manager in Lib/test/support.py that will do this for you automatically (which unfortunately you can't use as is until issue 15351 is addressed). This way the report output would be relative to the temp directory, and so you wouldn't need to know the absolute path. To me this approach is preferred because the report output is more readable (no long file paths, etc). Alternatively, you could save the temp directory path as an attribute of the test class, and then include it in your string match prior to calling the assert method. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 06:50:21 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Aug 2012 04:50:21 +0000 Subject: [issue15517] Minor trimming for ASDL parser In-Reply-To: <1343772503.75.0.788965811369.issue15517@psf.upfronthosting.co.za> Message-ID: <3Wn2Bc4WnZzMVq@mail.python.org> Roundup Robot added the comment: New changeset cbfb915424fd by Benjamin Peterson in branch 'default': construct fields in the right order (closes #15517) http://hg.python.org/cpython/rev/cbfb915424fd ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 06:57:39 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 01 Aug 2012 04:57:39 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343797059.85.0.681051548241.issue15502@psf.upfronthosting.co.za> Eric Snow added the comment: Here's a patch that addresses Nick's 2 & 3. I think I found a satisfactory solution for the inheritance that is both correct and backward compatible. One question for now: does FileFinder need to keep its find_module() method? That should be resolved before 3.3 is released to avoid backward compatibility issues. ---------- keywords: +patch Added file: http://bugs.python.org/file26639/issue15502_new_abc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 06:58:51 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 01 Aug 2012 04:58:51 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343797131.02.0.320746036957.issue15502@psf.upfronthosting.co.za> Eric Snow added the comment: I just noticed that WindowsRegistryImporter does not have load_module(). If we are going for consistency, we should change the name to WindowsRegistryFinder. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 07:13:53 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 01 Aug 2012 05:13:53 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343798033.33.0.25581928155.issue15502@psf.upfronthosting.co.za> Eric Snow added the comment: > With the draft docs now comitted, this issue is the home for thrashing > out the terminology. In my mind the key is consistency. While a worthy goal regardless, for the import system and its attendant complexity, consistency is crucial. ("importer" == finder + loader) sounds fine with me. Even if some of these terms have been ambiguous in the past, I think that a consistent usage in the current docs will leave the ambiguity in the past. I will advocate Barry's recommendation that we put a warning in PEP 302 that the terms there may be outdated. I'm find with changing "path importer" to "path finder". If no one does a patch first, I'll put one up tomorrow. I actually prefer "path entry handler" for the distinctiveness, but I'm fine with leaving it be. However, I get a sense that this is our one shot at this decision. I'm also okay with renaming FileFinder to DirectoryHandler, particularly since it is a new class to 3.3 (no backward-compatibility issues). Naturally this would parallel any decision on "path entry handler". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 07:39:50 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 01 Aug 2012 05:39:50 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343799590.01.0.858008667582.issue15502@psf.upfronthosting.co.za> Changes by Eric Snow : Removed file: http://bugs.python.org/file26639/issue15502_new_abc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 07:40:19 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 01 Aug 2012 05:40:19 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343799619.82.0.897314668633.issue15502@psf.upfronthosting.co.za> Changes by Eric Snow : Added file: http://bugs.python.org/file26640/issue15502_new_abc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 07:42:10 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 01 Aug 2012 05:42:10 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343799730.46.0.24041940726.issue15502@psf.upfronthosting.co.za> Changes by Eric Snow : Removed file: http://bugs.python.org/file26640/issue15502_new_abc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 07:42:24 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 01 Aug 2012 05:42:24 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343799744.48.0.771613171553.issue15502@psf.upfronthosting.co.za> Changes by Eric Snow : Added file: http://bugs.python.org/file26641/issue15502_new_abc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 07:45:32 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 01 Aug 2012 05:45:32 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343799932.73.0.48330159311.issue15502@psf.upfronthosting.co.za> Nick Coghlan added the comment: Reading the 3.3 What's New reminded me that we aren't really as free to redefine this terminology as we might hope (or as I claimed on the previous issue). We can still try, of course, but the PEP 302 naming scheme has been around for 10 years, and there are plenty of guides and other things that assume that the things on the meta path and things returned by path hooks are both finders. That's actually reasonable, since the key role of both is to find a module loader given a module name. They differ in API details, but they fundamentally do the same thing. Better to go with the flow, especially given how close we are to release. As far as the implementation goes: +1 for renaming WindowsRegistryImporter to WindowsRegistryFinder -1 on breaking any find_module implementations. Backwards compatibility requirements still apply to the importlib API - while the default import system won't call FileFinder.find_module() any more, third party import reimplementations are still free to do so. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 08:01:54 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 01 Aug 2012 06:01:54 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343800914.6.0.985879363116.issue15502@psf.upfronthosting.co.za> Eric Snow added the comment: > Backwards compatibility requirements still apply to the importlib API - > while the default import system won't call FileFinder.find_module() any > more, third party import reimplementations are still free to do so. Except that a good portion of the importlib API is new in 3.3, including FileFinder. I've removed the changes to the 3 default meta path finders don't belong in the patch. ---------- Added file: http://bugs.python.org/file26642/issue15502_new_abc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 08:02:11 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 01 Aug 2012 06:02:11 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343800931.23.0.335661483191.issue15502@psf.upfronthosting.co.za> Changes by Eric Snow : Removed file: http://bugs.python.org/file26641/issue15502_new_abc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 08:07:26 2012 From: report at bugs.python.org (Eli Bendersky) Date: Wed, 01 Aug 2012 06:07:26 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <1343801246.14.0.756513488517.issue14814@psf.upfronthosting.co.za> Eli Bendersky added the comment: Attaching an updated patch that completes the documentation of network objects (attributes, methods and operations). Additionally, inserted the "provisional package" note and a "new in 3.3" notice. ---------- Added file: http://bugs.python.org/file26643/ipaddr_refdoc_network.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 08:48:27 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 01 Aug 2012 06:48:27 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343803707.4.0.169627599937.issue15502@psf.upfronthosting.co.za> Nick Coghlan added the comment: Fair point. However, the find_module() variant of the API isn't dead yet, so we should still support it. find_module() likely won't die completely until 4.0. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 08:59:36 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Aug 2012 06:59:36 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1317341390.65.0.255779328054.issue13072@psf.upfronthosting.co.za> Message-ID: <1343804376.46.0.402971936412.issue13072@psf.upfronthosting.co.za> STINNER Victor added the comment: Should we do something before Python 3.3 final? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 09:20:01 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Aug 2012 07:20:01 +0000 Subject: [issue13119] Newline for print() is \n on Windows, and not \r\n as expected In-Reply-To: <1317934788.08.0.425265217585.issue13119@psf.upfronthosting.co.za> Message-ID: <1343805601.65.0.841636429476.issue13119@psf.upfronthosting.co.za> STINNER Victor added the comment: > On Windows, stdin, stdout and stderr are creates using TextIOWrapper(..., newline=None). > In this case, TextIOWrapper._writenl is os.linesep and so '\r\n'. Oh, I was wrong: stdin is created with newline=None, but stdout and stderr are created with newline="\n" and so "\n" is not translated to "\r\n". I checked in Python 2.7: print("abc") and sys.stdout.write("abc\n") writes b"abc\r\n" into the output file (when the output is redirected), but sys.stdout.write("abc\r\n") writes b"abc\r\r\n". Python 3.3 should do the same: \r\n is preferred on Windows (ex: notepad doesn't support UNIX line ending, \n). Attached patch changes line ending for stdout and stderr on Windows: translate "\n" to "\r\n". It would be nice to fix this before Python 3.3 final. ---------- keywords: +patch nosy: +georg.brandl priority: normal -> release blocker Added file: http://bugs.python.org/file26644/windows_stdout_newline.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 09:23:00 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Aug 2012 07:23:00 +0000 Subject: [issue12073] regrtest: use faulthandler to dump the tracebacks on SIGUSR1 In-Reply-To: <1305327717.08.0.00592057633309.issue12073@psf.upfronthosting.co.za> Message-ID: <1343805780.21.0.996222468957.issue12073@psf.upfronthosting.co.za> STINNER Victor added the comment: The change was already done in another issue. I'm closing this one. changeset: 71315:30f91fbfc8b3 user: Victor Stinner date: Wed Jul 13 23:47:21 2011 +0200 files: Lib/test/regrtest.py description: Issue #12550: regrtest displays the Python traceback on SIGALRM or SIGUSR1 ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 09:24:24 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Aug 2012 07:24:24 +0000 Subject: [issue15213] _PyOS_URandom documentation In-Reply-To: <1340845023.83.0.143337072725.issue15213@psf.upfronthosting.co.za> Message-ID: <1343805864.77.0.229286171276.issue15213@psf.upfronthosting.co.za> STINNER Victor added the comment: So can we close this issue, or should we start to document private functions? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 09:39:37 2012 From: report at bugs.python.org (Manu Cupcic) Date: Wed, 01 Aug 2012 07:39:37 +0000 Subject: [issue13992] Segfault in PyTrash_destroy_chain In-Reply-To: <1328964953.21.0.536994091719.issue13992@psf.upfronthosting.co.za> Message-ID: <1343806777.17.0.662632489265.issue13992@psf.upfronthosting.co.za> Manu Cupcic added the comment: I am also hitting this issue. I have been able to reproduce it in python 2.5 and 2.7, on debian 6 (64 bits) Exactly like the reporter, I am making extensive use of threads. I am also using SQLalchemy. All my threads but one are waiting (probably for the GIL) : (gdb) info threads 15 Thread 0x7fffe3ff7700 (LWP 419) 0x00007ffff7bd03c0 in sem_wait () from /lib/libpthread.so.0 14 Thread 0x7fffe47f8700 (LWP 418) 0x00007ffff7bd03c0 in sem_wait () from /lib/libpthread.so.0 13 Thread 0x7fffe4ff9700 (LWP 417) 0x00007ffff7bd03c0 in sem_wait () from /lib/libpthread.so.0 12 Thread 0x7fffe57fa700 (LWP 416) 0x00007ffff7bd03c0 in sem_wait () from /lib/libpthread.so.0 11 Thread 0x7fffe5ffb700 (LWP 415) 0x00007ffff7bd03c0 in sem_wait () from /lib/libpthread.so.0 * 10 Thread 0x7fffe67fc700 (LWP 414) 0x000000000046479f in _Py_ForgetReference (op=0x4dc7bc0) at Objects/object.c:2222 9 Thread 0x7fffe6ffd700 (LWP 413) 0x00007ffff7bd03c0 in sem_wait () from /lib/libpthread.so.0 8 Thread 0x7fffe77fe700 (LWP 412) 0x00007ffff7bd03c0 in sem_wait () from /lib/libpthread.so.0 7 Thread 0x7fffe7fff700 (LWP 411) 0x00007ffff7bd03c0 in sem_wait () from /lib/libpthread.so.0 6 Thread 0x7fffec81c700 (LWP 410) 0x00007ffff72a11a3 in select () from /lib/libc.so.6 5 Thread 0x7fffed01d700 (LWP 409) 0x00007ffff7bd03c0 in sem_wait () from /lib/libpthread.so.0 4 Thread 0x7fffed81e700 (LWP 408) 0x00007ffff7bd03c0 in sem_wait () from /lib/libpthread.so.0 3 Thread 0x7fffee01f700 (LWP 407) 0x00007ffff7bd03c0 in sem_wait () from /lib/libpthread.so.0 2 Thread 0x7fffee820700 (LWP 406) 0x00007ffff729c9d3 in poll () from /lib/libc.so.6 1 Thread 0x7ffff7fec700 (LWP 393) 0x00007ffff72a11a3 in select () from /lib/libc.so.6 And the segfault happens in _Py_ForgetReference : (gdb) bt #0 0x000000000046479f in _Py_ForgetReference (op=0x4dc7bc0) at Objects/object.c:2222 #1 0x0000000000464810 in _Py_Dealloc (op=0x4dc7bc0) at Objects/object.c:2242 #2 0x0000000000559a68 in frame_dealloc (f=0x4997ab0) at Objects/frameobject.c:458 #3 0x000000000046481d in _Py_Dealloc (op=0x4997ab0) at Objects/object.c:2243 ... probably because something else zeroed out the op object : (gdb) select-frame 0 (gdb) print *op $6 = {_ob_next = 0x0, _ob_prev = 0x0, ob_refcnt = 0, ob_type = 0x2364020} Is there something else I can do to help resolve this bug ? I can help debugging this, but I am not sure how to proceed. I have a --with-pydebug interpreter stopped at the segfault in gdb. ---------- nosy: +cupcicm _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 09:45:57 2012 From: report at bugs.python.org (Dirkjan Ochtman) Date: Wed, 01 Aug 2012 07:45:57 +0000 Subject: [issue15520] Document datetime.timestamp() in 3.3 What's New Message-ID: <1343807157.88.0.373148573533.issue15520@psf.upfronthosting.co.za> New submission from Dirkjan Ochtman: It seems nice if datetime.timestamp() would be mentioned in the What's New. Does that seem acceptable? I'm happy to whip up a patch. ---------- assignee: docs at python components: Documentation messages: 167096 nosy: djc, docs at python priority: normal severity: normal status: open title: Document datetime.timestamp() in 3.3 What's New versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 09:51:37 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Aug 2012 07:51:37 +0000 Subject: [issue15488] Closed files keep their buffer alive In-Reply-To: <1343584592.55.0.343269676926.issue15488@psf.upfronthosting.co.za> Message-ID: <1343807497.63.0.556236804745.issue15488@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Agree with Meador. ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 10:06:38 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Aug 2012 08:06:38 +0000 Subject: [issue8847] crash appending list and namedtuple In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za> Message-ID: <3Wn6Y86XNvzNbw@mail.python.org> Roundup Robot added the comment: New changeset 5a8c5631463f by Martin v. L?wis in branch '2.7': Issue #8847: Disable COMDAT folding in Windows PGO builds. http://hg.python.org/cpython/rev/5a8c5631463f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 11:07:48 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 01 Aug 2012 09:07:48 +0000 Subject: [issue15521] Dev Guide should say how to run tests in 2.7 Message-ID: <1343812068.2.0.0173567393654.issue15521@psf.upfronthosting.co.za> New submission from Chris Jerdonek: The Dev Guide should say the preferred way (or even a way) to run tests using the Python 2.7 build: http://docs.python.org/devguide/runtests.html This will help submitters who want to check that their patch works with 2.7. In Python 2.7, this did not work (for obvious reasons): $ ./python.exe -m test .../python.exe: No module named test.__main__; 'test' is a package and cannot be directly executed But this did: $ ./python.exe -m test.regrtest Is the latter the preferred way? ---------- assignee: docs at python components: Devguide, Documentation keywords: easy messages: 167099 nosy: cjerdonek, docs at python, ezio.melotti priority: normal severity: normal stage: needs patch status: open title: Dev Guide should say how to run tests in 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 11:11:09 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Aug 2012 09:11:09 +0000 Subject: [issue8847] crash appending list and namedtuple In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za> Message-ID: <3Wn7zc4npgzPcn@mail.python.org> Roundup Robot added the comment: New changeset 2638ce032151 by Martin v. L?wis in branch '3.2': Issue #8847: Disable COMDAT folding in Windows PGO builds. http://hg.python.org/cpython/rev/2638ce032151 New changeset 029cde4e58c5 by Martin v. L?wis in branch 'default': Issue #8847: Disable COMDAT folding in Windows PGO builds. http://hg.python.org/cpython/rev/029cde4e58c5 New changeset d3afe5d8a4da by Martin v. L?wis in branch 'default': Issue #8847: Merge with 3.2 http://hg.python.org/cpython/rev/d3afe5d8a4da ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 11:13:03 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 01 Aug 2012 09:13:03 +0000 Subject: [issue8847] crash appending list and namedtuple In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za> Message-ID: <1343812383.37.0.651106011451.issue8847@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Thanks for the research and the fix! ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 11:16:02 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 01 Aug 2012 09:16:02 +0000 Subject: [issue15510] textwrap.wrap('') returns empty list In-Reply-To: <1343697979.41.0.629576632811.issue15510@psf.upfronthosting.co.za> Message-ID: <1343812562.17.0.262784539999.issue15510@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I verified that this patch can be applied to 2.7 and that those tests pass as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 11:17:49 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 01 Aug 2012 09:17:49 +0000 Subject: [issue15521] Dev Guide should say how to run tests in 2.7 In-Reply-To: <1343812068.2.0.0173567393654.issue15521@psf.upfronthosting.co.za> Message-ID: <1343812669.48.0.64640801298.issue15521@psf.upfronthosting.co.za> Ezio Melotti added the comment: FWIW this is already mentioned in the quick start [0]. Do you want to propose a patch for runtest.rst? [0]: http://docs.python.org/devguide/#quick-start ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 11:19:39 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 01 Aug 2012 09:19:39 +0000 Subject: [issue15521] Dev Guide should say how to run tests in 2.7 In-Reply-To: <1343812068.2.0.0173567393654.issue15521@psf.upfronthosting.co.za> Message-ID: <1343812778.99.0.340463656449.issue15521@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > FWIW this is already mentioned in the quick start [0]. I didn't catch that, thanks. > Do you want to propose a patch for runtest.rst? Sure. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 11:28:50 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Aug 2012 09:28:50 +0000 Subject: [issue15037] curses.unget_wch and test_curses fail when linked with ncurses 5.7 and earlier In-Reply-To: <1339171712.6.0.747270716657.issue15037@psf.upfronthosting.co.za> Message-ID: <1343813330.83.0.378001775355.issue15037@psf.upfronthosting.co.za> STINNER Victor added the comment: To debug this issue, it would help to have the following information: - locale encoding: encoding variable - tested character: ch - character read by ncurses: read Can someone reproducing the issue try to add: print("encoding=%s, ch=%r, read=%r" % (encoding, ch, read)) before the error? It may be an issue in the Python implementation of unget_wch() or get_wch(). -- > I believe the problem is due to a sign-extension bug in the ncurses library unget_wch function (see link below). Can we workaround this issue in Python? For example, use value & 0xffffff? -- The test should be modified to use the encoding of stdscr, not the locale encoding: encoding = stdscr.encoding. (In this test, both encodings should be the same.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 11:29:51 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Aug 2012 09:29:51 +0000 Subject: [issue8847] crash appending list and namedtuple In-Reply-To: <1343812383.37.0.651106011451.issue8847@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: You didn't add any test for non regression?? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 11:33:52 2012 From: report at bugs.python.org (abael) Date: Wed, 01 Aug 2012 09:33:52 +0000 Subject: [issue15522] impove 27 percent performance on stringpbject.c( by prefetch and loop optimization) Message-ID: <1343813632.92.0.115452555082.issue15522@psf.upfronthosting.co.za> New submission from abael: Python-2.7.3/Objects/stringobject.c( SHA256SUM ad7795c75e2a25247e4dea4cc5327c225c4da03b7c7d57226c817ba6d12a316c) static PyObject *string_join(PyStringObject *self, PyObject *orig); OLD IMPLEMENT LOGIC(Pseudo code): char *sep = PyString_AS_STRING(self); const Py_ssize_t seplen = PyString_GET_SIZE(self); seq = PySequence_Fast(orig, ""); seqlen = PySequence_Size(seq); if (seqlen == 0) return PyString_FromString(""); else if (seqlen == 1)return the exactly first one item; else{ for (i = 0; i < seqlen; i++) { const size_t old_sz = sz; item = PySequence_Fast_GET_ITEM(seq, i); if (!PyString_Check(item)){ if ( Py_USING_UNICODE and PyUnicode_Check(item)) return PyUnicode_Join((PyObject *)self, seq); else PyErr_Format(...); } sz += PyString_GET_SIZE(item); if (i != 0) sz += seplen; } } /* Allocate result space. */ res = PyString_FromStringAndSize((char*)NULL, sz); /* Catenate everything. */ p = PyString_AS_STRING(res); for (i = 0; i < seqlen; ++i) { size_t n; item = PySequence_Fast_GET_ITEM(seq, i); n = PyString_GET_SIZE(item); Py_MEMCPY(p, PyString_AS_STRING(item), n); p += n; if (i < seqlen - 1) { Py_MEMCPY(p, sep, seplen); p += seplen; } } Abael's IMPLEMENT LOGIC: char *sep = PyString_AS_STRING(self); const Py_ssize_t seplen = PyString_GET_SIZE(self); seq = PySequence_Fast(orig, ""); seqlen = PySequence_Size(seq); if (seqlen == 0) return PyString_FromString(""); if (seqlen == 1) return the exactly first one item; if (seqlen <0)return NULL /**** PREFETCH start, get the first item size, since here we can assume seqleng >= 2 ****/ register size_t sz=0; register size_t old_sz=0; PyObject *res = NULL; item = PySequence_Fast_GET_ITEM(seq, 0); if (!PyString_Check(item)){ if ( Py_USING_UNICODE and PyUnicode_Check(item)) return PyUnicode_Join((PyObject *)self, seq); else PyErr_Format(...); } sz += PyString_GET_SIZE(item); if (sz < old_sz || sz > PY_SSIZE_T_MAX) PyErr_SetString(PyExc_OverflowError,"join() result is too long for a Python string"); /**** PREFETCH end, get the first item size, since here we can assume seqleng >= 2 ****/ register Py_ssize_t i; for (i=1; i < seqlen; i++) { /**** then here we can loop start from 1 ****/ const size_t old_sz = sz; item = PySequence_Fast_GET_ITEM(seq, i); if (!PyString_Check(item)){ if ( Py_USING_UNICODE and PyUnicode_Check(item)) return PyUnicode_Join((PyObject *)self, seq); else PyErr_Format(...); } sz += PyString_GET_SIZE(item); sz += seplen; /**** now we don't need to test (i != 0) every loop ****/ } /* Allocate result space. */ res = PyString_FromStringAndSize((char*)NULL, sz); /* Catenate everything. */ /**** PREFETCH start, memcpy the first item first, since here we can assume seqleng >= 2 ****/ register char *p = PyString_AS_STRING(res); item = PySequence_Fast_GET_ITEM(seq, 0); sz = PyString_GET_SIZE(item); Py_MEMCPY(p, PyString_AS_STRING(item),sz); p += sz; /**** PREFETCH end, memcpy the first item first, since here we can assume seqleng >= 2 ****/ for (i=1; i _______________________________________ From report at bugs.python.org Wed Aug 1 11:35:06 2012 From: report at bugs.python.org (abael) Date: Wed, 01 Aug 2012 09:35:06 +0000 Subject: [issue15522] impove 27 percent performance on stringpbject.c( by prefetch and loop optimization) In-Reply-To: <1343813632.92.0.115452555082.issue15522@psf.upfronthosting.co.za> Message-ID: <1343813706.36.0.44142669339.issue15522@psf.upfronthosting.co.za> Changes by abael : ---------- components: +Interpreter Core -Library (Lib) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 11:58:44 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 01 Aug 2012 09:58:44 +0000 Subject: [issue15521] Dev Guide should say how to run tests in 2.7 In-Reply-To: <1343812068.2.0.0173567393654.issue15521@psf.upfronthosting.co.za> Message-ID: <1343815124.06.0.0570340510677.issue15521@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Attaching a patch for review. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file26645/issue-15521-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 12:07:11 2012 From: report at bugs.python.org (Stefan Krah) Date: Wed, 01 Aug 2012 10:07:11 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1317341390.65.0.255779328054.issue13072@psf.upfronthosting.co.za> Message-ID: <1343815631.76.0.659113500021.issue13072@psf.upfronthosting.co.za> Stefan Krah added the comment: Is it possible without too much effort to keep the old behavior ('u' -> Py_UNICODE)? Then I'd say that should go into 3.3. The problem with the current behavior is that it's neither backwards compatible nor PEP-3118 compliant. If it is too much work to restore the status quo, we could leave this change with the excuse that 'u' is probably not used very often. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 12:07:48 2012 From: report at bugs.python.org (Jarvis) Date: Wed, 01 Aug 2012 10:07:48 +0000 Subject: [issue15523] Block on close TCP socket in SocketServer.py Message-ID: <1343815668.28.0.0910478510187.issue15523@psf.upfronthosting.co.za> New submission from Jarvis: In the Python 2.4, it closes the socket only by calling request.close() method. There is a risk by using this method to close socket. If the socket handle count does not reach zero because another process still has a handle to the socket then the connection is not closed and the socket is not deallocated. So in Python 2.7 it updates it by calling request.shutdown() first, which can close the underlying connection and send a FIN/EOF to the peer regardless of how many processes have handles to the socket. After that, it calls request.close() to deallocate the socket. You can see this updates below that is from the file of C:\Python27\Lib\SocketServer.py. def shutdown_request(self, request): """Called to shutdown and close an individual request.""" try: #explicitly shutdown. socket.close() merely releases #the socket and waits for GC to perform the actual close. request.shutdown(socket.SHUT_WR) except socket.error: pass #some platforms may raise ENOTCONN here self.close_request(request) However,it will block at self.close_request(request) after request.shutdown(socket.SHUT_WR) if there are remaining data on reading side of socket. Here, it calls request.shutdown() with SHUT_WR flag, which means it only shuts down the writing side of the socket. The reading side of the socket isn't shut down at same time. So when calling close_request to deallocate the socket, it will always be waiting to read response until response data is available. It seems like an issue in SokcetServer.py library. In terms of that, I replaced the SHUT_WR flag with SHUT_RDWR (shut down both reading and writing sides of the socket) for request.shutdown method. Then this issue was resolved, the SSL connection was closed immediately. ---------- messages: 167110 nosy: jarvisliang priority: normal severity: normal status: open title: Block on close TCP socket in SocketServer.py type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 12:17:35 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 01 Aug 2012 10:17:35 +0000 Subject: [issue8847] crash appending list and namedtuple In-Reply-To: Message-ID: <20120801121733.Horde.OSIFdKGZi1VQGQI9yZBWuuA@webmail.df.eu> Martin v. L?wis added the comment: > You didn't add any test for non regression?? Please rephrase your question: what tests did I not add? I did add the tests that Stefan proposed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 12:19:45 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Aug 2012 10:19:45 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1317341390.65.0.255779328054.issue13072@psf.upfronthosting.co.za> Message-ID: <1343816385.02.0.907423918004.issue13072@psf.upfronthosting.co.za> STINNER Victor added the comment: Here is a patch reverting changes of the PEP 393, as suggested by Martin von Loewis. With the patch, array uses Py_UNICODE* type for the 'u' format. So array.array('u', '\u0010ffff')[0] should return '\uDBFF' on Windows. ---------- keywords: +patch Added file: http://bugs.python.org/file26646/array_revert_pep393.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 12:26:49 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 01 Aug 2012 10:26:49 +0000 Subject: [issue15231] update PyPI upload doc to say --no-raw passed to rst2html.py In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za> Message-ID: <1343816809.49.0.833529458333.issue15231@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > Please backport and leave open for distutils2. ?ric, is there a place where updates to the distutils2 docs can be viewed and made prior to reinclusion in the main Python repo? For example, the documentation here: http://packages.python.org/Distutils2/devresources.html#documentation suggests that the documentation is in a docs/source directory of this repo: http://hg.python.org/distutils2 but I don't seem to see the documentation there. Or do all changes need to wait for reinclusion? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 13:48:34 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 01 Aug 2012 11:48:34 +0000 Subject: [issue13992] Segfault in PyTrash_destroy_chain In-Reply-To: <1343806777.17.0.662632489265.issue13992@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > Is there something else I can do to help resolve this bug ? I can help debugging this, but I am not sure how to proceed. I have a --with-pydebug interpreter stopped at the segfault in gdb. Could you post the output of : """ p op """ and """ thread apply all bt """ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 13:53:36 2012 From: report at bugs.python.org (Manu Cupcic) Date: Wed, 01 Aug 2012 11:53:36 +0000 Subject: [issue13992] Segfault in PyTrash_destroy_chain In-Reply-To: <1328964953.21.0.536994091719.issue13992@psf.upfronthosting.co.za> Message-ID: <1343822016.51.0.322231663782.issue13992@psf.upfronthosting.co.za> Manu Cupcic added the comment: (gdb) p op $12 = (PyObject *) 0x4dc7bc0 thread all apply bt is going to be very long no ? Could you tell me what you want to know that is not in info threads maybe ? I can definitely post it here, but it's going to be a lot of output. I can be available on IRC if you want to debug it live. Thanks ! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 14:05:31 2012 From: report at bugs.python.org (Dmitry Dvoinikov) Date: Wed, 01 Aug 2012 12:05:31 +0000 Subject: [issue15524] Dict items() ordering varies across interpreter invocations Message-ID: <1343822731.32.0.0425809167964.issue15524@psf.upfronthosting.co.za> New submission from Dmitry Dvoinikov: The following line prints different things each time you run it: python3 -c "print(', '.join({ '1': '2', '3': '4' }.keys()))" The output is either "1, 3" or "3, 1". Is such indeterministic behavior intentional ? Using Python 3.3.0b1 (default, Aug 1 2012, 06:09:44) ---------- components: Interpreter Core messages: 167116 nosy: ddvoinikov priority: normal severity: normal status: open title: Dict items() ordering varies across interpreter invocations type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 14:09:35 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 01 Aug 2012 12:09:35 +0000 Subject: [issue15488] Closed files keep their buffer alive In-Reply-To: <1343584592.55.0.343269676926.issue15488@psf.upfronthosting.co.za> Message-ID: <1343822975.84.0.349366149971.issue15488@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This has to wait for 3.4, since it's an enhancement, not a bug. ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 14:11:30 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 01 Aug 2012 12:11:30 +0000 Subject: [issue15213] _PyOS_URandom documentation In-Reply-To: <1340845023.83.0.143337072725.issue15213@psf.upfronthosting.co.za> Message-ID: <1343823090.92.0.845394249899.issue15213@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The comment needs to be fixed before the issue is closed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 14:16:12 2012 From: report at bugs.python.org (Stefan Krah) Date: Wed, 01 Aug 2012 12:16:12 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1317341390.65.0.255779328054.issue13072@psf.upfronthosting.co.za> Message-ID: <1343823372.11.0.597115050567.issue13072@psf.upfronthosting.co.za> Stefan Krah added the comment: The diff between b9558df8cc58 and default with array_revert_pep393.patch applied is small, but I noticed that in some places you switched back to Py_UNICODE typecode and in others not. For instance, in struct arraydescr typecode is still char. I'm not sure why typecode was originally Py_UNICODE though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 14:34:46 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Aug 2012 12:34:46 +0000 Subject: [issue8847] crash appending list and namedtuple In-Reply-To: <20120801121733.Horde.OSIFdKGZi1VQGQI9yZBWuuA@webmail.df.eu> Message-ID: STINNER Victor added the comment: > Please rephrase your question: what tests did I not add? > I did add the tests that Stefan proposed. Ah yes, you added new tests to Python 3.2 and 3.3, but no to Python 2.7. Why not adding these new tests to Python 2.7? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 14:45:06 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 01 Aug 2012 12:45:06 +0000 Subject: [issue15524] Dict items() ordering varies across interpreter invocations In-Reply-To: <1343822731.32.0.0425809167964.issue15524@psf.upfronthosting.co.za> Message-ID: <1343825106.07.0.31202248922.issue15524@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Yes, because hash randomization is now enabled by default: http://docs.python.org/dev/reference/datamodel.html#object.__hash__ If you want deterministic behaviour, just set e.g. PYTHONHASHSEED=0. (or any other fixed value) ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 14:45:10 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Aug 2012 12:45:10 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1343823372.11.0.597115050567.issue13072@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > The diff between b9558df8cc58 and default with array_revert_pep393.patch > applied is small, but I noticed that in some places you switched back to > Py_UNICODE typecode and in others not. I just copied code from Python 3.2, I forgot to update typecode type (Py_UNICODE => char). I attach a new patch which changes also the documentation of the "u" format. ---------- Added file: http://bugs.python.org/file26647/array_revert_pep393-2.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r d3afe5d8a4da Doc/library/array.rst --- a/Doc/library/array.rst Wed Aug 01 11:09:55 2012 +0200 +++ b/Doc/library/array.rst Wed Aug 01 14:43:35 2012 +0200 @@ -21,7 +21,7 @@ defined: +-----------+--------------------+-------------------+-----------------------+-------+ | ``'B'`` | unsigned char | int | 1 | | +-----------+--------------------+-------------------+-----------------------+-------+ -| ``'u'`` | Py_UCS4 | Unicode character | 4 | | +| ``'u'`` | Py_UNICODE | Unicode character | 2 | \(1) | +-----------+--------------------+-------------------+-----------------------+-------+ | ``'h'`` | signed short | int | 2 | | +-----------+--------------------+-------------------+-----------------------+-------+ @@ -35,9 +35,9 @@ defined: +-----------+--------------------+-------------------+-----------------------+-------+ | ``'L'`` | unsigned long | int | 4 | | +-----------+--------------------+-------------------+-----------------------+-------+ -| ``'q'`` | signed long long | int | 8 | \(1) | +| ``'q'`` | signed long long | int | 8 | \(2) | +-----------+--------------------+-------------------+-----------------------+-------+ -| ``'Q'`` | unsigned long long | int | 8 | \(1) | +| ``'Q'`` | unsigned long long | int | 8 | \(2) | +-----------+--------------------+-------------------+-----------------------+-------+ | ``'f'`` | float | float | 4 | | +-----------+--------------------+-------------------+-----------------------+-------+ @@ -47,6 +47,11 @@ defined: Notes: (1) + The ``'u'`` type code corresponds to Python's unicode character + (:c:type:`Py_UNICODE` which is :c:type:`wchar_t`). Depending on the + platform, it can be 16 bits or 32 bits. + +(2) The ``'q'`` and ``'Q'`` type codes are available only if the platform C compiler used to build Python supports C :c:type:`long long`, or, on Windows, :c:type:`__int64`. diff -r d3afe5d8a4da Modules/arraymodule.c --- a/Modules/arraymodule.c Wed Aug 01 11:09:55 2012 +0200 +++ b/Modules/arraymodule.c Wed Aug 01 14:43:35 2012 +0200 @@ -174,25 +174,24 @@ BB_setitem(arrayobject *ap, Py_ssize_t i static PyObject * u_getitem(arrayobject *ap, Py_ssize_t i) { - return PyUnicode_FromOrdinal(((Py_UCS4 *) ap->ob_item)[i]); + return PyUnicode_FromUnicode(&((Py_UNICODE *) ap->ob_item)[i], 1); } static int u_setitem(arrayobject *ap, Py_ssize_t i, PyObject *v) { - PyObject *p; + Py_UNICODE *p; + Py_ssize_t len; - if (!PyArg_Parse(v, "U;array item must be unicode character", &p)) + if (!PyArg_Parse(v, "u#;array item must be unicode character", &p, &len)) return -1; - if (PyUnicode_READY(p)) - return -1; - if (PyUnicode_GET_LENGTH(p) != 1) { + if (len != 1) { PyErr_SetString(PyExc_TypeError, "array item must be unicode character"); return -1; } if (i >= 0) - ((Py_UCS4 *)ap->ob_item)[i] = PyUnicode_READ_CHAR(p, 0); + ((Py_UNICODE *)ap->ob_item)[i] = p[0]; return 0; } @@ -444,13 +443,6 @@ d_setitem(arrayobject *ap, Py_ssize_t i, return 0; } -#if SIZEOF_INT == 4 -# define STRUCT_LONG_FORMAT "I" -#elif SIZEOF_LONG == 4 -# define STRUCT_LONG_FORMAT "L" -#else -# error "Unable to get struct format for Py_UCS4" -#endif /* Description of types. * @@ -460,7 +452,7 @@ d_setitem(arrayobject *ap, Py_ssize_t i, static struct arraydescr descriptors[] = { {'b', 1, b_getitem, b_setitem, "b", 1, 1}, {'B', 1, BB_getitem, BB_setitem, "B", 1, 0}, - {'u', sizeof(Py_UCS4), u_getitem, u_setitem, STRUCT_LONG_FORMAT, 0, 0}, + {'u', sizeof(Py_UNICODE), u_getitem, u_setitem, "u", 0, 0}, {'h', sizeof(short), h_getitem, h_setitem, "h", 1, 1}, {'H', sizeof(short), HH_getitem, HH_setitem, "H", 1, 0}, {'i', sizeof(int), i_getitem, i_setitem, "i", 1, 1}, @@ -1519,26 +1511,25 @@ This method is deprecated. Use tobytes i static PyObject * array_fromunicode(arrayobject *self, PyObject *args) { - PyObject *ustr; + Py_UNICODE *ustr; Py_ssize_t n; + char typecode; - if (!PyArg_ParseTuple(args, "U:fromunicode", &ustr)) + if (!PyArg_ParseTuple(args, "u#:fromunicode", &ustr, &n)) return NULL; - if (self->ob_descr->typecode != 'u') { + typecode = self->ob_descr->typecode; + if ((typecode != 'u')) { PyErr_SetString(PyExc_ValueError, "fromunicode() may only be called on " "unicode type arrays"); return NULL; } - if (PyUnicode_READY(ustr)) - return NULL; - n = PyUnicode_GET_LENGTH(ustr); if (n > 0) { Py_ssize_t old_size = Py_SIZE(self); if (array_resize(self, old_size + n) == -1) return NULL; - if (!PyUnicode_AsUCS4(ustr, (Py_UCS4 *)self->ob_item + old_size, n, 0)) - return NULL; + memcpy(self->ob_item + old_size * sizeof(Py_UNICODE), + ustr, n * sizeof(Py_UNICODE)); } Py_INCREF(Py_None); @@ -1557,14 +1548,14 @@ append Unicode data to an array of some static PyObject * array_tounicode(arrayobject *self, PyObject *unused) { - if (self->ob_descr->typecode != 'u') { + char typecode; + typecode = self->ob_descr->typecode; + if ((typecode != 'u')) { PyErr_SetString(PyExc_ValueError, "tounicode() may only be called on unicode type arrays"); return NULL; } - return PyUnicode_FromKindAndData(PyUnicode_4BYTE_KIND, - (Py_UCS4 *) self->ob_item, - Py_SIZE(self)); + return PyUnicode_FromUnicode((Py_UNICODE *) self->ob_item, Py_SIZE(self)); } PyDoc_STRVAR(tounicode_doc, @@ -1671,7 +1662,13 @@ typecode_to_mformat_code(char typecode) return UNSIGNED_INT8; case 'u': - return UTF32_LE + is_big_endian; + if (sizeof(Py_UNICODE) == 2) { + return UTF16_LE + is_big_endian; + } + if (sizeof(Py_UNICODE) == 4) { + return UTF32_LE + is_big_endian; + } + return UNKNOWN_FORMAT; case 'f': if (sizeof(float) == 4) { @@ -2419,8 +2416,14 @@ array_buffer_getbuf(arrayobject *self, P view->strides = &(view->itemsize); view->format = NULL; view->internal = NULL; - if ((flags & PyBUF_FORMAT) == PyBUF_FORMAT) + if ((flags & PyBUF_FORMAT) == PyBUF_FORMAT) { view->format = self->ob_descr->formats; +#ifdef Py_UNICODE_WIDE + if (self->ob_descr->typecode == 'u') { + view->format = "w"; + } +#endif + } finish: self->ob_exports++; @@ -2534,25 +2537,19 @@ array_new(PyTypeObject *type, PyObject * Py_DECREF(v); } else if (initial != NULL && PyUnicode_Check(initial)) { - Py_ssize_t n; - if (PyUnicode_READY(initial)) { - Py_DECREF(a); - return NULL; - } - n = PyUnicode_GET_LENGTH(initial); + Py_ssize_t n = PyUnicode_GET_DATA_SIZE(initial); if (n > 0) { arrayobject *self = (arrayobject *)a; - Py_UCS4 *item = (Py_UCS4 *)self->ob_item; - item = (Py_UCS4 *)PyMem_Realloc(item, n * sizeof(Py_UCS4)); + char *item = self->ob_item; + item = (char *)PyMem_Realloc(item, n); if (item == NULL) { PyErr_NoMemory(); Py_DECREF(a); return NULL; } - self->ob_item = (char*)item; - Py_SIZE(self) = n; - if (!PyUnicode_AsUCS4(initial, item, n, 0)) - return NULL; + self->ob_item = item; + Py_SIZE(self) = n / sizeof(Py_UNICODE); + memcpy(item, PyUnicode_AS_DATA(initial), n); self->allocated = Py_SIZE(self); } } @@ -2593,7 +2590,7 @@ is a single character. The following ty Type code C Type Minimum size in bytes \n\ 'b' signed integer 1 \n\ 'B' unsigned integer 1 \n\ - 'u' Unicode character 4 \n\ + 'u' Unicode character 2 (see note) \n\ 'h' signed integer 2 \n\ 'H' unsigned integer 2 \n\ 'i' signed integer 2 \n\ @@ -2605,6 +2602,9 @@ is a single character. The following ty 'f' floating point 4 \n\ 'd' floating point 8 \n\ \n\ +NOTE: The 'u' typecode corresponds to Python's unicode character. On \n\ +narrow builds this is 2-bytes on wide builds this is 4-bytes.\n\ +\n\ NOTE: The 'q' and 'Q' type codes are only available if the platform \n\ C compiler used to build Python supports 'long long', or, on Windows, \n\ '__int64'.\n\ From report at bugs.python.org Wed Aug 1 14:45:34 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 01 Aug 2012 12:45:34 +0000 Subject: [issue15524] Dict items() ordering varies across interpreter invocations In-Reply-To: <1343822731.32.0.0425809167964.issue15524@psf.upfronthosting.co.za> Message-ID: <1343825134.79.0.970712809035.issue15524@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 15:04:55 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 01 Aug 2012 13:04:55 +0000 Subject: [issue15522] impove 27 percent performance on stringpbject.c( by prefetch and loop optimization) In-Reply-To: <1343813632.92.0.115452555082.issue15522@psf.upfronthosting.co.za> Message-ID: <1343826295.99.0.343585939153.issue15522@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Hi, several points: - Python 2.7 is in bugfix mode; you need to work from the default Mercurial branch as explained in http://docs.python.org/devguide/ . In practice, this means your patch will target the future Python 3.4, and therefore either PyUnicode_Join or _PyBytes_Join. - please provide an actual patch (a Mercurial diff, probably) - please provide benchmarks (using e.g. timeit) which demonstrate the performance improvement you are proposing ---------- nosy: +pitrou versions: +Python 3.4 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 15:07:59 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 01 Aug 2012 13:07:59 +0000 Subject: [issue15425] Another strange Tracebacks with importlib In-Reply-To: <1342987622.49.0.633292920923.issue15425@psf.upfronthosting.co.za> Message-ID: <1343826479.82.0.243023963094.issue15425@psf.upfronthosting.co.za> Nick Coghlan added the comment: Indeed, there are still a couple of Windows failures, but they aren't related to this. ---------- status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 15:17:40 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 01 Aug 2012 13:17:40 +0000 Subject: [issue15525] test_multiprocessing failure on Windows XP Message-ID: <1343827060.29.0.756371915694.issue15525@psf.upfronthosting.co.za> New submission from Nick Coghlan: test_multiprocessing failed on one of the XP buildbots with a permission error: http://buildbot.python.org/all/builders/x86%20XP-4%203.x/builds/7223/steps/test/logs/stdio The immediate rerun also failed, but the one at the end of the test run succeeded. ---------- components: Library (Lib) keywords: buildbot messages: 167125 nosy: georg.brandl, ncoghlan, sbt priority: release blocker severity: normal stage: needs patch status: open title: test_multiprocessing failure on Windows XP type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 15:30:04 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 01 Aug 2012 13:30:04 +0000 Subject: [issue15526] regrtest crash on Windows 7 AMD64 Message-ID: <1343827804.07.0.425515249327.issue15526@psf.upfronthosting.co.za> New submission from Nick Coghlan: regrtest bailed out completely on one of the Windows 7 builders due to a problem with accessing the temporary working directory: http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/410/steps/test/logs/stdio It's seems a touch suspicious that test_fork1 just so happened to be the test executed right before test_startfile blew up. Not marking as a blocker yet, since my initial assumption is that it's a race condition with a particular sequence of tests rather than a problem in Python itself. I'll change my mind if it happens again on the rebuild I just forced. ---------- components: Tests keywords: buildbot messages: 167126 nosy: georg.brandl, ncoghlan priority: normal severity: normal status: open title: regrtest crash on Windows 7 AMD64 type: crash versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 15:31:08 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 01 Aug 2012 13:31:08 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1317341390.65.0.255779328054.issue13072@psf.upfronthosting.co.za> Message-ID: <1343827868.89.0.136917331538.issue13072@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 15:32:32 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 01 Aug 2012 13:32:32 +0000 Subject: [issue8847] crash appending list and namedtuple In-Reply-To: Message-ID: <20120801153231.Horde.D-SVSklCcOxQGS-vQmBCQmA@webmail.df.eu> Martin v. L?wis added the comment: > Ah yes, you added new tests to Python 3.2 and 3.3, but no to Python > 2.7. Why not adding these new tests to Python 2.7? The tests don't crash Python 2.7. So they are not useful as a test whether the bug has been worked-around. I actually don't know how to test this compiler bug in Python 2.7 (except for writing specific C code that tries to trigger the bug). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 15:34:54 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 01 Aug 2012 13:34:54 +0000 Subject: [issue15519] finish exposing WindowsRegistryImporter in importlib In-Reply-To: <1343788168.67.0.343499108562.issue15519@psf.upfronthosting.co.za> Message-ID: <1343828094.89.0.798974611831.issue15519@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 15:36:17 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 01 Aug 2012 13:36:17 +0000 Subject: [issue15526] regrtest crash on Windows 7 AMD64 In-Reply-To: <1343827804.07.0.425515249327.issue15526@psf.upfronthosting.co.za> Message-ID: <1343828177.37.0.0988633240208.issue15526@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Well, test_startfile seems to be a common issue on that buildbot. ---------- nosy: +jeremy.kloth, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 15:42:29 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 01 Aug 2012 13:42:29 +0000 Subject: [issue15522] impove 27 percent performance on stringpbject.c( by prefetch and loop optimization) In-Reply-To: <1343813632.92.0.115452555082.issue15522@psf.upfronthosting.co.za> Message-ID: <1343828549.19.0.851905462015.issue15522@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 16:01:43 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 01 Aug 2012 14:01:43 +0000 Subject: [issue15519] finish exposing WindowsRegistryImporter in importlib In-Reply-To: <1343788168.67.0.343499108562.issue15519@psf.upfronthosting.co.za> Message-ID: <1343829703.1.0.675390372191.issue15519@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I'm not sure why some finders are named "Finder" and others "Importer". It makes things confusing. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 16:04:26 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 01 Aug 2012 14:04:26 +0000 Subject: [issue15510] textwrap.wrap('') returns empty list In-Reply-To: <1343697979.41.0.629576632811.issue15510@psf.upfronthosting.co.za> Message-ID: <1343829866.96.0.732775552391.issue15510@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Uh, how is this a bug? An empty text doesn't contain lines at all, so returning an empty list of lines sounds right. Furthermore, by "fixing" this, you may break existing software. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 16:08:38 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 01 Aug 2012 14:08:38 +0000 Subject: [issue15520] Document datetime.timestamp() in 3.3 What's New In-Reply-To: <1343807157.88.0.373148573533.issue15520@psf.upfronthosting.co.za> Message-ID: <1343830118.92.0.876120937862.issue15520@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Yes, of course. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 16:17:24 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Wed, 01 Aug 2012 14:17:24 +0000 Subject: [issue15496] harden directory removal for tests on Windows In-Reply-To: <1343614495.69.0.283818579392.issue15496@psf.upfronthosting.co.za> Message-ID: <1343830644.0.0.0908729346405.issue15496@psf.upfronthosting.co.za> Jeremy Kloth added the comment: I must also add that the proposed solution works well within the test suite as the access denied error can also occur when creating subsequent files, not just removing them. This solution eliminates the need to wrap all creation calls with access denied handling, a huge plus IMHO. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 16:17:33 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Wed, 01 Aug 2012 14:17:33 +0000 Subject: [issue15526] regrtest crash on Windows 7 AMD64 In-Reply-To: <1343828177.37.0.0988633240208.issue15526@psf.upfronthosting.co.za> Message-ID: Jeremy Kloth added the comment: > Well, test_startfile seems to be a common issue on that buildbot. I wouldn't really call it common (twice in the last 30 runs). However I would wager that the PermissionError is being caused by an unknown (without having Process Monitor running when the error occurs) process temporarily grabbing a handle to a file/directory within the tests temporary directory. This just reinforces the need for the solution in issue15496 to be applied. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 16:24:45 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 01 Aug 2012 14:24:45 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343798033.33.0.25581928155.issue15502@psf.upfronthosting.co.za> Message-ID: <20120801102443.35de557c@limelight.wooz.org> Barry A. Warsaw added the comment: I've mostly run out of time to work on the docs, but I do want to say that I thought long and hard about all the terminology decisions. Please don't change them lightly, and definitely don't change them until you've tried to go through the documentation and make all the updates and read through them to see how well it flows and makes sense. It is *not* easy. On Aug 01, 2012, at 05:13 AM, Eric Snow wrote: >("importer" == finder + loader) sounds fine with me. That's how I tried to think about it. In some sense, it's just an implementation detail, but where it comes into the play for the documentation is the "path importer", which is the thing on sys.meta_path that implements all the sys.path/sys.path_hooks/sys.path_importer_cache semantics. While technically a finder, calling it the "path finder" just does not work, IMHO. It's too confusing and causes the documentation to be less comprehensible. So the one compromise I made was to call this thing the "path importer" because I think conceptually, if not strictly implementation-wise, that term ties everything together. A diagram would seal the deal I think. >I'm find with changing "path importer" to "path finder". If no one does a >patch first, I'll put one up tomorrow. Please don't, for reasons stated above! >I actually prefer "path entry handler" for the distinctiveness, but I'm fine >with leaving it be. However, I get a sense that this is our one shot at this >decision. I don't think "handler" is a very good term. These things *are* finders, even if the API they support is richer and slightly different than meta path finders. Also, I think "path entry handler" could almost be just as useful for the things on sys.path_hooks, although I do use "path entry hook" here. But in a sense the callables on sys.path_hooks also "handle" path entries, just in a different way. I think "path entry finder" neatly describes both its similarities and differences from other objects in the picture. I'm going to leave all the abc names and implementations to you guys. :) Thanks for all your excellent feedback and your own work on this nasty little corner of Python. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 16:37:46 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 01 Aug 2012 14:37:46 +0000 Subject: [issue15496] harden directory removal for tests on Windows In-Reply-To: <1343614495.69.0.283818579392.issue15496@psf.upfronthosting.co.za> Message-ID: <1343831866.46.0.240278961651.issue15496@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +brian.curtin stage: -> patch review versions: +Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 16:57:17 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 01 Aug 2012 14:57:17 +0000 Subject: [issue15519] finish exposing WindowsRegistryImporter in importlib In-Reply-To: <1343788168.67.0.343499108562.issue15519@psf.upfronthosting.co.za> Message-ID: <1343833037.56.0.428092143741.issue15519@psf.upfronthosting.co.za> Brett Cannon added the comment: The importers can both find and load modules (e.g. BuiltinImporter defines both find_module() and load_module()), while the finders only find modules (e.g. only define find_module()). It's defined in the glossary, so maybe more links to that would help. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 17:01:44 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 01 Aug 2012 15:01:44 +0000 Subject: [issue15519] finish exposing WindowsRegistryImporter in importlib In-Reply-To: <1343833037.56.0.428092143741.issue15519@psf.upfronthosting.co.za> Message-ID: <1343833158.3370.2.camel@localhost.localdomain> Antoine Pitrou added the comment: > The importers can both find and load modules (e.g. BuiltinImporter > defines both find_module() and load_module()), while the finders only > find modules (e.g. only define find_module()). Ah, fair enough. I thought loader objects were always distinct from finders. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 17:05:58 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Aug 2012 15:05:58 +0000 Subject: [issue15527] Double parents in functions references Message-ID: <1343833557.96.0.948912415493.issue15527@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: :c:func:`PyMem_Malloc(n)` on Doc/c-api/memory.rst:109 rendered in HTML as PyMem_Malloc(1)() (note double parents). There are many other examples on this and other pages. The issue is actual for all modern versions of Python. ---------- assignee: docs at python components: Documentation messages: 167137 nosy: docs at python, storchaka priority: normal severity: normal status: open title: Double parents in functions references versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 17:17:59 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 01 Aug 2012 15:17:59 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343834279.12.0.773777947094.issue15502@psf.upfronthosting.co.za> Brett Cannon added the comment: So just to weigh in on this, I think "meta path finder" and "path entry finder" (as Barry stated in the glossary already) clearly delineate what is from sys.meta_path and what is from some path entry hook by having a clarifying word to go with "finder" (either kind of finder is still trying to find a loader). Finder/loader/importer has history in terms of usage so we can't muck with these terms too much. This does mean, though, that PathFinder and FileFinder are misnamed. Unfortunately PathFinder existed in previous versions of Python, so it will need an alias to its old name from a new name (PathImporter as Barry wants or MetaPathEntryFinder?). But FileFinder is new, so that can be renamed to FilePathEntryFinder (or FileEntryFinder). And of course WindowsRegistryImporter should be changed to *Finder. I think if we harp on the "meta path" vs. "path entry" and use it consistently and extensively then the finder/loader/importer terminology does not need to change meaning and we don't have to misuse it for path importer to classify PathFinder while keeping the rest of Barry's terms intact which make it obvious when something is directly because of how import works vs. just a single meta path finder that happens to be what nearly everyone ends up using to handle their imports. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 17:33:52 2012 From: report at bugs.python.org (Dirkjan Ochtman) Date: Wed, 01 Aug 2012 15:33:52 +0000 Subject: [issue6308] termios fix for QNX breaks HP-UX In-Reply-To: <1245342143.83.0.0806702305005.issue6308@psf.upfronthosting.co.za> Message-ID: <1343835232.35.0.306432825499.issue6308@psf.upfronthosting.co.za> Dirkjan Ochtman added the comment: Can we have someone take a look at this? It seems fairly innocuous. ---------- nosy: +djc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 17:40:16 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 01 Aug 2012 15:40:16 +0000 Subject: [issue15521] Dev Guide should say how to run tests in 2.7 In-Reply-To: <1343812068.2.0.0173567393654.issue15521@psf.upfronthosting.co.za> Message-ID: <1343835616.44.0.37999507186.issue15521@psf.upfronthosting.co.za> Ezio Melotti added the comment: Thanks for the patch. I'm not sure it's necessary to add a new section though, unless you are planning to add more differences there. +base command instead of the one described above: :: You can just use "... above::" here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 17:41:15 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 01 Aug 2012 15:41:15 +0000 Subject: [issue15527] Double parens in functions references In-Reply-To: <1343833557.96.0.948912415493.issue15527@psf.upfronthosting.co.za> Message-ID: <1343835675.38.0.5541245168.issue15527@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- title: Double parents in functions references -> Double parens in functions references _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 17:48:30 2012 From: report at bugs.python.org (Daniel Holth) Date: Wed, 01 Aug 2012 15:48:30 +0000 Subject: [issue15468] Edit docs to hide hashlib.md5() In-Reply-To: <1343404007.83.0.817302008925.issue15468@psf.upfronthosting.co.za> Message-ID: <1343836110.56.0.878771484272.issue15468@psf.upfronthosting.co.za> Daniel Holth added the comment: re-tweak treatment of md5 in hashlib docs (the SHA-2 family is currently recommended by http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html) ---------- Added file: http://bugs.python.org/file26648/hashlib.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 18:18:47 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Wed, 01 Aug 2012 16:18:47 +0000 Subject: [issue15528] Better support for finalization with weakrefs Message-ID: <1343837927.06.0.561023898829.issue15528@psf.upfronthosting.co.za> New submission from Richard Oudkerk: A patch with docs and tests for the idea I suggested on python-ideas: http://comments.gmane.org/gmane.comp.python.ideas/15863 To repeat what I wrote there, the current issues with weakref callbacks include: 1. They are rather low level, and working out how to use them correctly requires a bit of head scratching. One must find somewhere to store the weakref till after the referent is dead, and without accidentally keeping the referent alive. Then one must ensure that the callback frees the weakref (without leaving any remnant ref-cycles). When it is an option, using a __del__ method is far less hassle. 2. Callbacks invoked during interpreter shutdown are troublesome. For instance they can throw exceptions because module globals have been replaced by None. 3. Sometimes you want the callback to be called at program exit even if the referent is still alive. 4. Exceptions thrown in callbacks do not produce a traceback. This can make debugging rather awkward. (Maybe this is because printing tracebacks is problematic during interpreter shutdown?) (Note that problems 2-4 also apply to using __del__ methods.) Trivial usage of the class looks like >>> class Kenny: pass ... >>> kenny = Kenny() >>> finalize(kenny, print, "you killed kenny!") >>> del kenny you killed kenny! ---------- files: finalize.patch keywords: patch messages: 167142 nosy: sbt priority: normal severity: normal stage: patch review status: open title: Better support for finalization with weakrefs type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file26649/finalize.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 18:40:31 2012 From: report at bugs.python.org (Tom Tromey) Date: Wed, 01 Aug 2012 16:40:31 +0000 Subject: [issue15529] PyIter_Check evaluates to 0 for Python list object Message-ID: <1343839231.18.0.262983756093.issue15529@psf.upfronthosting.co.za> New submission from Tom Tromey: I was debugging this bug reported against gdb: http://sourceware.org/bugzilla/show_bug.cgi?id=14386 It turns out that what went wrong in this code was that PyIter_Check evaluates to 0 when its argument is a Python list. This happens because the PyIter_Check macro looks at the tp_iternext field; but this field is 0 in PyList_Type. I am not sure of the correct fix; but PyIter_Check is not faithfully reflecting what PyObject_GetIter does. Maybe it isn't intended to; but anyway it seems that checking tp_iter would maybe be a better approximation. Even if PyIter_Check remains as-is, I think it would be nice if the documentation were more specific about what it actually does. FWIW I'm modifying gdb not to use this function. ---------- components: None messages: 167143 nosy: tromey priority: normal severity: normal status: open title: PyIter_Check evaluates to 0 for Python list object versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 18:43:00 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 01 Aug 2012 16:43:00 +0000 Subject: [issue15529] PyIter_Check evaluates to 0 for Python list object In-Reply-To: <1343839231.18.0.262983756093.issue15529@psf.upfronthosting.co.za> Message-ID: <1343839380.6.0.814517170498.issue15529@psf.upfronthosting.co.za> Benjamin Peterson added the comment: That's because lists are iterators not iterable. ---------- nosy: +benjamin.peterson resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 18:44:59 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Aug 2012 16:44:59 +0000 Subject: [issue15525] test_multiprocessing failure on Windows XP In-Reply-To: <1343827060.29.0.756371915694.issue15525@psf.upfronthosting.co.za> Message-ID: <3WnL3G2XvVzPjK@mail.python.org> Roundup Robot added the comment: New changeset b99a82bc2cde by Richard Oudkerk in branch 'default': Issue #15525: Increase timeout when TerminateProcess() fails http://hg.python.org/cpython/rev/b99a82bc2cde ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 18:48:13 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Wed, 01 Aug 2012 16:48:13 +0000 Subject: [issue15525] test_multiprocessing failure on Windows XP In-Reply-To: <1343827060.29.0.756371915694.issue15525@psf.upfronthosting.co.za> Message-ID: <1343839693.06.0.151614704217.issue15525@psf.upfronthosting.co.za> Richard Oudkerk added the comment: I would guess that the process has already terminated (or is being torn down) but the timeout is not long enough to let the parent join child. Let's see if increasing the timeout fixes the failures. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 18:53:47 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 01 Aug 2012 16:53:47 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343840027.69.0.0115109672042.issue15502@psf.upfronthosting.co.za> Eric Snow added the comment: @Barry: I'm fine with what you've said. My big concern is that we be really consistent here because of the complexity of the import system. Things are at a point that I think we're pretty close in the regard, so I'm mostly fine if we stay put. My only real regret would likely be "path importer" vs. PathFinder, but I can live with it. :) @Brett: I'll update my patch for WindowsRegistryImporter and FileFinder. @anyone: do the doc-based deprecations in the patch look okay? The inheritance model? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 18:57:18 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 01 Aug 2012 16:57:18 +0000 Subject: [issue15519] finish exposing WindowsRegistryImporter in importlib In-Reply-To: <1343788168.67.0.343499108562.issue15519@psf.upfronthosting.co.za> Message-ID: <1343840238.71.0.672923704298.issue15519@psf.upfronthosting.co.za> Eric Snow added the comment: Also, WindowsRegistryImporter is misnamed. It should be WindowsRegistryFinder (see issue15502). Depending on the patch there, I'll update the one here. ---------- dependencies: +Meta path finders and path entry finders are different, but share an ABC _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 19:00:20 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 01 Aug 2012 17:00:20 +0000 Subject: [issue15519] finish exposing WindowsRegistryImporter in importlib In-Reply-To: <1343788168.67.0.343499108562.issue15519@psf.upfronthosting.co.za> Message-ID: <1343840420.87.0.242868774343.issue15519@psf.upfronthosting.co.za> Eric Snow added the comment: I guess the real question here is if anyone has problems with adding WindowsRegistryFinder to importlib.machinery (and to the importlib docs). If it should stay private than I'd like to throw a _ on the name of the class. The change to importlib.abc would likely stay either way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 19:13:50 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 01 Aug 2012 17:13:50 +0000 Subject: [issue15519] finish exposing WindowsRegistryImporter in importlib In-Reply-To: <1343788168.67.0.343499108562.issue15519@psf.upfronthosting.co.za> Message-ID: <1343841230.79.0.612997882648.issue15519@psf.upfronthosting.co.za> Brett Cannon added the comment: It should be exposed (i.e. if SourcelessFileLoader is documented and exposed then so should WindowsRegistryFinder). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 19:19:47 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 01 Aug 2012 17:19:47 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343841587.67.0.871056672327.issue15502@psf.upfronthosting.co.za> Brett Cannon added the comment: The patch will have Finder break all subclasses that don't define find_loader which is backwards-incompatible. And if you really want to deprecate Finder you should have a warning in an __init__ method (as one would hope people are calling super() as necessary). Otherwise the patch looks fine (from a cursory glance). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 19:49:40 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Aug 2012 17:49:40 +0000 Subject: [issue15463] test_faulthandler can fail if install path is too long In-Reply-To: <1343352188.31.0.766597419616.issue15463@psf.upfronthosting.co.za> Message-ID: <3WnMTr26sbzPYj@mail.python.org> Roundup Robot added the comment: New changeset 6e03f9b72c61 by Victor Stinner in branch 'default': Issue #15463: Write a test for faulthandler truncating the name of functions http://hg.python.org/cpython/rev/6e03f9b72c61 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 19:50:57 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Aug 2012 17:50:57 +0000 Subject: [issue15463] test_faulthandler can fail if install path is too long In-Reply-To: <1343352188.31.0.766597419616.issue15463@psf.upfronthosting.co.za> Message-ID: <1343843457.1.0.851108263598.issue15463@psf.upfronthosting.co.za> STINNER Victor added the comment: I added a test checking that faulthandler truncates strings to MAX_STRING_LENGTH characters using a very long function name. I consider this issue as done. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 20:03:00 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Aug 2012 18:03:00 +0000 Subject: [issue14811] decoding_fgets() truncates long lines and fails with a SyntaxError("Non-UTF-8 code starting with...") In-Reply-To: <1337056300.81.0.374626607094.issue14811@psf.upfronthosting.co.za> Message-ID: <1343844180.54.0.380255875205.issue14811@psf.upfronthosting.co.za> STINNER Victor added the comment: > Are we going to fix this before 3.3? Any objections to Victor's patch? detect_truncate.patch is now raising an error if a line is longer than BUFSIZ, whereas Python supports lines longer than BUFSIZ bytes (it's just that the encoding cookie is ignored if the line 1 or 2 is longer than BUFSIZ bytes). So my patch is not correct. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 20:03:35 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Aug 2012 18:03:35 +0000 Subject: [issue15479] Allow MAX_STRING_LENGTH limits to be changed at runtime In-Reply-To: <1343512799.42.0.958459698801.issue15479@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > Sounds totally overkill to me. I changed the maximum length of a string to 500 characters instead of 100. It should be enough for most cases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 20:03:57 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Aug 2012 18:03:57 +0000 Subject: [issue15213] _PyOS_URandom documentation In-Reply-To: <1343823090.92.0.845394249899.issue15213@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > The comment needs to be fixed before the issue is closed. Ah yes, here is a patch updating the comment of _PyOS_URandom() and the doc of the os module. ---------- keywords: +patch Added file: http://bugs.python.org/file26650/urandom_doc.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 2dd1b056d663 Doc/library/os.rst --- a/Doc/library/os.rst Wed Aug 01 14:53:22 2012 +0200 +++ b/Doc/library/os.rst Wed Aug 01 15:34:07 2012 +0200 @@ -3331,5 +3331,5 @@ Miscellaneous Functions This function returns random bytes from an OS-specific randomness source. The returned data should be unpredictable enough for cryptographic applications, though its exact quality depends on the OS implementation. On a Unix-like - system this will query /dev/urandom, and on Windows it will use CryptGenRandom. - If a randomness source is not found, :exc:`NotImplementedError` will be raised. + system this will query ``/dev/urandom``, and on Windows it will use + :c:func:`CryptGenRandom`. diff -r 2dd1b056d663 Python/random.c --- a/Python/random.c Wed Aug 01 14:53:22 2012 +0200 +++ b/Python/random.c Wed Aug 01 15:34:07 2012 +0200 @@ -219,8 +219,9 @@ lcg_urandom(unsigned int x0, unsigned ch } } -/* Fill buffer with size pseudo-random bytes, not suitable for cryptographic - use, from the operating random number generator (RNG). +/* Fill buffer with size pseudo-random bytes from the operating random number + generator (RNG). It is suitable for for most cryptographic purposes except + long living private keys for asymmetric encryption. Return 0 on success, raise an exception and return -1 on error. */ int From report at bugs.python.org Wed Aug 1 20:07:52 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Aug 2012 18:07:52 +0000 Subject: [issue15441] test_posixpath fails on Japanese edition of Windows In-Reply-To: <1343143448.49.0.0362298873842.issue15441@psf.upfronthosting.co.za> Message-ID: <3WnMtt4hCHzPgX@mail.python.org> Roundup Robot added the comment: New changeset 3edc71ed19e7 by Victor Stinner in branch 'default': Issue #15441: Skip test_nonascii_abspath() of test_genericpath on Windows http://hg.python.org/cpython/rev/3edc71ed19e7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 20:10:36 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Aug 2012 18:10:36 +0000 Subject: [issue15441] test_posixpath fails on Japanese edition of Windows In-Reply-To: <1343143448.49.0.0362298873842.issue15441@psf.upfronthosting.co.za> Message-ID: <1343844636.17.0.499134984876.issue15441@psf.upfronthosting.co.za> STINNER Victor added the comment: This issue (the test) should be fixed, see the issue #15478 for the real fix. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 20:11:16 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 01 Aug 2012 18:11:16 +0000 Subject: [issue15463] test_faulthandler can fail if install path is too long In-Reply-To: <1343352188.31.0.766597419616.issue15463@psf.upfronthosting.co.za> Message-ID: <1343844676.05.0.577075939646.issue15463@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > I didn't want to write such test, but I can review a patch adding such test. Victor, did you see and review my patch? There is currently no test to check that a long file path (longer than 100 characters) will render, which was the original issue that was fixed. The patch provides such a test. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 20:13:43 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Aug 2012 18:13:43 +0000 Subject: [issue15463] test_faulthandler can fail if install path is too long In-Reply-To: <1343844676.05.0.577075939646.issue15463@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > Victor, did you see and review my patch? There is currently no test to check that a long file path (longer than 100 characters) will render, which was the original issue that was fixed. The patch provides such a test. Yes, I saw your patch, but I don't want to create very long filename. Not all platforms support paths longer than 500 characters. It is exactly the same code to display function name and file names. I prefer to use a very long function name, it's simple and portable. My patch is different than yours: it checks that the string is truncated, not that string shorter than the limit are not truncated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 20:19:56 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Aug 2012 18:19:56 +0000 Subject: [issue15530] Enhance Py_MIN and Py_MAX Message-ID: <1343845195.3.0.786704958428.issue15530@psf.upfronthosting.co.za> New submission from STINNER Victor: Attached patch enhances Py_MIN and Py_MAX to check that types of both arguments are compatible at compile time. Checks are only done if the compiler is GCC. The patch uses also Py_MIN and Py_MAX in more places. (The commit may be done in two parts.) ---------- components: Interpreter Core files: py_min_max.patch keywords: patch messages: 167161 nosy: haypo priority: normal severity: normal status: open title: Enhance Py_MIN and Py_MAX versions: Python 3.3 Added file: http://bugs.python.org/file26651/py_min_max.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 20:35:56 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 01 Aug 2012 18:35:56 +0000 Subject: [issue15463] test_faulthandler can fail if install path is too long In-Reply-To: <1343352188.31.0.766597419616.issue15463@psf.upfronthosting.co.za> Message-ID: <1343846156.86.0.783547802116.issue15463@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > Yes, I saw your patch, but I don't want to create very long filename. Not all platforms support paths longer than 500 characters. I think you may have a slight misunderstanding. My patch was not meant to test paths over 500 characters. It tests a path *under* 500 characters (but slightly over 100 characters). And it has the same style and portability characteristics as the existing ".*threading.py" tests. > My patch is different than yours: it checks that the string is truncated, not that string shorter than the limit are not truncated. Yes, your patch is different in two ways. :) It tests function names instead of paths, and length > 500 instead of 100 < length < 500. I think there is value in adding a file path test because code changes over time, so it may not always be using the same code path as function names. I agree that it is okay to leave out a file path test for longer than 500 characters for the portability reasons you stated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 21:00:03 2012 From: report at bugs.python.org (Dave Abrahams) Date: Wed, 01 Aug 2012 19:00:03 +0000 Subject: [issue15531] os.path symlink docs missing Message-ID: <1343847603.27.0.526292718618.issue15531@psf.upfronthosting.co.za> New submission from Dave Abrahams: the docs for os.path don't mention the following facts which I think are important (in fact I assumed the facts would be the reverse): os.path.realpath(l) works when l is a broken symbolic link, returning the path to the (missing) target os.path.readlink(l) causes an error when l is a broken symbolic link. ---------- assignee: docs at python components: Documentation messages: 167163 nosy: dabrahams, docs at python priority: normal severity: normal status: open title: os.path symlink docs missing type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 21:22:22 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 01 Aug 2012 19:22:22 +0000 Subject: [issue15529] PyIter_Check evaluates to 0 for Python list object In-Reply-To: <1343839231.18.0.262983756093.issue15529@psf.upfronthosting.co.za> Message-ID: <1343848942.67.0.0909290252124.issue15529@psf.upfronthosting.co.za> Brett Cannon added the comment: I think Benjamin meant to say lists are iterables not iterators. =) ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 21:29:44 2012 From: report at bugs.python.org (Stefan Krah) Date: Wed, 01 Aug 2012 19:29:44 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1317341390.65.0.255779328054.issue13072@psf.upfronthosting.co.za> Message-ID: <1343849384.09.0.592658577902.issue13072@psf.upfronthosting.co.za> Stefan Krah added the comment: array_revert_pep393-2.patch looks good (checked against 7042a83f37e and all following commits that should be kept). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 22:44:23 2012 From: report at bugs.python.org (Christian Heimes) Date: Wed, 01 Aug 2012 20:44:23 +0000 Subject: [issue15500] Python should support naming threads In-Reply-To: <1343650770.87.0.181202709436.issue15500@psf.upfronthosting.co.za> Message-ID: <1343853863.51.0.747775929758.issue15500@psf.upfronthosting.co.za> Christian Heimes added the comment: +1 win32 supports thread names, too. http://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 22:51:01 2012 From: report at bugs.python.org (Christian Heimes) Date: Wed, 01 Aug 2012 20:51:01 +0000 Subject: [issue15468] Edit docs to hide hashlib.md5() In-Reply-To: <1343404007.83.0.817302008925.issue15468@psf.upfronthosting.co.za> Message-ID: <1343854261.25.0.515518555653.issue15468@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 22:56:35 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 01 Aug 2012 20:56:35 +0000 Subject: [issue15510] textwrap.wrap('') returns empty list In-Reply-To: <1343697979.41.0.629576632811.issue15510@psf.upfronthosting.co.za> Message-ID: <1343854595.3.0.262251329085.issue15510@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Here are additional test cases impacted by this issue: >>> wrap(" ") [] >>> wrap("\n\n\n") [] >>> wrap("\n\n\n", replace_whitespace=False) [] >>> wrap(" \n\n", replace_whitespace=False) [] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 23:02:38 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 01 Aug 2012 21:02:38 +0000 Subject: [issue15530] Enhance Py_MIN and Py_MAX In-Reply-To: <1343845195.3.0.786704958428.issue15530@psf.upfronthosting.co.za> Message-ID: <1343854958.96.0.682059793836.issue15530@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I think that's too late for 3.3. It's not a bug fix. If we use this kind of feature, we either need to declare a minimum supported GCC version (any GCC older than 10 years can be dropped IMO), or check for the specific version of GCC in which all the necessary features were present. Did you detect any errors in the Python code using this change? Wouldn't the compiler refuse to perform the comparison if the types were not compatible? ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 23:22:50 2012 From: report at bugs.python.org (Dave Malcolm) Date: Wed, 01 Aug 2012 21:22:50 +0000 Subject: [issue9635] Add Py_BREAKPOINT and sys._breakpoint hooks In-Reply-To: <1282175005.37.0.905894818052.issue9635@psf.upfronthosting.co.za> Message-ID: <1343856170.75.0.482845594005.issue9635@psf.upfronthosting.co.za> Dave Malcolm added the comment: Note to self: a messy way of forcing gdb to do the equivalent of a breakpoint directly from Python is: os.kill(os.getpid(), signal.SIGTRAP) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 1 23:56:38 2012 From: report at bugs.python.org (Andy Lutomirski) Date: Wed, 01 Aug 2012 21:56:38 +0000 Subject: [issue15532] "for line in file" is *still* broken in Python 2.7 Message-ID: <1343858198.39.0.554130035278.issue15532@psf.upfronthosting.co.za> New submission from Andy Lutomirski: This program: import subprocess, sys p = subprocess.Popen(['bash', '-c', 'while true; do echo x; sleep 1; done'], bufsize=0, stdout=subprocess.PIPE) for line in p.stdout: sys.stdout.buffer.write(line) sys.stdout.flush() sits around and does nothing on Python 2.7.3. It works (i.e. prints 'x' once per second) on Python 3. This was http://bugs.python.org/issue3907 and is supposedly fixed, but it's not. ---------- components: IO messages: 167170 nosy: Andy.Lutomirski priority: normal severity: normal status: open title: "for line in file" is *still* broken in Python 2.7 type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 00:03:29 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 01 Aug 2012 22:03:29 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343841587.67.0.871056672327.issue15502@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: As a final attempt at giving the path import machinery the emphasis it deserves without misusing the "importer" term, how about: 1. "path import subsystem" for that whole section of the import machinery; and 2. "path import finder" specifically for the meta path finder that importlib calls "PathFinder" and the new docs currently call "path importer" "path_importer_cache" would still be a bit of a misnomer, but that ship sailed a long time ago. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 00:04:45 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Aug 2012 22:04:45 +0000 Subject: [issue15530] Enhance Py_MIN and Py_MAX In-Reply-To: <1343845195.3.0.786704958428.issue15530@psf.upfronthosting.co.za> Message-ID: <1343858685.21.0.657423422572.issue15530@psf.upfronthosting.co.za> STINNER Victor added the comment: > I think that's too late for 3.3. It's not a bug fix. Oops, I chose 3.3 instead of 3.4. Fixed. > If we use this kind of feature, we either need to declare a minimum supported GCC version typeof() and __builtin_types_compatible_p() were introduced to gcc in version 3.0 and 3.1.1. Do we plan to support GCC older than 3.1? :-) > (any GCC older than 10 years can be dropped IMO) GCC 3.1 was released 10 years ago. It's cheap to add a test on the GCC version to fallback on the simple "x Did you detect any errors in the Python code using this change? Nope. But it avoids at least to evaluate an expression twice (if an argument is not a variable or a number, but a complex expression... like most new PyUnicode_*() macros). Even if I prefer to avoid expressions in macro arguments... > Wouldn't the compiler refuse to perform the comparison > if the types were not compatible? I don't know exactly how __builtin_types_compatible_p() compare types. At least, I can say that int and unsigned int are considered as incompatible. -- The Linux kernel uses "(void) (&_min1 == &_min2);" to check that types are compatible. I suppose that this expression is written for GCC. GCC only emits a warning, I chose Py_BUILD_ASSERT_EXPR() to emit an error instead. ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 00:15:33 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Aug 2012 22:15:33 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1317341390.65.0.255779328054.issue13072@psf.upfronthosting.co.za> Message-ID: <1343859332.92.0.84191981603.issue13072@psf.upfronthosting.co.za> STINNER Victor added the comment: @Georg: are you ok with this change? It reverts the behaviour of Python 3.2 and avoids to have to maintain an API that nobody wants to use ('u' format using Py_UCS4, 32 bits unsigned). ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 00:17:56 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 01 Aug 2012 22:17:56 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: Message-ID: <20120801181747.7e9a6275@resist.wooz.org> Barry A. Warsaw added the comment: On Aug 01, 2012, at 10:03 PM, Nick Coghlan wrote: >1. "path import subsystem" for that whole section of the import machinery; >and >2. "path import finder" specifically for the meta path finder that >importlib calls "PathFinder" and the new docs currently call "path importer" -0. To me, this doesn't make things vastly more clear for the additional awkwardness in readability. >"path_importer_cache" would still be a bit of a misnomer, but that ship >sailed a long time ago. Yeah, we all agree that one's unfortunate! ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 00:24:04 2012 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 01 Aug 2012 22:24:04 +0000 Subject: [issue1521950] shlex.split() does not tokenize like the shell Message-ID: <1343859844.24.0.889360065256.issue1521950@psf.upfronthosting.co.za> Changes by Vinay Sajip : ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 00:25:44 2012 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 01 Aug 2012 22:25:44 +0000 Subject: [issue14713] PEP 414 installation hook fails with an AssertionError In-Reply-To: <1336059741.48.0.751323304263.issue14713@psf.upfronthosting.co.za> Message-ID: <1343859944.78.0.188056550636.issue14713@psf.upfronthosting.co.za> Changes by Vinay Sajip : ---------- versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 00:26:30 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Aug 2012 22:26:30 +0000 Subject: [issue15525] test_multiprocessing failure on Windows XP In-Reply-To: <1343827060.29.0.756371915694.issue15525@psf.upfronthosting.co.za> Message-ID: <1343859990.54.0.815690378721.issue15525@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 00:27:21 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Aug 2012 22:27:21 +0000 Subject: [issue15525] test_multiprocessing failure on Windows XP In-Reply-To: <1343827060.29.0.756371915694.issue15525@psf.upfronthosting.co.za> Message-ID: <1343860041.26.0.901161432628.issue15525@psf.upfronthosting.co.za> STINNER Victor added the comment: > Let's see if increasing the timeout fixes the failures. At least, the 3 following builds succeed (let's see the next builds). ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 00:27:34 2012 From: report at bugs.python.org (Andy Lutomirski) Date: Wed, 01 Aug 2012 22:27:34 +0000 Subject: [issue15532] "for line in file" is *still* broken in Python 2.7 on pipes In-Reply-To: <1343858198.39.0.554130035278.issue15532@psf.upfronthosting.co.za> Message-ID: <1343860054.78.0.375322579657.issue15532@psf.upfronthosting.co.za> Changes by Andy Lutomirski : ---------- title: "for line in file" is *still* broken in Python 2.7 -> "for line in file" is *still* broken in Python 2.7 on pipes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 00:44:53 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 01 Aug 2012 22:44:53 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <20120801181747.7e9a6275@resist.wooz.org> Message-ID: Nick Coghlan added the comment: The problem with "path importer" is it's just plain *wrong*. That object is not an importer and thus calling it one makes it much harder to learn the finder/loader/importer distinctions correctly. "import finder" is only slightly longer than "importer" and has the huge advantage of *not being wrong*. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 01:55:22 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 01 Aug 2012 23:55:22 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: Message-ID: <20120801195517.1601a120@resist.wooz.org> Barry A. Warsaw added the comment: On Aug 01, 2012, at 10:44 PM, Nick Coghlan wrote: >The problem with "path importer" is it's just plain *wrong*. That object is >not an importer and thus calling it one makes it much harder to learn the >finder/loader/importer distinctions correctly. The term "importer" is sufficiently squishy though, and I think we could just as easily adjust the term's definition in the glossary to match what this thing is. >"import finder" is only slightly longer than "importer" and has the huge >advantage of *not being wrong*. The problem is that "import finder" isn't correct either, because this thing doesn't load modules, and it doesn't find imports. It finds loaders through different kinds of finders. It is unquestionably a finder, so probably the most accurate term would be "path finder" but that just didn't read well when I tried to use it. Part of the problem is that "path finder" isn't different enough from "path entry finder" to avoid confusion, and I really like the latter to describe the things that the sys.path_hooks callables return, and I'm sure none of us want to call it the "path entry loader finder finder" :). Keep trying, but so far "path importer" is the least crappy of the lot, IMHO. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 01:57:43 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Aug 2012 23:57:43 +0000 Subject: [issue15321] bdist_wininst installers may terminate with "close failed in file object destructor:\nsys.excepthook is missing\nlost sys.stderr" In-Reply-To: <1341965309.27.0.878027505194.issue15321@psf.upfronthosting.co.za> Message-ID: <3WnWfV1HSKzPfY@mail.python.org> Roundup Robot added the comment: New changeset 014b36383a54 by Eli Bendersky in branch '3.2': Issue #15321: update PyPI upload doc to say --no-raw passed to rst2html.py http://hg.python.org/cpython/rev/014b36383a54 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 02:00:59 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Aug 2012 00:00:59 +0000 Subject: [issue15231] update PyPI upload doc to say --no-raw passed to rst2html.py In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za> Message-ID: <3WnWkJ4LBtzPfY@mail.python.org> Roundup Robot added the comment: New changeset 29bdbcadf299 by Eli Bendersky in branch '2.7': Issue #15231: update PyPI upload doc to say --no-raw passed to rst2html.py http://hg.python.org/cpython/rev/29bdbcadf299 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 02:01:35 2012 From: report at bugs.python.org (Eli Bendersky) Date: Thu, 02 Aug 2012 00:01:35 +0000 Subject: [issue15231] update PyPI upload doc to say --no-raw passed to rst2html.py In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za> Message-ID: <1343865695.07.0.964345000297.issue15231@psf.upfronthosting.co.za> Eli Bendersky added the comment: Backported in 014b36383a54 and 29bdbcadf299 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 02:08:06 2012 From: report at bugs.python.org (Chris Calloway) Date: Thu, 02 Aug 2012 00:08:06 +0000 Subject: [issue15518] Provide test coverage for filecmp.dircmp.report methods. In-Reply-To: <1343786533.33.0.657671203467.issue15518@psf.upfronthosting.co.za> Message-ID: <1343866086.09.0.796085026964.issue15518@psf.upfronthosting.co.za> Chris Calloway added the comment: > There are at least two ways you could deal with this. You could change the working directory to the temp directory in setUp() and change it back in tearDown(). This is a common pattern in the tests [...] > Alternatively, you could save the temp directory path as an attribute of the test class, and then include it in your string match prior to calling the assert method. Although I prefer explicitly testing that the subdirectory paths shows up in the reports and, in the case of the report_partial_closure test, the regex explicitly tests that the "only in" subdirectory is reported correctly, if I were to have to choose between the two options you propose, I would choose decorating the test instance with the strings as that would at least preserve the ability to perform the latter of the two explicit tests I mention and would not be subject to yet another file system point of failure while switching directories (even if that is a common pattern in the tests). assertRegex is new from unittest2 and seems tailor-made for this use case to me. It gets the job done in explicitly correctly in the least amount of code. If you insist that I not use assertRegex for the report test, I will yield to your preferences. However, I would like your blessing to continue with assertRegex in this case. In either event, I still will refactor the patch into separate test methods for the report methods as previously agreed after your continued feedback. And thank you again for your feedback above. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 02:27:13 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 02 Aug 2012 00:27:13 +0000 Subject: [issue15518] Provide test coverage for filecmp.dircmp.report methods. In-Reply-To: <1343786533.33.0.657671203467.issue15518@psf.upfronthosting.co.za> Message-ID: <1343867233.63.0.640069953039.issue15518@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > However, I would like your blessing to continue with assertRegex in this case. Sure, you can proceed that way. :) My suggestions were just that -- suggestions for you to consider. And I am not a core developer, so my approval won't necessarily get your patch committed more quickly. :) Thanks for considering my suggestions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 02:36:42 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 02 Aug 2012 00:36:42 +0000 Subject: [issue15521] Dev Guide should say how to run tests in 2.7 In-Reply-To: <1343812068.2.0.0173567393654.issue15521@psf.upfronthosting.co.za> Message-ID: <1343867802.11.0.438949236533.issue15521@psf.upfronthosting.co.za> Chris Jerdonek added the comment: It is a relatively large section (nine paragraphs + six code snippets) and is primarily about the in-development branch, so I did not want to interrupt the flow with a remark specific to 2.7. I also liked that the instructions in a subsection could be linked to. But here is a new patch. ---------- Added file: http://bugs.python.org/file26652/issue-15521-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 03:16:59 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Thu, 02 Aug 2012 01:16:59 +0000 Subject: [issue15526] regrtest crash on Windows 7 AMD64 In-Reply-To: Message-ID: Jeremy Kloth added the comment: I have just completed an upgrade of the Win64 buildbot slave with a faster hard drive and the issue is now much more pronounced. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 03:42:35 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 02 Aug 2012 01:42:35 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343871755.85.0.544841606318.issue15502@psf.upfronthosting.co.za> Eric Snow added the comment: > The patch will have Finder break all subclasses that don't define > find_loader which is backwards-incompatible. How so? Finder is registered against PathEntryFinder. It doesn't inherit, so it doesn't get the abc.ABCMeta as a metaclass and thereby there is no instantiation-time checks for find_loader(). Attached is a patch that makes the two names changes (FileFinder was all over the place). ---------- Added file: http://bugs.python.org/file26653/issue15502_new_abc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 03:42:43 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 02 Aug 2012 01:42:43 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343871763.61.0.158117406478.issue15502@psf.upfronthosting.co.za> Changes by Eric Snow : Removed file: http://bugs.python.org/file26642/issue15502_new_abc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 03:49:40 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 02 Aug 2012 01:49:40 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343872180.19.0.128899887268.issue15502@psf.upfronthosting.co.za> Eric Snow added the comment: Regarding deprecating importlib.abc.Finder, I'll add a DeprecationWarning to the patch later. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 05:02:58 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 02 Aug 2012 03:02:58 +0000 Subject: [issue15526] regrtest crash on Windows 7 AMD64 In-Reply-To: <1343827804.07.0.425515249327.issue15526@psf.upfronthosting.co.za> Message-ID: <1343876578.38.0.822937411476.issue15526@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 05:03:53 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 02 Aug 2012 03:03:53 +0000 Subject: [issue15496] harden directory removal for tests on Windows In-Reply-To: <1343614495.69.0.283818579392.issue15496@psf.upfronthosting.co.za> Message-ID: <1343876633.72.0.665705546334.issue15496@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 05:04:08 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 02 Aug 2012 03:04:08 +0000 Subject: [issue7443] test.support.unlink issue on Windows platform In-Reply-To: <1260026404.41.0.635406889881.issue7443@psf.upfronthosting.co.za> Message-ID: <1343876648.61.0.129393612952.issue7443@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 05:54:22 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 02 Aug 2012 03:54:22 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343879662.3.0.76705103675.issue15502@psf.upfronthosting.co.za> Nick Coghlan added the comment: As far as "path import finder" goes, it's no more wrong than "meta path finder" and "path entry finder". A "meta path finder" is a finder that gets installed on sys.meta_path, a "path entry finder" is one that finds loaders based on a specific path entry, and the "path import finders" finds loaders based on the full path import machinery (sys.path, __path__ attributes, sys.path_hooks, sys. path_importer_cache"). As far as FileFinder goes, FilePathEntryFinder is an awful name. If we change the name at all (which I don't consider necessary, since FileFinder is just fine as a name for a finder that finds loaders for files), then more appropriate names would be FilesystemFinder or DirectoryFinder. I like the simplicity of FileFinder though and am -1 on changing it. I'm far more comfortable with the idea of explaining that the qualifiers on the "finder" and "importer" terms may convey information regarding one or more of the kind of loaders being found (FileFinder, BuiltinImporter, FrozenImporter, zipimporter), the information sources that are being searched (BuiltinImporter, FrozenImporter, zipimporter, PathEntryFinder, PathImportFinder), or how the finders are themselves retrieved (PathEntryFinder, MetaPathFinder) than I am with trying to redefine the decade old unambiguous meaning of the "importer" term as something which is both a finder and a loader. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 06:43:12 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 02 Aug 2012 04:43:12 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343882592.5.0.531347024333.issue15502@psf.upfronthosting.co.za> Eric Snow added the comment: Okay, while the dust clears, I am going to separate the two parts into different patches. :) ---------- Added file: http://bugs.python.org/file26654/issue15502_new_abc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 06:43:25 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 02 Aug 2012 04:43:25 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343882605.07.0.435940447125.issue15502@psf.upfronthosting.co.za> Changes by Eric Snow : Removed file: http://bugs.python.org/file26653/issue15502_new_abc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 06:49:34 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 02 Aug 2012 04:49:34 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343882974.88.0.0802316438034.issue15502@psf.upfronthosting.co.za> Changes by Eric Snow : Added file: http://bugs.python.org/file26655/issue15502_windows_registry_finder.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 06:50:30 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 02 Aug 2012 04:50:30 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343883030.32.0.472925795781.issue15502@psf.upfronthosting.co.za> Changes by Eric Snow : Removed file: http://bugs.python.org/file26654/issue15502_new_abc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 06:51:03 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 02 Aug 2012 04:51:03 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343883063.9.0.754611677112.issue15502@psf.upfronthosting.co.za> Changes by Eric Snow : Added file: http://bugs.python.org/file26656/issue15502_new_abc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 07:03:15 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 02 Aug 2012 05:03:15 +0000 Subject: [issue15496] harden directory removal for tests on Windows In-Reply-To: <1343614495.69.0.283818579392.issue15496@psf.upfronthosting.co.za> Message-ID: <1343883795.17.0.68538622937.issue15496@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 07:04:28 2012 From: report at bugs.python.org (Ned Deily) Date: Thu, 02 Aug 2012 05:04:28 +0000 Subject: [issue15532] "for line in file" is *still* broken in Python 2.7 on pipes In-Reply-To: <1343858198.39.0.554130035278.issue15532@psf.upfronthosting.co.za> Message-ID: <1343883868.9.0.580936911791.issue15532@psf.upfronthosting.co.za> Ned Deily added the comment: Notice in the reply to Issue3907, "with 2.6, you have to use io.open() explicitly". This is still true in Python 2.7, i.e. the new 3.x-compatible io library is not used by default in Python 2. If you want to use it with subprocess.Popen, one way is to supply a pipe with an io wrapper, perhaps something like: import io, os i, o = os.pipe() piperead = io.open(i,'rb',buffering=0) p = subprocess.Popen(..., stdout=o) See Chapter 15 of the Python 2.7 Standard Library doc for more information on the io module: http://docs.python.org/library/io.html ---------- nosy: +ned.deily resolution: -> works for me stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 07:08:20 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 02 Aug 2012 05:08:20 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343884100.49.0.504245877869.issue15502@psf.upfronthosting.co.za> Eric Snow added the comment: While ungainly a name change, this patch at least demonstrates the places that the name would have to change. ---------- Added file: http://bugs.python.org/file26657/issue15502_file_path_entry_finder_of_doom.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 07:11:02 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 02 Aug 2012 05:11:02 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343884262.19.0.918279056434.issue15502@psf.upfronthosting.co.za> Changes by Eric Snow : Added file: http://bugs.python.org/file26658/issue15502_new_abc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 07:11:21 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 02 Aug 2012 05:11:21 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343884281.8.0.283044328059.issue15502@psf.upfronthosting.co.za> Changes by Eric Snow : Removed file: http://bugs.python.org/file26656/issue15502_new_abc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 07:11:49 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 02 Aug 2012 05:11:49 +0000 Subject: [issue7443] test.support.unlink issue on Windows platform In-Reply-To: <1260026404.41.0.635406889881.issue7443@psf.upfronthosting.co.za> Message-ID: <1343884309.45.0.0740101291258.issue7443@psf.upfronthosting.co.za> Nick Coghlan added the comment: See #15496 for an alternative approach to solving this problem, at least in the test suite - as noted in that issue, the rename dance isn't sufficient when the problem gets triggered by a different sequence like: unlink(file_in_parent_dir) unlink(parent_dir) # This fails if file is still locked ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 07:14:51 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 02 Aug 2012 05:14:51 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343884491.17.0.15636654496.issue15502@psf.upfronthosting.co.za> Changes by Eric Snow : Removed file: http://bugs.python.org/file26655/issue15502_windows_registry_finder.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 07:15:52 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 02 Aug 2012 05:15:52 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343884552.34.0.88291287773.issue15502@psf.upfronthosting.co.za> Eric Snow added the comment: didn't mean to yank that one. ---------- Added file: http://bugs.python.org/file26659/issue15502_windows_registry_finder.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 07:20:09 2012 From: report at bugs.python.org (Atsuo Ishimoto) Date: Thu, 02 Aug 2012 05:20:09 +0000 Subject: [issue13119] Newline for print() is \n on Windows, and not \r\n as expected In-Reply-To: <1317934788.08.0.425265217585.issue13119@psf.upfronthosting.co.za> Message-ID: <1343884809.78.0.113718573899.issue13119@psf.upfronthosting.co.za> Atsuo Ishimoto added the comment: Test for this issue. Tested on Windows7, Ubuntu linux 12.04. I wonder why "print(1, file=sys.stderr)" returns '1' instead of '1\n'. But in Python2.7, "print >>sys.stderr, 1" also returns '1', so this might not be a problem. ---------- Added file: http://bugs.python.org/file26660/issue13119_test.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 07:44:32 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 02 Aug 2012 05:44:32 +0000 Subject: [issue15533] subprocess.Popen(cwd) documentation Message-ID: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za> New submission from Chris Jerdonek: The sentence describing Popen()'s cwd argument in the subprocess documentation seems reversed to me: http://docs.python.org/dev/library/subprocess.html#subprocess.Popen It says, "If cwd is not None, the child?s current directory will be changed to cwd before it is executed. Note that this directory is not considered when searching the executable, so you can?t specify the program?s path relative to cwd." However, when cwd is not None, it seems like you *must* specify the program's path relative to cwd. For example, when running a script containing the following using `./python.exe` from a source checkout-- p = Popen(['./python.exe', '-V'], stdout=PIPE, stderr=PIPE, cwd='temp') you get an: "OSError: [Errno 2] No such file or directory." In contrast, when you *do* specify the program's path relative to cwd, it works-- p = Popen(['../python.exe', '-V'], stdout=PIPE, stderr=PIPE, cwd='temp') Issue 6374 seems to have made the same point in its second bullet, but the issue was closed without addressing that part of it. ---------- assignee: docs at python components: Documentation keywords: easy messages: 167194 nosy: cjerdonek, docs at python priority: normal severity: normal status: open title: subprocess.Popen(cwd) documentation versions: Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 09:21:43 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Aug 2012 07:21:43 +0000 Subject: [issue15521] Dev Guide should say how to run tests in 2.7 In-Reply-To: <1343812068.2.0.0173567393654.issue15521@psf.upfronthosting.co.za> Message-ID: <3WnjVq0M5pzPfP@mail.python.org> Roundup Robot added the comment: New changeset 851adff2d434 by Ezio Melotti in branch 'default': #15521: mention that test.regrtest is necessary to run tests on 2.7. Patch by Chris Jerdonek. http://hg.python.org/devguide/rev/851adff2d434 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 09:23:45 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 02 Aug 2012 07:23:45 +0000 Subject: [issue15521] Dev Guide should say how to run tests in 2.7 In-Reply-To: <1343812068.2.0.0173567393654.issue15521@psf.upfronthosting.co.za> Message-ID: <1343892225.0.0.179808695986.issue15521@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the patch! ---------- assignee: docs at python -> ezio.melotti resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 09:38:26 2012 From: report at bugs.python.org (Tim Golden) Date: Thu, 02 Aug 2012 07:38:26 +0000 Subject: [issue15496] harden directory removal for tests on Windows In-Reply-To: <1343883795.17.0.68538622937.issue15496@psf.upfronthosting.co.za> Message-ID: <501A2E6E.9040006@timgolden.me.uk> Tim Golden added the comment: I'm +1 on the approach in principle. I'm tentative about using ctypes for this just because I don't believe we use it anywhere else. But at the least I suggest applying the patch to see how Jeremy's buildbot behaves. If there are wider objections to ctypes we could always work up a C patch. (In 3.3+ we could use the new _winapi module). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 09:58:13 2012 From: report at bugs.python.org (Ned Deily) Date: Thu, 02 Aug 2012 07:58:13 +0000 Subject: [issue10731] UnicodeDecodeError in OS X tkinter when binding to In-Reply-To: <1292685761.16.0.751551658727.issue10731@psf.upfronthosting.co.za> Message-ID: <1343894293.06.0.55633697897.issue10731@psf.upfronthosting.co.za> Ned Deily added the comment: Tcl/Tk 8.5.12 has now been released. After installing ActiveTcl 8.5.12 for OS X, your 3.2 test case that previously readily failed for me no longer does. So I hope you also find that the problem is now resolved. ---------- stage: -> committed/rejected status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 11:06:37 2012 From: report at bugs.python.org (Dmitry Dvoinikov) Date: Thu, 02 Aug 2012 09:06:37 +0000 Subject: [issue15534] xmlrpc escaping breaks on unicode \u043c Message-ID: <1343898397.75.0.0676657128653.issue15534@psf.upfronthosting.co.za> New submission from Dmitry Dvoinikov: For the following script ------------------------------------ import xmlrpc.client; from xmlrpc.client import escape text = "...\u043c......<" print(escape(text)) ------------------------------------ Python 3.3.0b1 produces ...?..<...< whereas Python 3.2 ...?......< ---------- components: Library (Lib) messages: 167199 nosy: ddvoinikov priority: normal severity: normal status: open title: xmlrpc escaping breaks on unicode \u043c type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 12:02:39 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 02 Aug 2012 10:02:39 +0000 Subject: [issue15496] harden directory removal for tests on Windows In-Reply-To: <1343614495.69.0.283818579392.issue15496@psf.upfronthosting.co.za> Message-ID: <1343901759.0.0.651464401433.issue15496@psf.upfronthosting.co.za> Nick Coghlan added the comment: My inclination is to say that using ctypes is a reasonable option for improving Windows buildbot stability in the near term, but we'd probably want to move this into _winapi long term. Adding Antoine & MvL to get their opinion. ---------- nosy: +loewis, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 12:20:40 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 02 Aug 2012 10:20:40 +0000 Subject: [issue15496] harden directory removal for tests on Windows In-Reply-To: <1343614495.69.0.283818579392.issue15496@psf.upfronthosting.co.za> Message-ID: <1343902840.5.0.0716133241106.issue15496@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I wonder why it couldn't use os.listdir to find out whether the directory is empty, and os.stat to find out whether a specific file or directory still exists. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 12:22:20 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 02 Aug 2012 10:22:20 +0000 Subject: [issue15519] finish exposing WindowsRegistryImporter in importlib In-Reply-To: <1343788168.67.0.343499108562.issue15519@psf.upfronthosting.co.za> Message-ID: <1343902940.38.0.942882710367.issue15519@psf.upfronthosting.co.za> Nick Coghlan added the comment: We'll also want to add this to the inheritance tests in test_importlib.test_abc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 12:33:29 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 02 Aug 2012 10:33:29 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343903609.6.0.0840814321813.issue15502@psf.upfronthosting.co.za> Nick Coghlan added the comment: In reviewing Eric's changes, I found what I consider a good reason to keep Finder as the root of the hierarchy: *all* finders, both meta path and path entry, will continue to share the optional "invalidate_caches" API. I'll commit a variant that has the inheritance that way around (still narrowing the "find_module" API for the new ABCs) and see how it looks to everyone. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 13:26:15 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Aug 2012 11:26:15 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <3Wnpx10Vl3zPjQ@mail.python.org> Roundup Robot added the comment: New changeset 184700df5b6a by Nick Coghlan in branch 'default': Issue #15502: Bring the importlib ABCs into line with the current state of the import protocols given PEP 420. Original patch by Eric Snow. http://hg.python.org/cpython/rev/184700df5b6a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 13:33:25 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 02 Aug 2012 11:33:25 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343907205.36.0.450059955606.issue15502@psf.upfronthosting.co.za> Nick Coghlan added the comment: Specifically, what I did was to drop "find_module" from the Finder ABC, but keep the ABC itself as a way to document the common "invalidate_caches" API. The ABC definition no longer cares whether you implement find_module() or not. MetaPathFinder then enforces find_module(), while PathEntryFinder enforces find_loader(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 13:50:21 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 02 Aug 2012 11:50:21 +0000 Subject: [issue15519] finish exposing WindowsRegistryImporter in importlib In-Reply-To: <1343788168.67.0.343499108562.issue15519@psf.upfronthosting.co.za> Message-ID: <1343908221.26.0.0699146916141.issue15519@psf.upfronthosting.co.za> Nick Coghlan added the comment: This didn't close automatically (I assume the open dependency upset matters, since it also prevented me from closing it manually the first time). Applied to trunk in http://hg.python.org/cpython/rev/a1ac1e13c5a0 (including the rename from #15502) ---------- dependencies: -Meta path finders and path entry finders are different, but share an ABC resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 13:50:36 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 02 Aug 2012 11:50:36 +0000 Subject: [issue15519] finish exposing WindowsRegistryImporter in importlib In-Reply-To: <1343788168.67.0.343499108562.issue15519@psf.upfronthosting.co.za> Message-ID: <1343908236.64.0.0217692397306.issue15519@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 13:51:08 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 02 Aug 2012 11:51:08 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343908268.03.0.423275927473.issue15502@psf.upfronthosting.co.za> Nick Coghlan added the comment: I also dealt with #15519 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 14:49:25 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Aug 2012 12:49:25 +0000 Subject: [issue15534] xmlrpc escaping breaks on unicode \u043c In-Reply-To: <1343898397.75.0.0676657128653.issue15534@psf.upfronthosting.co.za> Message-ID: <1343911765.44.0.718906783183.issue15534@psf.upfronthosting.co.za> STINNER Victor added the comment: Hum, it's a regression introduced by the super-optimized fastsearch. It is just a typo: _s => s. I renamed _s to ptr to avoid future confusion ;-) -- For your information, str.find(), str.rfind(), str.index(), str.rindex() and str.replace() are now using memchr() and memrchr() to find a substring, even if the substring contains characters outside the ASCII (U+0000-U+007F) and latin1 ranges (U+0000-U+00FF). memchr() and memrchr() are much faster than a dummy C loop, even if there are false positive. ---------- keywords: +patch nosy: +flox, haypo, loewis, pitrou Added file: http://bugs.python.org/file26661/fastsearch.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 14:50:07 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Aug 2012 12:50:07 +0000 Subject: [issue15534] xmlrpc escaping breaks on unicode \u043c In-Reply-To: <1343898397.75.0.0676657128653.issue15534@psf.upfronthosting.co.za> Message-ID: <1343911807.07.0.701929360424.issue15534@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 15:00:35 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 02 Aug 2012 13:00:35 +0000 Subject: [issue15534] xmlrpc escaping breaks on unicode \u043c In-Reply-To: <1343898397.75.0.0676657128653.issue15534@psf.upfronthosting.co.za> Message-ID: <1343912435.27.0.974044820133.issue15534@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ow, nice find. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 15:04:11 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Aug 2012 13:04:11 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <3Wns611vYtzPhs@mail.python.org> Roundup Robot added the comment: New changeset 1f8351cf00f3 by Nick Coghlan in branch 'default': Issue #15502: Bring the importlib.PathFinder docs and docstring more in line with the new import system documentation, and fix various parts of the new docs that weren't quite right given PEP 420 or were otherwise a bit misleading. Also note the key terminology problem still being discussed in the issue http://hg.python.org/cpython/rev/1f8351cf00f3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 15:06:13 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 02 Aug 2012 13:06:13 +0000 Subject: [issue15496] harden directory removal for tests on Windows In-Reply-To: <1343614495.69.0.283818579392.issue15496@psf.upfronthosting.co.za> Message-ID: <1343912773.64.0.159444191746.issue15496@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > On my machine I have programs that simply do not have an option to > ignore any directories thus causing some grief during testing. What are those programs exactly? A buildbot should ideally have a lean system install that does not interfere with the tests running. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 15:15:34 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 02 Aug 2012 13:15:34 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343913334.25.0.0972202731645.issue15502@psf.upfronthosting.co.za> Nick Coghlan added the comment: OK, that last commit (along with one I did earlier for the import statement) brought over all the fixes I was previously overly hasty in committing to Barry's importdocs branch. I've decided I can live with "regular packages" as the term for initialised packages (especially given the drawn out arguments on import-sig with the namespace package PEPs). If it becomes an anachronism by the time 4.0 rolls around, well, so be it. The last big issue to be resolved is the terminology conflict between importlib.PathFinder, "path importer" and "importer. I think the first thing to try there is a rename to "importlib.PathImportFinder" and "path import finder" to see how well it reads. My current feeling is that the result will have to be pretty horrible to make changing the long standing definition of "importer" to look like a superior option :) I'm busy for the next couple of days though, so this may not make beta2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 15:44:46 2012 From: report at bugs.python.org (Thomas Miedema) Date: Thu, 02 Aug 2012 13:44:46 +0000 Subject: [issue15535] Fix pickling of named tuples in 2.7.3 Message-ID: <1343915086.31.0.252328658724.issue15535@psf.upfronthosting.co.za> New submission from Thomas Miedema: Pickling a namedtuple Point(x=10, y=20, z=30) in Python 2.7.2 with protocol level 0 would result in something like the following output: ccopy_reg _reconstructor p0 (c__main__ Point p1 c__builtin__ tuple p2 (I10 I20 I30 tp3 tp4 Rp5 . In Python 2.7.3, the same namedtuple dumps to: ccopy_reg _reconstructor p0 (c__main__ Point p1 c__builtin__ tuple p2 (I10 I20 I30 tp3 tp4 Rp5 ccollections OrderedDict p6 ((lp7 (lp8 S'x' p9 aI10 aa(lp10 S'y' p11 aI20 aa(lp12 S'z' p13 aI30 aatp14 Rp15 b. Note the OrderedDictionary at the end. All data, the field names and the values, are duplicated, which can result in very large pickled files when using nested namedtuples. Loading both dumps with CPython 2.7.3 works. This is why this bug was not noticed any earlier. Loading the second dump with CPython or pypy 2.7.2 does not work however. CPython 2.7.3 broke forward compatibility. Attached is a patch with a fix. The patch makes pickled namedtuples forward compatibile with 2.7.2. This patch does not break backward compability with 2.7.3, since the extra OrderedDict data contained the same information as the tuple. Introduced: http://hg.python.org/cpython/diff/26d5f022eb1a/Lib/collections.py Also relevant: http://bugs.python.org/issue3065 ---------- components: Library (Lib) files: namedtuple_pickle_fix.patch keywords: patch messages: 167215 nosy: rhettinger, thomie priority: normal severity: normal status: open title: Fix pickling of named tuples in 2.7.3 type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file26662/namedtuple_pickle_fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 15:48:14 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 02 Aug 2012 13:48:14 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343879662.3.0.76705103675.issue15502@psf.upfronthosting.co.za> Message-ID: <20120802094809.0b118def@resist.wooz.org> Barry A. Warsaw added the comment: What about "Path Scanner"? Came to me in a dream, so it has to be perfect, right? :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 15:49:02 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Thu, 02 Aug 2012 13:49:02 +0000 Subject: [issue15496] harden directory removal for tests on Windows In-Reply-To: <1343912773.64.0.159444191746.issue15496@psf.upfronthosting.co.za> Message-ID: Jeremy Kloth added the comment: > What are those programs exactly? A buildbot should ideally have a lean system install that does not interfere with the tests running. My development machine has add'l programs, not the buildbot machine. Sorry is there was any confusion. I get the same occasional access denied errors when running the tests locally. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 15:49:38 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 02 Aug 2012 13:49:38 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343915378.23.0.708514454206.issue15502@psf.upfronthosting.co.za> Eric Snow added the comment: Regarding the ABCs, I'm okay with it as long as invalidate_caches() is meant to be a part of meta path finders. I had considered this while writing the patch, so how I had it wasn't a fluke. The fluke was that I didn't bring it up for discussion like I had meant to do. Anyway, my rationale was that importlib.invalidate_caches() is specific to path entry finders. My patch reflected this. If invalidates_caches() were meaningful for meta path finders then we could address that later without losing backward compatibility. As to pulling find_module() off Finder, I felt that having a distinct signature, while semantically unimportant, made a clearer distinction between the old and the new. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 15:54:53 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 02 Aug 2012 13:54:53 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343907205.36.0.450059955606.issue15502@psf.upfronthosting.co.za> Message-ID: <20120802095448.11cfec74@resist.wooz.org> Barry A. Warsaw added the comment: On Aug 02, 2012, at 11:33 AM, Nick Coghlan wrote: >Specifically, what I did was to drop "find_module" from the Finder ABC, but >keep the ABC itself as a way to document the common "invalidate_caches" >API. The ABC definition no longer cares whether you implement find_module() >or not. MetaPathFinder then enforces find_module(), while PathEntryFinder >enforces find_loader(). One problem I have, which I'm not sure how to solve, is that the protocol defines a couple of optional methods, specifically find_loader() on meta path finders, and module_repr() on loaders. You'd like for the ABC to be able to capture both the support of these methods if they exist, and their optional nature, but I don't believe that's possible with @abc.abstractmethod. Correct me if I'm wrong, but by adding these methods to the ABC, it requires subclasses to define them. I noticed this when I broke the test suite, and solved it by just adding the methods to the mocks and other test classes. But I think this is not the best solution. Maybe we need an @abc.optionalabstractmethod decorator? ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 16:01:35 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Thu, 02 Aug 2012 14:01:35 +0000 Subject: [issue15496] harden directory removal for tests on Windows In-Reply-To: <501A2E6E.9040006@timgolden.me.uk> Message-ID: Jeremy Kloth added the comment: > Tim Golden added the comment: > I'm tentative about using ctypes this just because I don't believe we use it anywhere else. ctypes is already used later in test_support so I figured it was fine to use for this as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 16:04:29 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 02 Aug 2012 14:04:29 +0000 Subject: [issue15311] Dev Guide update hook broken In-Reply-To: <1341880820.83.0.419912780964.issue15311@psf.upfronthosting.co.za> Message-ID: <1343916269.66.0.82602067571.issue15311@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Has this issue been resolved? I saw that the following change is on the web site today: http://hg.python.org/devguide/rev/851adff2d434 (though I didn't verify it immediately, just 6 hours after). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 16:08:04 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Thu, 02 Aug 2012 14:08:04 +0000 Subject: [issue15496] harden directory removal for tests on Windows In-Reply-To: <1343902840.5.0.0716133241106.issue15496@psf.upfronthosting.co.za> Message-ID: Jeremy Kloth added the comment: > I wonder why it couldn't use os.listdir to find out whether the directory is empty, and os.stat to find out whether a specific file or directory still exists. It is possible to do the same thing with just os.listdir. The use of the Find*File functions was chosen to eliminate duplicating the wait function for the two different cases. Also, it is just less resource and time intensive to use the Find*File API directly (no need to build an entire list when just testing if any entries exist). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 16:10:06 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 02 Aug 2012 14:10:06 +0000 Subject: [issue15496] harden directory removal for tests on Windows In-Reply-To: Message-ID: <1343916459.3368.1.camel@localhost.localdomain> Antoine Pitrou added the comment: > > I wonder why it couldn't use os.listdir to find out whether the directory is empty, and os.stat to find out whether a specific file or directory still exists. > > It is possible to do the same thing with just os.listdir. The use of > the Find*File functions was chosen to eliminate duplicating the wait > function for the two different cases. Also, it is just less resource > and time intensive to use the Find*File API directly (no need to build > an entire list when just testing if any entries exist). But it's certainly much easier to maintain using regular Python APIs. We would use ctypes if the functionality wasn't accessible from pure Python, but since it is, we don't want to reinvent the wheel. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 16:41:19 2012 From: report at bugs.python.org (Dave Abrahams) Date: Thu, 02 Aug 2012 14:41:19 +0000 Subject: [issue15536] re.split doesn't respect MULTILINE Message-ID: <1343918479.14.0.936812287244.issue15536@psf.upfronthosting.co.za> New submission from Dave Abrahams: This session demonstrates. See especially the very last expression evaluated >>> s='''this is the end s='''this is the end ... your only friend your only friend ... the end''' the end''' >>> re.split('^', s, re.MULTILINE) re.split('^', s, re.MULTILINE) ['this is the end\nyour only friend\nthe end'] >>> re.split('t', s, re.MULTILINE) re.split('t', s, re.MULTILINE) ['', 'his is ', 'he end\nyour only friend\n', 'he end'] >>> re.split('\n', s, re.MULTILINE) re.split('\n', s, re.MULTILINE) ['this is the end', 'your only friend', 'the end'] >>> re.split('(?<=\n)', s, re.MULTILINE) re.split('(?<=\n)', s, re.MULTILINE) ['this is the end\nyour only friend\nthe end'] >>> re.split('^y', s, re.MULTILINE) re.split('^y', s, re.MULTILINE) ['this is the end\nyour only friend\nthe end'] >>> re.split('$', s, re.MULTILINE) re.split('$', s, re.MULTILINE) ['this is the end\nyour only friend\nthe end'] >>> re.split('$\n', s, re.MULTILINE) re.split('$\n', s, re.MULTILINE) ['this is the end\nyour only friend\nthe end'] >>> re.split('\n', s, re.MULTILINE) re.split('\n', s, re.MULTILINE) ['this is the end', 'your only friend', 'the end'] >>> re.split('^t', s, re.MULTILINE) re.split('^t', s, re.MULTILINE) ['', 'his is the end\nyour only friend\nthe end'] >>> re.split('^t', s) re.split('^t', s) ['', 'his is the end\nyour only friend\nthe end'] >>> ---------- components: Regular Expressions messages: 167224 nosy: dabrahams, ezio.melotti, mrabarnett priority: normal severity: normal status: open title: re.split doesn't respect MULTILINE type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 16:43:44 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 02 Aug 2012 14:43:44 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343918624.47.0.437151635651.issue15502@psf.upfronthosting.co.za> Eric Snow added the comment: I wish "path subsystem finder" weren't so long. Then PathFinder would probably still be appropriate for the class name (as FileFinder is appropriate for FilePathEntryFinder :). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 16:44:42 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Thu, 02 Aug 2012 14:44:42 +0000 Subject: [issue15496] harden directory removal for tests on Windows In-Reply-To: <1343614495.69.0.283818579392.issue15496@psf.upfronthosting.co.za> Message-ID: <1343918682.25.0.265154047174.issue15496@psf.upfronthosting.co.za> Jeremy Kloth added the comment: OK, here is another patch that uses just os.listdir ---------- Added file: http://bugs.python.org/file26663/support.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 16:45:22 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 02 Aug 2012 14:45:22 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343918722.39.0.366224243698.issue15502@psf.upfronthosting.co.za> Eric Snow added the comment: > Maybe we need an @abc.optionalabstractmethod decorator? Perhaps you are kidding, but I've had a similar thought on a number of occasions. For kicks, I'll float this by python-ideas. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 16:58:57 2012 From: report at bugs.python.org (Dave Abrahams) Date: Thu, 02 Aug 2012 14:58:57 +0000 Subject: [issue15537] MULTILINE confuses re.split Message-ID: <1343919537.43.0.272512350755.issue15537@psf.upfronthosting.co.za> New submission from Dave Abrahams: compare the output of $ python -c "open('/tmp/tst','w').write(100*'x\n');import re;print len(re.split('\n(?=x)', open('/tmp/tst').read()))" 100 with $ python -c "open('/tmp/tst','w').write(100*'x\n');import re;print len(re.split('\n(?=x)', open('/tmp/tst').read(), re.MULTILINE))" 9 ---------- components: Regular Expressions messages: 167228 nosy: dabrahams, ezio.melotti, mrabarnett priority: normal severity: normal status: open title: MULTILINE confuses re.split versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 17:11:39 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 02 Aug 2012 15:11:39 +0000 Subject: [issue14873] Windows devguide: clarification for build errors due to missing optional dependencies In-Reply-To: <1337635934.97.0.00774228484409.issue14873@psf.upfronthosting.co.za> Message-ID: <1343920299.02.0.760019071834.issue14873@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I also think this would be worth a note. May I propose a patch? ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 17:12:28 2012 From: report at bugs.python.org (Chris Calloway) Date: Thu, 02 Aug 2012 15:12:28 +0000 Subject: [issue15518] Provide test coverage for filecmp.dircmp.report methods. In-Reply-To: <1343786533.33.0.657671203467.issue15518@psf.upfronthosting.co.za> Message-ID: <1343920348.8.0.813444677162.issue15518@psf.upfronthosting.co.za> Chris Calloway added the comment: Well, really, the reason I'm deferring is to get the patch accepted, because it seems kind of unacceptable for standard library modules not to have full test coverage. So far, I don't see evidence that the issue has even been triaged. Of the three approaches, regex, cd, or decoration, which do you see as most likely to be accepted? I understand that cd might be common in some tests. But it also appears that, at least in test_filecmp, some pretty heinous practices are also common like piling a ridiculous number of asserts into one test method. (And I'll fix that, too.) I do really appreciate your advice, core developer or not. You are the only one providing advice here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 17:19:20 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 02 Aug 2012 15:19:20 +0000 Subject: [issue15311] Dev Guide update hook broken In-Reply-To: <1341880820.83.0.419912780964.issue15311@psf.upfronthosting.co.za> Message-ID: <1343920760.01.0.210579831579.issue15311@psf.upfronthosting.co.za> Ezio Melotti added the comment: I think MvL fixed it. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 17:24:22 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 02 Aug 2012 15:24:22 +0000 Subject: [issue15496] harden directory removal for tests on Windows In-Reply-To: <1343614495.69.0.283818579392.issue15496@psf.upfronthosting.co.za> Message-ID: <1343921062.13.0.768591280026.issue15496@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I fail to see the point of not using os.stat. IIUC, Windows will delete the file once the last handle is been closed. Since stat will close any handle it temporarily gets, it will not prolong the live of the file; the file will still go away when the last process has closed it. Performance is not an issue at all here, since we are waiting for the deletion of the file anyway. So checking whether the file is in the directory listing is fine with me as well. Unless someone can demonstrate how os.stat can prevent removal of the file, I'd like to see the comment corrected, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 17:25:13 2012 From: report at bugs.python.org (Philipp Hagemeister) Date: Thu, 02 Aug 2012 15:25:13 +0000 Subject: [issue15538] Avoid nonstandard s6_addr8 Message-ID: <1343921113.22.0.952708095298.issue15538@psf.upfronthosting.co.za> New submission from Philipp Hagemeister: The s6_addr8 field of in6_addr structs is nonstandard, and therefore not supported on all platforms (android in my example). cpython's socket module should use the standard s6_addr field instead. ---------- components: IO hgrepos: 144 messages: 167233 nosy: phihag priority: normal severity: normal status: open title: Avoid nonstandard s6_addr8 type: compile error versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 17:27:20 2012 From: report at bugs.python.org (Philipp Hagemeister) Date: Thu, 02 Aug 2012 15:27:20 +0000 Subject: [issue15538] Avoid nonstandard s6_addr8 In-Reply-To: <1343921113.22.0.952708095298.issue15538@psf.upfronthosting.co.za> Message-ID: <1343921240.93.0.859505633588.issue15538@psf.upfronthosting.co.za> Changes by Philipp Hagemeister : ---------- keywords: +patch Added file: http://bugs.python.org/file26664/issue15538.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 17:30:44 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 02 Aug 2012 15:30:44 +0000 Subject: [issue15311] Dev Guide update hook broken In-Reply-To: <1341880820.83.0.419912780964.issue15311@psf.upfronthosting.co.za> Message-ID: <1343921444.79.0.209863718292.issue15311@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I added an automated build process, yes. However, the current text is incorrect as it states that the build occurs immediately through a hook. This is not the case; instead, there is a cronjob that pulls changes. I refuse to report the frequency with which this happens, and advise against documenting the status quo, since that may again get outdated. It should be safe to say that changes should be published within a day. ---------- priority: critical -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 17:31:14 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 02 Aug 2012 15:31:14 +0000 Subject: [issue15311] Dev Guide update procedure documentation in dev guide outdated In-Reply-To: <1341880820.83.0.419912780964.issue15311@psf.upfronthosting.co.za> Message-ID: <1343921474.21.0.966125610252.issue15311@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- title: Dev Guide update hook broken -> Dev Guide update procedure documentation in dev guide outdated _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 17:36:06 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 02 Aug 2012 15:36:06 +0000 Subject: [issue15538] Avoid nonstandard s6_addr8 In-Reply-To: <1343921113.22.0.952708095298.issue15538@psf.upfronthosting.co.za> Message-ID: <1343921766.64.0.660846650278.issue15538@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- versions: -Python 2.6, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 17:50:41 2012 From: report at bugs.python.org (Brett Cannon) Date: Thu, 02 Aug 2012 15:50:41 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343922641.85.0.583010464085.issue15502@psf.upfronthosting.co.za> Brett Cannon added the comment: In terms of invalidate_caches(), it could easily be changed to walk sys.meta_path and to call the method on the meta path finders. Not sure if that generalization is reasonable or not, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 17:51:35 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 02 Aug 2012 15:51:35 +0000 Subject: [issue15518] Provide test coverage for filecmp.dircmp.report methods. In-Reply-To: <1343786533.33.0.657671203467.issue15518@psf.upfronthosting.co.za> Message-ID: <1343922695.66.0.659358115557.issue15518@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > Of the three approaches, regex, cd, or decoration, which do you see as most likely to be accepted? In my limited experience, I think the patch most likely to be accepted is the one that changes existing code the least. That would mean adding to the practices you're observing, unfortunately. Personally, I would go with trying to use test.support.temp_cwd() and doing an exact string match (since it provides a more precise test) -- taking appropriate cross-platform measures as necessary. > I do really appreciate your advice, core developer or not. You are the only one providing advice here. You're welcome. I'm in the same boat as you, so I know how it feels. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 18:11:35 2012 From: report at bugs.python.org (Atsuo Ishimoto) Date: Thu, 02 Aug 2012 16:11:35 +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: <1343923895.38.0.0190624713813.issue15216@psf.upfronthosting.co.za> Changes by Atsuo Ishimoto : ---------- nosy: +ishimoto _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 18:18:18 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 02 Aug 2012 16:18:18 +0000 Subject: [issue15538] Avoid nonstandard s6_addr8 In-Reply-To: <1343921113.22.0.952708095298.issue15538@psf.upfronthosting.co.za> Message-ID: <1343924298.6.0.366707379341.issue15538@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Android doesn't have getaddrinfo()? getaddrinfo.c and getnameinfo.c only get compiled when the OS doesn't provide the same-named functions. ---------- nosy: +pitrou stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 18:20:27 2012 From: report at bugs.python.org (Jonathan Paugh) Date: Thu, 02 Aug 2012 16:20:27 +0000 Subject: [issue14905] zipimport.c needs to support namespace packages when no 'directory' entry exists In-Reply-To: <1337905627.12.0.841961188355.issue14905@psf.upfronthosting.co.za> Message-ID: <1343924427.18.0.120783315284.issue14905@psf.upfronthosting.co.za> Changes by Jonathan Paugh : ---------- nosy: +jpaugh _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 18:21:34 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 02 Aug 2012 16:21:34 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343924494.47.0.425722541202.issue15502@psf.upfronthosting.co.za> Eric Snow added the comment: Not to detract from the fun terminology discussion, but I have lingering concerns with the ABC inheritance model here. Looking over changeset 184700df5b6a, I'm still fine with the change if invalidate_caches() is appropriate for both. If not or if we don't know yet, I think we should hold off on moving invalidate_caches() up into Finder. If it is okay then we should add meta path finder traversal to importlib.invalidate_caches(). Either way there's a (not substantial) loose end. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 18:24:36 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Aug 2012 16:24:36 +0000 Subject: [issue15539] Fixing Tools/scripts/pindent.py Message-ID: <1343924676.33.0.76595941249.issue15539@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Here is a patch which fixes some bugs in Tools/scripts/pindent.py and modernizes it with regard to the new Python features abilities that have made since 1994. 1. Now pindent works with "with". 2. Now pindent does not produce improper indentation (tabs by default for space-indented file). It uses for the end-marks indentation the same sequence of whitespaces that for start operator indentation. 3. Now pindent works with escaped newline "\\\n" at start of line and after "class" and "def". 4. Now pindent does not produce indentation for empty line. 5. Fixed one type in help message. 6. Using io.StringIO. 7. Using booleans, augmented assignments, list.pop(), with operators, etc. ---------- components: Demos and Tools files: pindent.patch keywords: patch messages: 167239 nosy: storchaka priority: normal severity: normal status: open title: Fixing Tools/scripts/pindent.py type: behavior versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file26665/pindent.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 19:05:07 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Aug 2012 17:05:07 +0000 Subject: [issue15537] MULTILINE confuses re.split In-Reply-To: <1343919537.43.0.272512350755.issue15537@psf.upfronthosting.co.za> Message-ID: <1343927107.0.0.971557080207.issue15537@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: re.split = split(pattern, string, maxsplit=0, flags=0) Split the source string by the occurrences of the pattern, returning a list containing the resulting substrings. If capturing parentheses are used in pattern, then the text of all groups in the pattern are also returned as part of the resulting list. If maxsplit is nonzero, at most maxsplit splits occur, and the remainder of the string is returned as the final element of the list. maxsplit=0 in your fist example and maxsplit=8 (re.MULTILINE is 8) in your second example. This is not a bug, this is a wrong understanding. ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 19:06:50 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Aug 2012 17:06:50 +0000 Subject: [issue15536] re.split doesn't respect MULTILINE In-Reply-To: <1343918479.14.0.936812287244.issue15536@psf.upfronthosting.co.za> Message-ID: <1343927210.71.0.999432393027.issue15536@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Same as for issue 15537. ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 19:23:01 2012 From: report at bugs.python.org (Marc Culler) Date: Thu, 02 Aug 2012 17:23:01 +0000 Subject: [issue10731] UnicodeDecodeError in OS X tkinter when binding to In-Reply-To: <1292685761.16.0.751551658727.issue10731@psf.upfronthosting.co.za> Message-ID: <1343928181.76.0.603194434328.issue10731@psf.upfronthosting.co.za> Marc Culler added the comment: Thanks, Ned! It seems to be completely fixed by 8.5.12. ---------- nosy: +Marc.Culler _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 19:29:00 2012 From: report at bugs.python.org (Matthew Barnett) Date: Thu, 02 Aug 2012 17:29:00 +0000 Subject: [issue15537] MULTILINE confuses re.split In-Reply-To: <1343919537.43.0.272512350755.issue15537@psf.upfronthosting.co.za> Message-ID: <1343928540.67.0.778601534302.issue15537@psf.upfronthosting.co.za> Matthew Barnett added the comment: There are actually 2 issues here: 1. The third argument is 'maxsplit', the fourth is 'flags'. 2. It never splits on a zero-width match. See issue 3262. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 20:17:01 2012 From: report at bugs.python.org (Brett Cannon) Date: Thu, 02 Aug 2012 18:17:01 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343931421.5.0.329733444065.issue15502@psf.upfronthosting.co.za> Brett Cannon added the comment: I guess the question is how extensive do we want this cache validation to go? Do we think that only path entry finders stored in sys.path_importer_cache will have stuff to be cleared, or do we think stuff on sys.meta_path or sys.path_hooks will have things that need to get cleared as well? The more I think about it, the more I want to generalize this to the point of sys.meta_path and then having PathFinder handle sys.path_hooks and sys.path_importer_cache. That stays in line with import not caring about sys.path, etc. and it really just being some cruft left over from Python 2. Regardless, though, I would not define invalidate_caches() on Finder and instead define it separately on PathEntryFinder and MetaPathFinder. It's new in 3.3 so it doesn't need to be on Finder for backwards-compatibility, and it isn't inherent to finders. Plus if Finder goes away we will have to push it up to the other ABCs anyway. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 20:31:39 2012 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 02 Aug 2012 18:31:39 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343932299.81.0.556898848228.issue15502@psf.upfronthosting.co.za> Eric V. Smith added the comment: I think the cache invalidation should be moved to the sys.meta_path level. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 20:42:18 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Aug 2012 18:42:18 +0000 Subject: [issue15538] Avoid nonstandard s6_addr8 In-Reply-To: <1343921113.22.0.952708095298.issue15538@psf.upfronthosting.co.za> Message-ID: <3Wp0c72VhCzPct@mail.python.org> Roundup Robot added the comment: New changeset 86558ff7ce33 by Antoine Pitrou in branch '2.7': Issue #15538: Fix compilation of the getnameinfo() / getaddrinfo() emulation code. http://hg.python.org/cpython/rev/86558ff7ce33 New changeset 547f3a55a216 by Antoine Pitrou in branch '3.2': Issue #15538: Fix compilation of the getnameinfo() / getaddrinfo() emulation code. http://hg.python.org/cpython/rev/547f3a55a216 New changeset 61a56e982e98 by Antoine Pitrou in branch 'default': Issue #15538: Fix compilation of the getnameinfo() / getaddrinfo() emulation code. http://hg.python.org/cpython/rev/61a56e982e98 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 20:44:08 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 02 Aug 2012 18:44:08 +0000 Subject: [issue15538] Avoid nonstandard s6_addr8 In-Reply-To: <1343921113.22.0.952708095298.issue15538@psf.upfronthosting.co.za> Message-ID: <1343933048.58.0.374811031835.issue15538@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, I couldn't test the patch as getipnodebyname / getipnodebyaddr don't exist here, but I committed it anyway. If it still doesn't work, please re-open the issue. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 21:46:57 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 02 Aug 2012 19:46:57 +0000 Subject: [issue14873] Windows devguide: clarification for build errors due to missing optional dependencies In-Reply-To: <1337635934.97.0.00774228484409.issue14873@psf.upfronthosting.co.za> Message-ID: <1343936817.43.0.567348472578.issue14873@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I am attaching a proposed patch for this issue. I also did not know whether the errors were normal when building with Windows for the first time. ---------- Added file: http://bugs.python.org/file26666/issue-14873-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 22:08:14 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 02 Aug 2012 20:08:14 +0000 Subject: [issue15311] Dev Guide update procedure documentation in dev guide outdated In-Reply-To: <1341880820.83.0.419912780964.issue15311@psf.upfronthosting.co.za> Message-ID: <1343938094.38.0.855179213249.issue15311@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Attaching proposed wording along the lines Martin suggested. ---------- keywords: +patch Added file: http://bugs.python.org/file26667/issue-15311-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 22:16:45 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Aug 2012 20:16:45 +0000 Subject: [issue13119] Newline for print() is \n on Windows, and not \r\n as expected In-Reply-To: <1343884809.78.0.113718573899.issue13119@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > I wonder why "print(1, file=sys.stderr)" returns '1' instead of '1\n'. I suppose that you mean "returns '1\n' instead of '1'". This is a major change between Python 2 and Python 3. Use print(1, end=' ') if you want the same behaviour. See: http://docs.python.org/dev/whatsnew/3.0.html#print-is-a-function You can also use the print() as a function in Python 2 using "from __future__ import print_function": http://docs.python.org/dev/whatsnew/2.6.html#pep-3105-print-as-a-function I never liked "print expr," because it looks like a typo or an ugly hack. It's easy to add a comma by mistake. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 22:28:27 2012 From: report at bugs.python.org (Phillip J. Eby) Date: Thu, 02 Aug 2012 20:28:27 +0000 Subject: [issue15295] Import machinery documentation In-Reply-To: <1341755083.83.0.00364845964194.issue15295@psf.upfronthosting.co.za> Message-ID: <1343939307.28.0.675883632818.issue15295@psf.upfronthosting.co.za> Phillip J. Eby added the comment: Hope I'm not too late to the bikeshed painting party; just wanted to chip in with the suggestion of "self-contained package" for non-namespace packages. (i.e., a self-contained package is one that cannot be split across different sys.path entries due to its use of an __init__ module). Also, technically, namespace portions do not only contribute subpackages; they can contribute modules as well. Another point of possible confusion: meta finders and path finders are both described as "hooks", but this terminology seems in conflict with the use of "hook" as describing a callable on path_hooks. Perhaps we could drop the term "hook" from this section, and retitle it "Import System Extensions" and say you can extend the system by writing meta finders and path entry finders. This would let the term "hook" be the exclusive property of path_hooks, which is how you extend the import system to use your custom finders. The statement about __path__ being a list is also out-of-date; as of PEP 420, it can be an immutable, iterable object. Specification-wise, __path__ need only be a re-iterable object, and people reading its value must NOT assume that it's a list or even indexable. The term "sys path finder" should also be replaced by "path entry finder". The former term is both incorrect and misleading, as it both implies that such a finder actually searches sys.path, and that it is exclusive to sys.path. Path entry finders are used to look for modules within a location specified by a "path entry" - a string found in sys.path or in a __path__ attribute. The term "path importer" is also horribly confusing in context... after some reflection, I suggest the following additional terminology changes: 1. Replace "meta path finder" with "import handler" 2. Replace "path importer" with "sys.path import handler" Now we can say that you extend the import system by adding import handlers to sys.meta_path, and that one of the default handlers is the sys.path import handler, which processes imports using sys.path and module __path__ attributes. The sys.path import handler can of course in turn be extended by adding path hooks to sys.path_hooks, which are used to create module finder objects for the path entry strings found in sys.path and module __path__ attributes. A path hook must return a finder object, which implements similar methods to those of an import handler, but with some important differences. Whew. It's a bit of a mouthful, but I think that this set of terms would keep all the roles and functions clear, along with their relationships to one another. In addition, I think it provides greater clarity as to which pieces you need to extend when, why, and how. What do you think? ---------- nosy: +pje _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 22:34:07 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 02 Aug 2012 20:34:07 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343939647.03.0.826287412173.issue15502@psf.upfronthosting.co.za> Eric Snow added the comment: Good points, Brett. While I still favor my posted patch, wouldn't Nick's commit still be okay (once invalidate_cache() is added appropriately)? Or would it be confusing to people to have this "Finder" class that no one is actually supposed to use? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 22:35:33 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 02 Aug 2012 20:35:33 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343939733.5.0.0526230086228.issue15502@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- Removed message: http://bugs.python.org/msg167252 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 22:35:46 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 02 Aug 2012 20:35:46 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343939746.02.0.824527038555.issue15502@psf.upfronthosting.co.za> Eric Snow added the comment: Good points, Brett. While I still favor my posted patch, wouldn't Nick's commit still be okay? Or would it be confusing to people to have this "Finder" class that no one is actually supposed to use? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 23:09:18 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Aug 2012 21:09:18 +0000 Subject: [issue15534] xmlrpc escaping breaks on unicode \u043c In-Reply-To: <1343898397.75.0.0676657128653.issue15534@psf.upfronthosting.co.za> Message-ID: <3Wp3sm5hKgzPfh@mail.python.org> Roundup Robot added the comment: New changeset 0e95b61af859 by Victor Stinner in branch 'default': Close #15534: Fix a typo in the fast search function of the string library (_s => s) http://hg.python.org/cpython/rev/0e95b61af859 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 23:10:37 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Aug 2012 21:10:37 +0000 Subject: [issue15534] xmlrpc escaping breaks on unicode \u043c In-Reply-To: <1343898397.75.0.0676657128653.issue15534@psf.upfronthosting.co.za> Message-ID: <1343941837.9.0.58427239096.issue15534@psf.upfronthosting.co.za> STINNER Victor added the comment: The issue should be fixed, thanks for the report! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 23:10:46 2012 From: report at bugs.python.org (Dave Malcolm) Date: Thu, 02 Aug 2012 21:10:46 +0000 Subject: [issue15540] Python 3.3 and numpy Message-ID: <1343941846.47.0.970447396436.issue15540@psf.upfronthosting.co.za> New submission from Dave Malcolm: I've been trying to get numpy working with Python 3.3, and to so I had to make some changes to CPython - hence I'm posting this to the Python bug tracker. numpy pokes at the insides of PyUnicodeObject in a few places and is thus affected by the PEP 393 changes in Python 3.3 I'm attaching my latest work-in-progress patch for numpy, which mostly works (it has 3 remaining errors). AIUI, the "numpy.str_" type subclasses PyUnicodeObject but with its own custom allocator, which takes a size (this is called in PyArray_Scalar when type_num == NPY_UNICODE). unicode_new_subtype calls tp_alloc but passes in 0 for the size, so we can't use that. So I had to reimplement parts of unicode creation in-place within numpy's PyArray_Scalar, copying macros from out of cpython's unicodeobject.c The other wart is that, AIUI, numpy supports byte-swapping the values within an array, and when this is done for a unicode array, it byte-swaps the 4-byte UCS4 values. At that point, it's unlikely that the resulting 4-byte values are below 0x10ffff, leading to various failures from inside CPython's unicode handling. So I hacked those test from out of CPython :) I'm attaching the diff I've got against cpython (clearly just a hack at this stage). I may of course be misunderstanding the insides of numpy. With these changes, the numpy test suite runs, with just these remaining errors: ====================================================================== ERROR: Ticket #16 ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/david/coding/python3.3/local-install/lib/python3.3/site-packages/numpy/core/tests/test_regression.py", line 41, in test_pickle_transposed b = pickle.load(f) EOFError ====================================================================== ERROR: test_power_zero (test_umath.TestPower) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/david/coding/python3.3/local-install/lib/python3.3/site-packages/numpy/core/tests/test_umath.py", line 139, in test_power_zero assert_complex_equal(np.power(zero, 0+1j), cnan) RuntimeWarning: invalid value encountered in power ====================================================================== ERROR: Failure: ValueError (can't handle version 187 of numpy.ndarray pickle) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/david/coding/python3.3/local-install/lib/python3.3/site-packages/nose-1.1.2-py3.3.egg/nose/failure.py", line 37, in runTest raise self.exc_class(self.exc_val).with_traceback(self.tb) File "/home/david/coding/python3.3/local-install/lib/python3.3/site-packages/nose-1.1.2-py3.3.egg/nose/loader.py", line 232, in generate for test in g(): File "/home/david/coding/python3.3/local-install/lib/python3.3/site-packages/numpy/lib/tests/test_format.py", line 429, in test_roundtrip arr2 = roundtrip(arr) File "/home/david/coding/python3.3/local-install/lib/python3.3/site-packages/numpy/lib/tests/test_format.py", line 420, in roundtrip arr2 = format.read_array(f2) File "/home/david/coding/python3.3/local-install/lib/python3.3/site-packages/numpy/lib/format.py", line 449, in read_array array = pickle.load(fp) ValueError: can't handle version 187 of numpy.ndarray pickle ---------------------------------------------------------------------- Ran 4776 tests in 68.189s FAILED (KNOWNFAIL=6, SKIP=1, errors=3) ---------- components: Interpreter Core files: get-numpy-working-with-python-3.3.patch keywords: patch messages: 167256 nosy: dmalcolm priority: normal severity: normal status: open title: Python 3.3 and numpy versions: Python 3.3 Added file: http://bugs.python.org/file26668/get-numpy-working-with-python-3.3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 23:11:05 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Aug 2012 21:11:05 +0000 Subject: [issue13119] Newline for print() is \n on Windows, and not \r\n as expected In-Reply-To: <1317934788.08.0.425265217585.issue13119@psf.upfronthosting.co.za> Message-ID: <1343941865.42.0.674227306917.issue13119@psf.upfronthosting.co.za> STINNER Victor added the comment: > It would be nice to fix this before Python 3.3 final. @Georg: So, what do you think? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 23:11:30 2012 From: report at bugs.python.org (Dave Malcolm) Date: Thu, 02 Aug 2012 21:11:30 +0000 Subject: [issue15540] Python 3.3 and numpy In-Reply-To: <1343941846.47.0.970447396436.issue15540@psf.upfronthosting.co.za> Message-ID: <1343941890.07.0.16503652747.issue15540@psf.upfronthosting.co.za> Changes by Dave Malcolm : Added file: http://bugs.python.org/file26669/hack-out-test-against-MAX_UNICODE-from-cpython-3.3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 23:12:31 2012 From: report at bugs.python.org (Dave Malcolm) Date: Thu, 02 Aug 2012 21:12:31 +0000 Subject: [issue15540] Python 3.3 and numpy In-Reply-To: <1343941846.47.0.970447396436.issue15540@psf.upfronthosting.co.za> Message-ID: <1343941951.18.0.527057800206.issue15540@psf.upfronthosting.co.za> Changes by Dave Malcolm : ---------- nosy: +haypo, loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 23:13:16 2012 From: report at bugs.python.org (Alex Gaynor) Date: Thu, 02 Aug 2012 21:13:16 +0000 Subject: [issue15540] Python 3.3 and numpy In-Reply-To: <1343941846.47.0.970447396436.issue15540@psf.upfronthosting.co.za> Message-ID: <1343941996.69.0.271700742423.issue15540@psf.upfronthosting.co.za> Changes by Alex Gaynor : ---------- nosy: +alex _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 23:16:05 2012 From: report at bugs.python.org (Dave Malcolm) Date: Thu, 02 Aug 2012 21:16:05 +0000 Subject: [issue15540] Python 3.3 and numpy In-Reply-To: <1343941846.47.0.970447396436.issue15540@psf.upfronthosting.co.za> Message-ID: <1343942165.29.0.285027323454.issue15540@psf.upfronthosting.co.za> Changes by Dave Malcolm : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 23:16:22 2012 From: report at bugs.python.org (Dave Malcolm) Date: Thu, 02 Aug 2012 21:16:22 +0000 Subject: [issue15540] Python 3.3 and numpy In-Reply-To: <1343941846.47.0.970447396436.issue15540@psf.upfronthosting.co.za> Message-ID: <1343942182.98.0.57572374557.issue15540@psf.upfronthosting.co.za> Changes by Dave Malcolm : ---------- nosy: +teoliphant _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 23:24:17 2012 From: report at bugs.python.org (Brett Cannon) Date: Thu, 02 Aug 2012 21:24:17 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343942657.48.0.771910938308.issue15502@psf.upfronthosting.co.za> Brett Cannon added the comment: Nick's current patch is fine, although I would add back in invalidate_caches() into MetaPathFinder and PathEntryFinder where they do nothing but return NotImplemented as a form of no-op. I know you have a python-ideas discussion going about optional abstractmethod, but until that's settled I would rather have something there to document in code what is supported as part of the API. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 23:31:36 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 02 Aug 2012 21:31:36 +0000 Subject: [issue15540] Python 3.3 and numpy In-Reply-To: <1343941846.47.0.970447396436.issue15540@psf.upfronthosting.co.za> Message-ID: <1343943096.93.0.587867607831.issue15540@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 23:48:58 2012 From: report at bugs.python.org (Brett Cannon) Date: Thu, 02 Aug 2012 21:48:58 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343944138.17.0.0106644320993.issue15502@psf.upfronthosting.co.za> Brett Cannon added the comment: As for Finder containing nothing significant, that's a side-effect of the cleanup and why Finder should get deprecated, especially since the contract that a Finder implements find_module() is no longer being enforced. Tying MetaPathFinder and PathEntryFinder together because they are conceptually finders is just not useful from a programming perspective since their APIs have no overlap except for invalidate_caches(), which if generalized, is just happenstance and not by explicit design. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 23:52:13 2012 From: report at bugs.python.org (Ned Batchelder) Date: Thu, 02 Aug 2012 21:52:13 +0000 Subject: [issue15541] logging.exception doesn't accept 'extra' Message-ID: <1343944333.27.0.175563876294.issue15541@psf.upfronthosting.co.za> New submission from Ned Batchelder: The logging.exception method differs from .debug(), .info(), .warning(), .error() and .critical() in that it does not accept an `extra` keyword argument. There seems to be no reason for this. The docs are misleading about this. They say, "The arguments are interpreted as for debug()." Changing exception() to this would take care of it:: def exception(self, msg, *args, **kwargs): """ Convenience method for logging an ERROR with exception information. """ kwargs['exc_info'] = 1 self.error(msg, *args, **kwargs) ---------- components: Library (Lib) messages: 167260 nosy: nedbat priority: normal severity: normal status: open title: logging.exception doesn't accept 'extra' type: behavior versions: Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 2 23:55:37 2012 From: report at bugs.python.org (Brett Cannon) Date: Thu, 02 Aug 2012 21:55:37 +0000 Subject: [issue15473] importlib no longer uses imp.NullImporter In-Reply-To: <1343414217.14.0.255366402583.issue15473@psf.upfronthosting.co.za> Message-ID: <1343944537.26.0.562998605052.issue15473@psf.upfronthosting.co.za> Brett Cannon added the comment: Did this get addressed in the final doc update? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 00:02:11 2012 From: report at bugs.python.org (Stefan Krah) Date: Thu, 02 Aug 2012 22:02:11 +0000 Subject: [issue15540] Python 3.3 and numpy In-Reply-To: <1343941846.47.0.970447396436.issue15540@psf.upfronthosting.co.za> Message-ID: <1343944931.23.0.312544560733.issue15540@psf.upfronthosting.co.za> Stefan Krah added the comment: A couple of days ago there was another effort by Ond?ej ?ert?k to get NumPy working with 3.3, see the thread starting here: http://comments.gmane.org/gmane.comp.python.numeric.general/51087 I participated in that discussion and we hit the same problem with the byte-swapped arrays: Since the generated Unicode strings are invalid, the consistency checks fail in debug mode. I wonder if taking out that assert is the right thing though: The use case is pretty unique; could NumPy not convert these byte-swapped arrays to uint32? ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 00:13:59 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 02 Aug 2012 22:13:59 +0000 Subject: [issue15540] Python 3.3 and numpy In-Reply-To: <1343941846.47.0.970447396436.issue15540@psf.upfronthosting.co.za> Message-ID: <1343945639.08.0.871169965686.issue15540@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The byte swapping in numpy is clearly a misfeature when applied to Unicode. I don't think Python should support that, and I can't imagine anybody is using this for a purpose that couldn't also be achieved in a better way. Not sure why you are submitting these patches here - consider this one rejected. I'm also not sure why you posted the numpy patch here; we cannot process it in any meaningful way. If you just need to find a place in the web to post it, please use wiki.python.org. In general, I'm (personally) quite opposed to using the tracker for work-in-progress. Tracker issues should be actionable by core committer (reject, commit, request further changes). If the author is aware that it is not ready for review yet, it shouldn't go into the tracker. If you primarily wanted to report these incompatibilies: that's appreciated. I can add them to http://www.python.org/dev/peps/pep-0393/#deprecations-removals-and-incompatibilities I don't think anything can be done about this: any C extension type subclassing the Unicode type needs to be reviewed; I don't think any reasonable backwards compatibility can be applied. This is unfortunate, but without a good solution. Likewise, code that mutates what is designed to be an immutable object is prone to break. I have no regrets about this breakage. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 00:14:10 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 02 Aug 2012 22:14:10 +0000 Subject: [issue15473] importlib no longer uses imp.NullImporter In-Reply-To: <1343944537.26.0.562998605052.issue15473@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: Barry covered it in a footnote ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 00:16:48 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 02 Aug 2012 22:16:48 +0000 Subject: [issue15295] Import machinery documentation In-Reply-To: <1343939307.28.0.675883632818.issue15295@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: We changed quite a bit already as we tried to make everything consistent, including the importlib ABCs. Current version is on trunk, current discussion is in #15502 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 00:23:28 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 02 Aug 2012 22:23:28 +0000 Subject: [issue15403] Refactor package creation support code into a common location In-Reply-To: <1342782793.3.0.140383152387.issue15403@psf.upfronthosting.co.za> Message-ID: <1343946208.85.0.443452215329.issue15403@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Attaching an updated patch. Changes include: 1. Cleans up and expands support API to include creating nested directory structures (for use in the filecmp tests, for example). 2. Adds unit tests for the full API (similar to test_support.py). 3. Refactors test_filecmp and test_import to use the support code, in addition to test_runpy and test_cmd_line_script. We can remove some of these refactorings if you think it does not add much at this point. 4. Puts changes in package_helper.py for now (until issue 15494 is done). I didn't put them in script_helper.py to avoid creating a circular dependency. ---------- Added file: http://bugs.python.org/file26670/issue-15403-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 00:23:43 2012 From: report at bugs.python.org (Aaron Staley) Date: Thu, 02 Aug 2012 22:23:43 +0000 Subject: [issue15542] Documentation incorrectly suggests __init__ called after direct __new__ call Message-ID: <1343946223.73.0.562621858875.issue15542@psf.upfronthosting.co.za> New submission from Aaron Staley: The documentation for __new__ at http://docs.python.org/reference/datamodel.html#object.__new__ is: """ object.__new__(cls[, ...]) Called to create a new instance of class cls. __new__() is a static method (special-cased so you need not declare it as such) that takes the class of which an instance was requested as its first argument. The remaining arguments are those passed to the object constructor expression (the call to the class). The return value of __new__() should be the new object instance (usually an instance of cls). Typical implementations create a new instance of the class by invoking the superclass?s __new__() method using super(currentclass, cls).__new__(cls[, ...]) with appropriate arguments and then modifying the newly-created instance as necessary before returning it. If __new__() returns an instance of cls, then the new instance?s __init__() method will be invoked like __init__(self[, ...]), where self is the new instance and the remaining arguments are the same as were passed to __new__(). If __new__() does not return an instance of cls, then the new instance?s __init__() method will not be invoked. __new__() is intended mainly to allow subclasses of immutable types (like int, str, or tuple) to customize instance creation. It is also commonly overridden in custom metaclasses in order to customize class creation. """ The problem is in this line: "If __new__() returns an instance of cls, then the new instance?s __init__() method will be invoked like __init__(self[, ...]), where self is the new instance and the remaining arguments are the same as were passed to __new__()." This is only true in the context of a constructor. In particular, directly calling cls.__new__(cls) will NOT call __init__. If I define a class: class C(object): def __new__(*args, **kwargs): print 'new', args, kwargs return object.__new__(*args,**kwargs) def __init__(self): print 'init' C() will result in __new__ and __init__ being both executed, but C.__new__(C) will only create the instance of C; it will not call __init__! The original documentation described in http://bugs.python.org/issue1123716 was more correct: "__new__ must return an object... If you return an existing object, the constructor call will still call its __init__ method unless the object is an instance of a different class..." That is __init__ is only being called in the context of an external constructor call. Proposed phrasing: "If __new__() is invoked during object construction (cls()) and it returns an instance of cls, then the new instance?s __init__() method will be invoked like __init__(self[, ...]), where self is the new instance and the remaining arguments are the same as were passed to the object constructor." ---------- assignee: docs at python components: Documentation messages: 167267 nosy: Aaron.Staley, docs at python priority: normal severity: normal status: open title: Documentation incorrectly suggests __init__ called after direct __new__ call versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 00:28:03 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 02 Aug 2012 22:28:03 +0000 Subject: [issue15540] Python 3.3 and numpy In-Reply-To: <1343941846.47.0.970447396436.issue15540@psf.upfronthosting.co.za> Message-ID: <1343946483.82.0.619793557796.issue15540@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Agreed with Martin. Byte-swapped unicode data in unicode objects doesn't make sense, since it will break the semantics of many operations. If numpy wants to support byte-swapped unicode data (what for?), they should store it in a different object type. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 00:33:40 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 02 Aug 2012 22:33:40 +0000 Subject: [issue13119] Newline for print() is \n on Windows, and not \r\n as expected In-Reply-To: <1317934788.08.0.425265217585.issue13119@psf.upfronthosting.co.za> Message-ID: <1343946820.94.0.50981484915.issue13119@psf.upfronthosting.co.za> Antoine Pitrou added the comment: About the patch: why wouldn't you use newline = NULL in both cases? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 00:59:20 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 02 Aug 2012 22:59:20 +0000 Subject: [issue15542] Documentation incorrectly suggests __init__ called after direct __new__ call In-Reply-To: <1343946223.73.0.562621858875.issue15542@psf.upfronthosting.co.za> Message-ID: <1343948360.45.0.850646391039.issue15542@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Whether or not the current language is technically correct, I would support improving its clarity. Would you like to create a formal patch? Also, note that the newest documentation is published here: http://docs.python.org/dev/reference/datamodel.html#object.__new__ (Note that in the future, you do not need to post such full excerpts, just the key parts.) ---------- nosy: +cjerdonek stage: -> needs patch type: -> enhancement versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 01:01:48 2012 From: report at bugs.python.org (Travis Oliphant) Date: Thu, 02 Aug 2012 23:01:48 +0000 Subject: [issue15540] Python 3.3 and numpy In-Reply-To: <1343946483.82.0.619793557796.issue15540@psf.upfronthosting.co.za> Message-ID: <2BF1B7E4-F115-4C3C-8011-822965DF8A98@gmail.com> Travis Oliphant added the comment: On Aug 2, 2012, at 5:28 PM, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > > Agreed with Martin. Byte-swapped unicode data in unicode objects doesn't make sense, since it will break the semantics of many operations. If numpy wants to support byte-swapped unicode data (what for?), they should store it in a different object type. This is a mis-understanding of what NumPy does and why. There is a need to byte-swap only when the data is stored on disk in the reverse order from the native machine (i.e. NumPy is pointing to memory-mapped data). The byte-swapping must be done prior to conversion to a Python Unicode-Object when selecting data out of the array. -Travis ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 01:06:10 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 02 Aug 2012 23:06:10 +0000 Subject: [issue7317] Display full tracebacks when an error occurs asynchronously In-Reply-To: <1258140215.22.0.835793798885.issue7317@psf.upfronthosting.co.za> Message-ID: <1343948770.36.0.0373962989185.issue7317@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Oops, sorry for the silence, I had forgotten about this issue. I'll take a look at the patch soon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 01:06:45 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 02 Aug 2012 23:06:45 +0000 Subject: [issue7317] Display full tracebacks when an error occurs asynchronously In-Reply-To: <1258140215.22.0.835793798885.issue7317@psf.upfronthosting.co.za> Message-ID: <1343948805.87.0.050735469057.issue7317@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Oops, sorry for the silence, I had forgotten about this issue. I'll take a look at the patch soon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 01:07:02 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 02 Aug 2012 23:07:02 +0000 Subject: [issue7317] Display full tracebacks when an error occurs asynchronously In-Reply-To: <1258140215.22.0.835793798885.issue7317@psf.upfronthosting.co.za> Message-ID: <1343948822.56.0.39411564409.issue7317@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- Removed message: http://bugs.python.org/msg167273 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 01:09:49 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 02 Aug 2012 23:09:49 +0000 Subject: [issue15540] Python 3.3 and numpy In-Reply-To: <2BF1B7E4-F115-4C3C-8011-822965DF8A98@gmail.com> Message-ID: <1343948839.3368.4.camel@localhost.localdomain> Antoine Pitrou added the comment: > The byte-swapping must be done prior to conversion to a Python > Unicode-Object when selecting data out of the array. But then it shouldn't affect the invariants which are commented out in Dave's patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 01:15:41 2012 From: report at bugs.python.org (Stefan Krah) Date: Thu, 02 Aug 2012 23:15:41 +0000 Subject: [issue15540] Python 3.3 and numpy In-Reply-To: <1343941846.47.0.970447396436.issue15540@psf.upfronthosting.co.za> Message-ID: <1343949341.62.0.680389813511.issue15540@psf.upfronthosting.co.za> Stefan Krah added the comment: > There is a need to byte-swap only when the data is stored on disk in the reverse order from the native machine (i.e. NumPy is pointing to memory-mapped data). In that case it should be a matter of disabling some NumPy unit tests. It seems that currently generating a Unicode object with non-native byte-order is being tested, hence the reported failures. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 01:23:30 2012 From: report at bugs.python.org (Stefan Krah) Date: Thu, 02 Aug 2012 23:23:30 +0000 Subject: [issue15540] Python 3.3 and numpy In-Reply-To: <1343941846.47.0.970447396436.issue15540@psf.upfronthosting.co.za> Message-ID: <1343949810.52.0.624539112268.issue15540@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: +certik _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 01:26:42 2012 From: report at bugs.python.org (Travis Oliphant) Date: Thu, 02 Aug 2012 23:26:42 +0000 Subject: [issue15540] Python 3.3 and numpy In-Reply-To: <1343948839.3368.4.camel@localhost.localdomain> Message-ID: <68DC345B-7E22-4D15-86F1-E1B2E7D8AC1A@gmail.com> Travis Oliphant added the comment: On Aug 2, 2012, at 6:09 PM, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > >> The byte-swapping must be done prior to conversion to a Python >> Unicode-Object when selecting data out of the array. > > But then it shouldn't affect the invariants which are commented out in > Dave's patch. > My impression is that Python should not have to change anything, but NumPy needs to adapt to the new Unicode concepts (which I think are great, by the way --- I'm a big supporter of getting rid of the wide/narrow build distinction). > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 01:50:00 2012 From: report at bugs.python.org (Phillip J. Eby) Date: Thu, 02 Aug 2012 23:50:00 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343951400.49.0.898410564614.issue15502@psf.upfronthosting.co.za> Phillip J. Eby added the comment: Per Nick's request that I redirect this here instead of #15295... (w/already-fixed things deleted): Hope I'm not too late to the bikeshed painting party; just wanted to chip in with the suggestion of "self-contained package" for non-namespace packages. (i.e., a self-contained package is one that cannot be split across different sys.path entries due to its use of an __init__ module). Also, technically, namespace portions do not only contribute subpackages; they can contribute modules as well. (The trunk doc says they contribute subpackages ATM.) Another point of possible confusion: meta finders and path finders are both described as "hooks", but this terminology seems in conflict with the use of "hook" as describing a callable on path_hooks. Perhaps we could drop the term "hook" from this section, and retitle it "Import System Extensions" and say you can extend the system by writing meta finders and path entry finders. This would let the term "hook" be the exclusive property of path_hooks, which is how you extend the import system to use your custom finders. With respect to the current discussion about "importer", "handler", "finder", etc., I'd like to propose a slight tweak that I think can clear up the remaining confusing points: 1. Replace "meta path finder" with "import handler" 2. Replace "path finder" with "sys.path import handler" Rationale: Despite the similarity in interface between the two types of finders, they perform different sorts of functions. A object in sys.meta_path can (and MUST) implement a broad module-finding policy, whereas a path entry finder is much more limited in scope - it only gets to override later path entry finders, and can't, for example, decide to use some other sort of __path__ attribute. (I'm not married to the term "handler" here, either - I just think "importer" is too generic, "finder" conflates with the more-commonly used kind of finder. "Policy" could be another possibility. Both imply a broader scope of responsibility than "finder", and don't impinge on the special meaning of "importer".) With a bigger distinction drawn between these two types of finders, we can say that you... """Extend the import system by adding "import handlers" to sys.meta_path, and that one of the default handlers is the "sys.path import handler", which processes imports using sys.path and module __path__ attributes. The sys.path import handler can of course in turn be extended by adding "path hooks" to sys.path_hooks, which are then used to create "module finder" objects for the path entry strings found in sys.path and module __path__ attributes. A path hook must return a finder object, which implements similar methods to those of an import handler, but with some important differences. """ Of course, if you make that "sys.path import policy" instead of "sys.path import handler", it still works. Thoughts? ---------- nosy: +pje _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 02:18:54 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 03 Aug 2012 00:18:54 +0000 Subject: [issue15540] Python 3.3 and numpy In-Reply-To: <1343941846.47.0.970447396436.issue15540@psf.upfronthosting.co.za> Message-ID: <1343953134.27.0.983729668691.issue15540@psf.upfronthosting.co.za> Nick Coghlan added the comment: While I agree this is important (e.g. I know Dave started looking into this as getting NumPy working is currently a blocker for Fedora migrating their Python 3 stack to 3.3), the burden is definitely on the NumPy side to get the code point values using the right byte order before handing them over to the CPython API. If the sanity checks in the Unicode implementation are firing, it means something is still wrong on the NumPy side (perhaps erroneous unit tests, as Stefan reports). >From the point of view of CPython, an array of byte-swapped code points isn't text, it's an array of 16 or 32 bit integers, and NumPy's text handling needs to work within that constraint. FWIW, with regard to Martin's tangential comment about appropriate use of the tracker, I'm personally fine with using the tracker for 'I found this problem, attempted to fix it (but failed), here's my attempt'. It's part of the wide spectrum of issue reporting that ranges from 'I found this problem, but have no idea what is causing it or where to even begin trying to fix it' through 'I found this problem, here's a fix that worked for me' all the way to 'I found this problem, here's a fix that works on multiple platforms with new tests, insightful doc adjustments and a pony' :) ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 02:20:34 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 03 Aug 2012 00:20:34 +0000 Subject: [issue15543] central documentation for 'universal newlines' Message-ID: <1343953234.25.0.0555174882779.issue15543@psf.upfronthosting.co.za> New submission from Chris Jerdonek: "Universal newlines" of PEP 278 does not seem to have a central, linkable description within the documentation. In particular, there does not seem to be a glossary entry or any index entries for it. The main documentation seems to be in the middle of the documentation for the open() built-in function: http://docs.python.org/dev/library/functions.html?highlight=open#open But this does not feature prominently when searching for universal newlines in the "Quick Search". This would allow us, for example, to reference and link to an explanation of universal newlines in the documentation for str.splitlines(): http://docs.python.org/dev/library/stdtypes.html#str.splitlines I would be happy to provide a patch. ---------- assignee: docs at python components: Documentation keywords: easy messages: 167279 nosy: cjerdonek, docs at python priority: normal severity: normal status: open title: central documentation for 'universal newlines' versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 02:21:53 2012 From: report at bugs.python.org (Ondrej Certik) Date: Fri, 03 Aug 2012 00:21:53 +0000 Subject: [issue15540] Python 3.3 and numpy In-Reply-To: <1343941846.47.0.970447396436.issue15540@psf.upfronthosting.co.za> Message-ID: <1343953313.37.0.330986246841.issue15540@psf.upfronthosting.co.za> Ondrej Certik added the comment: I wrote this initial patch for the issue last week: https://github.com/numpy/numpy/pull/366 with huge help from Stefan and others. As far as the unicode issue goes, Travis and I just talked about this and I think I now understand what is going on ---- the unicode type itself (as returned by the PyArray_Scalar() function in NumPy) should *never* have the byte swapped internals. In other words, the usage of the byte swapping is that if numpy happens to be pointing to a memory with byte swapped data (for example you save some data on big endian and you load it on little endian), let's say you have some strings (unicode). They will always be UCS4 inside numpy, possibly swapped. When the user actually calls things like my_array[1], then the PyArray_Scalar() looks at the memory, does any swapping (if necessary) and returns a valid unicode object on the current platform (with the correct endianness). The returned unicode can have any length (UCS1, UCS2 or UCS4 -- whatever Python likes), that doesn't really matter. So no changes are necessary to Python itself. As far as NumPy goes -- the tests are obviously wrong, because they happen to create unicode that is invalid. So the NumPy tests need to be fixed. Otherwise there is no problem. I am now working on a better version of my patch, that doesn't need to be forcing the unicode to be UCS4 so that it can swap its contents. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 03:05:24 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 03 Aug 2012 01:05:24 +0000 Subject: [issue15456] Correct __sizeof__ support for code objects In-Reply-To: <1343298555.0.0.339886098812.issue15456@psf.upfronthosting.co.za> Message-ID: <1343955924.69.0.293509708605.issue15456@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 03:47:15 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 03 Aug 2012 01:47:15 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343958435.31.0.63770813759.issue15502@psf.upfronthosting.co.za> Nick Coghlan added the comment: On the "self-contained" packages point, I was going to suggest that name, but the ability to set __path__ from __init__.py messes with it. "Regular packages" isn't great, but I'm willing to tolerate it (mainly because it was the terminology used in the approved PEP 420). The reason I still prefer "initialized" package though, is because the real difference between the two is the presence or absence of __init__.py. That means arbitrary code execution can occur as a side effect of import for initialized packages, in contrast to namespace packages which are comparatively "pure" (that is, no user provided code is executed as a side effect of importing them). +1 for renaming the current "hooks" section to "extensions" (with only the callables on path_hooks being referred to as hooks). On the topic of "import handlers" vs "meta path finders", the reason I'm happy with keeping the common suffix for "meta path finders" and "path entry finders" is that while there are substantial differences in *how* they do what they do, they are fundamentally the same in terms of *what* they do: given a module name, find a loader for it (or indicate that you can't find one). Meta path finders search more broadly than path entry finders do, but they're still doing much the same job. I've come to the conclusion that PEP 302 actually did a reasonable job with the finder vs loader vs importer classification scheme, and it's not worth trying to change that terminology too much after it's already been in the wild for 10+ years. Clarify and refine by introducing additional distinctions, yes, but change, no. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 04:41:49 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 03 Aug 2012 02:41:49 +0000 Subject: [issue15537] MULTILINE confuses re.split In-Reply-To: <1343919537.43.0.272512350755.issue15537@psf.upfronthosting.co.za> Message-ID: <1343961709.56.0.0428534322288.issue15537@psf.upfronthosting.co.za> Ezio Melotti added the comment: See also #11957. ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 04:47:48 2012 From: report at bugs.python.org (Dave Abrahams) Date: Fri, 03 Aug 2012 02:47:48 +0000 Subject: [issue15537] MULTILINE confuses re.split In-Reply-To: <1343919537.43.0.272512350755.issue15537@psf.upfronthosting.co.za> Message-ID: <1343962068.19.0.605179808837.issue15537@psf.upfronthosting.co.za> Dave Abrahams added the comment: Dang! Thanks, and sorry for wasting everyone's time on this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 04:54:03 2012 From: report at bugs.python.org (Steven D'Aprano) Date: Fri, 03 Aug 2012 02:54:03 +0000 Subject: [issue15544] math.isnan fails with some Decimal NaNs Message-ID: <1343962443.78.0.878505736017.issue15544@psf.upfronthosting.co.za> New submission from Steven D'Aprano: math.nan fails on some Decimal NANs. For example, while this works: >>> import math >>> from decimal import Decimal >>> math.isnan(Decimal('nan')) True These both fail with ValueError: math.isnan(Decimal('snan')) math.isnan(Decimal('nan123')) (Tested on Python 3.2 and 3.3.0a1) ---------- messages: 167284 nosy: stevenjd priority: normal severity: normal status: open title: math.isnan fails with some Decimal NaNs versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 04:54:34 2012 From: report at bugs.python.org (Steven D'Aprano) Date: Fri, 03 Aug 2012 02:54:34 +0000 Subject: [issue15544] math.isnan fails with some Decimal NaNs In-Reply-To: <1343962443.78.0.878505736017.issue15544@psf.upfronthosting.co.za> Message-ID: <1343962474.74.0.71870959073.issue15544@psf.upfronthosting.co.za> Changes by Steven D'Aprano : ---------- components: +Library (Lib) type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 04:58:46 2012 From: report at bugs.python.org (Meador Inge) Date: Fri, 03 Aug 2012 02:58:46 +0000 Subject: [issue15459] ctypes Structures with subclassed types in the _fields_ list In-Reply-To: <1343327705.62.0.223741820518.issue15459@psf.upfronthosting.co.za> Message-ID: <1343962726.52.0.657534288819.issue15459@psf.upfronthosting.co.za> Meador Inge added the comment: OK, I finally had some time to look at this. The attached patch does fix the issue. However, it has a nasty side effect in that the encoded bitfield size stays with the field member object: >>> class SubByte(c_ubyte): pass ... >>> class A(Structure): ... _fields_ = [("x", SubByte, 5)] ... >>> sizeof(A().x) 327680 Before the patch things look like: >>> class SubByte(c_ubyte): pass ... >>> class A(Structure): ... _fields_ = [("x", SubByte, 5)] ... >>> sizeof(A().x) 1 Leaking the internal bitfield size encoding seems like a deal breaker to me. ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 05:24:46 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 03 Aug 2012 03:24:46 +0000 Subject: [issue15544] math.isnan fails with some Decimal NaNs In-Reply-To: <1343962443.78.0.878505736017.issue15544@psf.upfronthosting.co.za> Message-ID: <1343964286.54.0.465533154894.issue15544@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +mark.dickinson, skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 05:59:07 2012 From: report at bugs.python.org (Eric Snow) Date: Fri, 03 Aug 2012 03:59:07 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343966347.39.0.55304371659.issue15502@psf.upfronthosting.co.za> Eric Snow added the comment: The more I think about it the more I think there needs to be a harder separation between the import system proper and the path-based subsystem. I hadn't really thought of it this way until the discussion of the last few days, but it has really clicked in my mind. The new "import system" in the language reference already does a pretty good job of this. I'll try to get a patch up in the next few days that shows what I mean. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 06:06:20 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Aug 2012 04:06:20 +0000 Subject: [issue15311] Dev Guide update procedure documentation in dev guide outdated In-Reply-To: <1341880820.83.0.419912780964.issue15311@psf.upfronthosting.co.za> Message-ID: <3WpF6x4XVqzPhf@mail.python.org> Roundup Robot added the comment: New changeset 864cd63db2bb by Ned Deily in branch 'default': Closes #15311 - update devguide publication info. http://hg.python.org/devguide/rev/864cd63db2bb ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 06:44:29 2012 From: report at bugs.python.org (Atsuo Ishimoto) Date: Fri, 03 Aug 2012 04:44:29 +0000 Subject: [issue13119] Newline for print() is \n on Windows, and not \r\n as expected In-Reply-To: <1317934788.08.0.425265217585.issue13119@psf.upfronthosting.co.za> Message-ID: <1343969069.44.0.139552793625.issue13119@psf.upfronthosting.co.za> Atsuo Ishimoto added the comment: On Fri, Aug 3, 2012 at 5:16 AM, STINNER Victor wrote: >> I wonder why "print(1, file=sys.stderr)" returns '1' instead of '1\n'. > > I suppose that you mean "returns '1\n' instead of '1'". No, sorry for my lame wording. In the test I submitted, printing to stdout with "print(1, file=sys.stdout);print(2, file=sys.stdout)" outputs "1\r\n2\r\n" but printing to stderr with "print(1, file=sys.stderr);print(2, file=sys.stderr)" outputs "1\r\n2" <- no '\r\n' at the end I wondered why, but this is not specific to Python 3. With Python 2.7 print >>sys.stderr, 1 doesn't output '\r\n' at the end also. So I think this may not be a bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 06:49:08 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 03 Aug 2012 04:49:08 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343969348.55.0.238371432463.issue15502@psf.upfronthosting.co.za> Nick Coghlan added the comment: See my comment above about explicitly defining the "path import subsystem" and renaming the "path importer" to be the "path import finder". I think the subsystem is well worth calling out explicitly, as when most people think of Python's import system, they're far more likely to be thinking about sys.path and filesystem imports in general than they are the meta path machinery. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 07:40:23 2012 From: report at bugs.python.org (Georg Brandl) Date: Fri, 03 Aug 2012 05:40:23 +0000 Subject: [issue14330] don't use host python, use host search paths for host compiler In-Reply-To: <1331856850.28.0.590122825265.issue14330@psf.upfronthosting.co.za> Message-ID: <1343972423.68.0.52783868795.issue14330@psf.upfronthosting.co.za> Georg Brandl added the comment: Matthias, any comments? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 08:19:24 2012 From: report at bugs.python.org (Eric Snow) Date: Fri, 03 Aug 2012 06:19:24 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1343974764.65.0.943708901549.issue15502@psf.upfronthosting.co.za> Eric Snow added the comment: This patch implements most of Brett's recommendation. I've held off on actually deprecating Finder just yet. However, it would probably entail a message in the docs like this: The API signatures for meta path finders and path entry finders were separated by PEP 420. This class is still available for compatibility with legacy third party reimplementations of the import system. Either :class:`MetaPathFinder` or :class:`PathEntryFinder` should be used instead. ---------- Added file: http://bugs.python.org/file26671/issue15502_invalidate_caches.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 08:35:24 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 03 Aug 2012 06:35:24 +0000 Subject: [issue15540] Python 3.3 and numpy In-Reply-To: <2BF1B7E4-F115-4C3C-8011-822965DF8A98@gmail.com> Message-ID: <20120803083522.Horde.FdzmXqGZi1VQG3EqdU-WNkA@webmail.df.eu> Martin v. L?wis added the comment: > This is a mis-understanding of what NumPy does and why. There is > a need to byte-swap only when the data is stored on disk in the > reverse order from the native machine So is there ever a need to byte-swap Unicode strings? I can see how *numeric* data are stored using the internal representation on disk; this is a common technique. For strings, there is the notion of encodings which makes the relationship between internal and disk representations. So if NumPy applies the numeric concept to string data, then this is a flaw. It may be that people really do store text data in the same memory blob as numeric data and dump it to a file, but they really should think of this data as "UTF-16-BE" or "UTF-32-LE" and the like, not in terms of byte swapping. You can use PyUnicode_Decode to create a Unicode object given a void*, a length, and a codec name. The concept "native Unicode representation" does not exist - people use all of two-byte, four-byte and UTF-8 representations in memory, on a single processor architecture and operating system. > The byte-swapping must be done prior to conversion to a Python > Unicode-Object when selecting data out of the array. So if the byte swapping is done before the Unicode object is created: why did Dave and Ond?ej run into problems then? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 09:06:16 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 03 Aug 2012 07:06:16 +0000 Subject: [issue15544] math.isnan fails with some Decimal NaNs In-Reply-To: <1343962443.78.0.878505736017.issue15544@psf.upfronthosting.co.za> Message-ID: <1343977576.73.0.142770280543.issue15544@psf.upfronthosting.co.za> Mark Dickinson added the comment: Yep, Decimal.__float__ isn't too sophisticated. Probably it should convert all Decimal quiet NaNs (at least) to float NaNs, keeping the sign if possible but discarding any payload. Not so sure about signaling NaNs, though; I think it would be fine for those to continue to raise ValueError (on the basis that doing pretty much anything with a signaling NaN should give an exception). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 09:42:08 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Aug 2012 07:42:08 +0000 Subject: [issue15543] central documentation for 'universal newlines' In-Reply-To: <1343953234.25.0.0555174882779.issue15543@psf.upfronthosting.co.za> Message-ID: <1343979728.93.0.0876903194492.issue15543@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See issue15204. ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 09:59:59 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Fri, 03 Aug 2012 07:59:59 +0000 Subject: [issue13992] Segfault in PyTrash_destroy_chain In-Reply-To: <1343822016.51.0.322231663782.issue13992@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > (gdb) p op > $12 = (PyObject *) 0x4dc7bc0 Don't you have GDB 7, to decode Python objects ? You can check the type of the object with : """ p op->ob_type.tp_name """ > > thread all apply bt is going to be very long no ? Could you tell me what you want to know that is not in info threads maybe ? I can definitely post it here, but it's going to be a lot of output. You can add it as an attachment. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 10:07:56 2012 From: report at bugs.python.org (Pierre Le Marre) Date: Fri, 03 Aug 2012 08:07:56 +0000 Subject: [issue15545] sqlite3.Connection.iterdump() does not work with row_factory = sqlite3.Row Message-ID: <1343981276.31.0.0397998065256.issue15545@psf.upfronthosting.co.za> Changes by Pierre Le Marre : ---------- components: None nosy: plemarre priority: normal severity: normal status: open title: sqlite3.Connection.iterdump() does not work with row_factory = sqlite3.Row type: crash versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 10:09:32 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 03 Aug 2012 08:09:32 +0000 Subject: [issue15545] sqlite3.Connection.iterdump() does not work with row_factory = sqlite3.Row Message-ID: <1343981372.87.0.323193257201.issue15545@psf.upfronthosting.co.za> New submission from Martin v. L?wis: Can you please elaborate? Structure your report as follows: 1. this is what I did 2. this is what happened 3. this is what should have happened instead. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 10:24:06 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 03 Aug 2012 08:24:06 +0000 Subject: [issue15204] Deprecate the 'U' open mode In-Reply-To: <1340792991.22.0.497199331706.issue15204@psf.upfronthosting.co.za> Message-ID: <1343982246.65.0.654285421536.issue15204@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 10:27:02 2012 From: report at bugs.python.org (Pierre Le Marre) Date: Fri, 03 Aug 2012 08:27:02 +0000 Subject: [issue15545] sqlite3.Connection.iterdump() does not work with row_factory = sqlite3.Row In-Reply-To: <1343981372.87.0.323193257201.issue15545@psf.upfronthosting.co.za> Message-ID: <1343982422.69.0.920992443085.issue15545@psf.upfronthosting.co.za> Pierre Le Marre added the comment: I use Python 3.2.3 on GNU/Linux 64bits (openSUSE 12.2). I have created an in-memory connection with the following code: conn = sqlite3.connect(":memory:", detect_types=sqlite3.PARSE_DECLTYPES, check_same_thread=False) conn.row_factory = sqlite3.Row Then I have filled the database, but when it comes to copy it via conn.iterdump(), it crashed with the following message: File "/usr/lib64/python3.2/sqlite3/dump.py", line 30, in _iterdump for table_name, type, sql in sorted(schema_res.fetchall()): TypeError: unorderable types: sqlite3.Row() < sqlite3.Row() It seems that the error appears because of the use of "sorted()". In fact, if I don't change conn.row_factory or if I use a custom class _Row implementing __lt__ method (see below) this error does not appear. class _Row(sqlite3.Row): def __lt__(self, x): return False ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 10:33:25 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 03 Aug 2012 08:33:25 +0000 Subject: [issue15543] central documentation for 'universal newlines' In-Reply-To: <1343953234.25.0.0555174882779.issue15543@psf.upfronthosting.co.za> Message-ID: <1343982805.17.0.873875622357.issue15543@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Since universal newline mode is discouraged and getting deprecated in the built-in open() function, the "central" place for describing universal newlines should probably not be the documentation for the open() method. I am leaning towards a glossary entry. The io.TextIOWrapper class is another candidate: http://docs.python.org/dev/library/io.html#io.TextIOWrapper ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 11:04:34 2012 From: report at bugs.python.org (David Beazley) Date: Fri, 03 Aug 2012 09:04:34 +0000 Subject: [issue15546] Iteration breaks with bz2.open(filename,'rt') Message-ID: <1343984674.35.0.733492369263.issue15546@psf.upfronthosting.co.za> New submission from David Beazley: The bz2 library in Python3.3b1 doesn't support iteration for text-mode properly. Example: >>> f = bz2.open('access-log-0108.bz2') >>> next(f) # Works b'140.180.132.213 - - [24/Feb/2008:00:08:59 -0600] "GET /ply/ply.html HTTP/1.1" 200 97238\n' >>> g = bz2.open('access-log-0108.bz2','rt') >>> next(g) # Fails Traceback (most recent call last): File "", line 1, in StopIteration >>> ---------- components: Library (Lib) messages: 167299 nosy: dabeaz priority: normal severity: normal status: open title: Iteration breaks with bz2.open(filename,'rt') type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 11:06:13 2012 From: report at bugs.python.org (Steven D'Aprano) Date: Fri, 03 Aug 2012 09:06:13 +0000 Subject: [issue15544] math.isnan fails with some Decimal NaNs In-Reply-To: <1343962443.78.0.878505736017.issue15544@psf.upfronthosting.co.za> Message-ID: <1343984773.98.0.439753263454.issue15544@psf.upfronthosting.co.za> Steven D'Aprano added the comment: Attached is a patch for decimal.py, and test_decimal.py. I cannot provide a patch for the C decimal implementation, sorry. Following Mark's suggestion, my patch keeps the sign but discards the payload for quiet NANs, and raises ValueError for signalling NANs. (I'm ambivalent about signalling NANs raising ValueError, but I guess that's better than having snan silently converted to a quiet nan.) ---------- keywords: +patch Added file: http://bugs.python.org/file26672/decimalnan.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 11:18:10 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 03 Aug 2012 09:18:10 +0000 Subject: [issue15540] Python 3.3 and numpy In-Reply-To: <1343953134.27.0.983729668691.issue15540@psf.upfronthosting.co.za> Message-ID: <20120803111807.Horde.IHjPH6GZi1VQG5dPtLawPpA@webmail.df.eu> Martin v. L?wis added the comment: > FWIW, with regard to Martin's tangential comment about appropriate > use of the tracker, I'm personally fine with using the tracker for > 'I found this problem, attempted to fix it (but failed), here's my > attempt'. I don't mind that at all, either. What I dislike is "I have this issue, here is what I've got, and I will continue to work on it" kind of reports (when Dave clearly said that his patch is work-in-progress). There is a worse kind, where people say "I have this issue", followed (after 15 minutes) with "I found out more", and then going on with that for a while. I feel that this wastes the reader's time (who may actually start to work on the issue as well, duplicating efforts) - this is something that submitters really need to consider. It's not this bad in this issue, since Dave said from the beginning that it is work-in-progress. On-topic: what action do you suggest for this issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 11:24:42 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 03 Aug 2012 09:24:42 +0000 Subject: [issue15544] math.isnan fails with some Decimal NaNs In-Reply-To: <1343962443.78.0.878505736017.issue15544@psf.upfronthosting.co.za> Message-ID: <1343985882.68.0.00781588175816.issue15544@psf.upfronthosting.co.za> Stefan Krah added the comment: I think math.isnan('snan') probably should not raise. Decimal('snan').is_nan() just returns true and I am under the impression that IEEE 754 specifies the same. I have to admit though that I just consulted Wikipedia for the latter: "The predicate isNaN(x) determines if a value is a NaN and never signals an exception, even if x is a signaling NaN." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 11:51:55 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 03 Aug 2012 09:51:55 +0000 Subject: [issue15540] Python 3.3 and numpy In-Reply-To: <20120803111807.Horde.IHjPH6GZi1VQG5dPtLawPpA@webmail.df.eu> Message-ID: <20120803095155.GA2617@sleipnir.bytereef.org> Stefan Krah added the comment: Martin v. L??wis wrote: > I don't mind that at all, either. What I dislike is "I have this issue, > here is what I've got, and I will continue to work on it" kind of reports > (when Dave clearly said that his patch is work-in-progress). There is a > worse kind, where people say "I have this issue", followed (after 15 minutes) > with "I found out more", and then going on with that for a while. I feel > that this wastes the reader's time (who may actually start to work on the > issue as well, duplicating efforts) - this is something that submitters > really need to consider. It's not this bad in this issue, since Dave said > from the beginning that it is work-in-progress. I think Dave's main issue was: Here's a problem with NumPy/3.3, could we perhaps remove an assert() to keep NumPy working. That was the one-liner patch. The NumPy patches were probably there for illustration. -- It might be unusual to post patches for third party packages on the tracker, but NumPy is in a very special situation right now: Version 1.7 is about to be released and is currently not 3.3 compatible. As Nick said, NumPy is a blocker for Python-3.3 integration into Fedora. So, I hope that Travis doesn't mind if people keep pushing the issue a bit. On the positive side, it's a sign that people care a lot about NumPy. > On-topic: what action do you suggest for this issue? As for the action, I think everyone agrees that no changes to Python are necessary. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 12:37:17 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 03 Aug 2012 10:37:17 +0000 Subject: [issue15546] Iteration breaks with bz2.open(filename,'rt') In-Reply-To: <1343984674.35.0.733492369263.issue15546@psf.upfronthosting.co.za> Message-ID: <1343990237.57.0.169021842224.issue15546@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +nadeem.vawda _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 12:48:28 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 03 Aug 2012 10:48:28 +0000 Subject: [issue15530] Enhance Py_MIN and Py_MAX In-Reply-To: <1343845195.3.0.786704958428.issue15530@psf.upfronthosting.co.za> Message-ID: <1343990908.41.0.169497781.issue15530@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I don't understand the point of your patch. Can you explain? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 13:29:17 2012 From: report at bugs.python.org (Nadeem Vawda) Date: Fri, 03 Aug 2012 11:29:17 +0000 Subject: [issue15546] Iteration breaks with bz2.open(filename,'rt') In-Reply-To: <1343984674.35.0.733492369263.issue15546@psf.upfronthosting.co.za> Message-ID: <1343993357.92.0.324926780749.issue15546@psf.upfronthosting.co.za> Nadeem Vawda added the comment: I can't seem to reproduce this with an up-to-date checkout from Mercurial: >>> import bz2 >>> g = bz2.open('access-log-0108.bz2','rt') >>> next(g) '140.180.132.213 - - [24/Feb/2008:00:08:59 -0600] "GET /ply/ply.html HTTP/1.1" 200 97238\n' (where 'access-log-0108.bz2' is a file I created with the output above as its first line, and a couple of other lines of random junk following that) Would it be possible for you to upload the file you used to trigger this bug? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 13:35:07 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 03 Aug 2012 11:35:07 +0000 Subject: [issue15530] Enhance Py_MIN and Py_MAX In-Reply-To: <1343845195.3.0.786704958428.issue15530@psf.upfronthosting.co.za> Message-ID: <1343993707.56.0.111102443558.issue15530@psf.upfronthosting.co.za> STINNER Victor added the comment: > I don't understand the point of your patch. Can you explain? Yes. It's explained in the comment of the two macros: "When compiled with GCC, check also that types of x and y are compatible at compile time." So it adds a cheap santity check at compile time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 13:37:23 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 03 Aug 2012 11:37:23 +0000 Subject: [issue15530] Enhance Py_MIN and Py_MAX In-Reply-To: <1343993707.56.0.111102443558.issue15530@psf.upfronthosting.co.za> Message-ID: <1343993691.3377.1.camel@localhost.localdomain> Antoine Pitrou added the comment: > Yes. It's explained in the comment of the two macros: > > "When compiled with GCC, check also that types of x and y are > compatible at compile time." I'm sorry, that doesn't explain anything. The C compiler already checks types for you. So what does it bring? And if it brings anything, why should it be restricted to Py_MIN and Py_MAX? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 13:52:10 2012 From: report at bugs.python.org (David Beazley) Date: Fri, 03 Aug 2012 11:52:10 +0000 Subject: [issue15546] Iteration breaks with bz2.open(filename,'rt') In-Reply-To: <1343984674.35.0.733492369263.issue15546@psf.upfronthosting.co.za> Message-ID: <1343994730.7.0.637317915507.issue15546@psf.upfronthosting.co.za> David Beazley added the comment: File attached. The file can be read in its entirety in binary mode. ---------- Added file: http://bugs.python.org/file26673/access-log-0108.bz2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 14:06:45 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 03 Aug 2012 12:06:45 +0000 Subject: [issue15544] math.isnan fails with some Decimal NaNs In-Reply-To: <1343962443.78.0.878505736017.issue15544@psf.upfronthosting.co.za> Message-ID: <1343995605.27.0.275832929857.issue15544@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Decimal('snan').is_nan() > just returns true and I am under the impression that IEEE 754 specifies > the same. Sure, but IEEE 754 also specifies that math.sqrt() should signal. Since both math.sqrt and math.isnan are going through __float__, we can't keep everyone happy here. The question for me is really what __float__ should do. IEEE 754 doesn't help here, since it doesn't cover decimal floating-point <-> binary floating-point conversions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 14:07:11 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 03 Aug 2012 12:07:11 +0000 Subject: [issue15525] test_multiprocessing failure on Windows XP In-Reply-To: <1343827060.29.0.756371915694.issue15525@psf.upfronthosting.co.za> Message-ID: <1343995631.65.0.656706074741.issue15525@psf.upfronthosting.co.za> Richard Oudkerk added the comment: Looks like it is fixed. ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 14:13:04 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 03 Aug 2012 12:13:04 +0000 Subject: [issue15547] Why do we have os.truncate() and os.ftruncate() whereas os.truncate() accepts a file descriptor? Message-ID: <1343995984.36.0.909130129312.issue15547@psf.upfronthosting.co.za> New submission from STINNER Victor: posix_truncate() accepts a file descriptor, so os.ftruncate() can be removed from Python 3.3. memset(&path, 0, sizeof(path)); path.function_name = "truncate"; #ifdef HAVE_FTRUNCATE path.allow_fd = 1; #endif if (!PyArg_ParseTupleAndKeywords(args, kwargs, "O&O&:truncate", keywords, path_converter, &path, _parse_off_t, &length)) return NULL; ---------- messages: 167311 nosy: haypo, larry priority: deferred blocker severity: normal status: open title: Why do we have os.truncate() and os.ftruncate() whereas os.truncate() accepts a file descriptor? versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 14:15:20 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 03 Aug 2012 12:15:20 +0000 Subject: [issue15530] Enhance Py_MIN and Py_MAX In-Reply-To: <1343845195.3.0.786704958428.issue15530@psf.upfronthosting.co.za> Message-ID: <1343996120.86.0.149995813205.issue15530@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Victor hinted that it would detect errors when combining int and unsigned int. To elaborate, see the attached min.c. It gives [traditional MIN definition] [int, pointer] min.c:18: warning: comparison between pointer and integer min.c:18: warning: pointer/integer type mismatch in conditional expression [static assert] [int, unsigned int] min.c:20: error: size of array ?type name? is negative [int, double] min.c:21: error: size of array ?type name? is negative [int, pointer] min.c:22: error: size of array ?type name? is negative min.c:22: warning: comparison between pointer and integer min.c:22: warning: pointer/integer type mismatch in conditional expression So compared to the traditional type checks: a) this gives a hard compile error, whereas the existing check would only produce warnings b) the existing min happily combines (int,unsigned) giving unsigned and (int, double) giving double; the new code will will reject such code. I think the feature is somewhat desirable; I agree code combining different types in MIN or MAX is flawed - if it is intentional, asking for an explicit cast is not asking too much. The only downside of the patch is that it uses a language extension. We should strive to reduce usage of language extensions, not increase it. I also have a personal dislike of fanciness in code. Code should be clean, not cute. ---------- Added file: http://bugs.python.org/file26674/min.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 14:16:42 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 03 Aug 2012 12:16:42 +0000 Subject: [issue15514] Correct __sizeof__ support for cpu_set In-Reply-To: <1343724004.49.0.263322089559.issue15514@psf.upfronthosting.co.za> Message-ID: <1343996202.53.0.868622097838.issue15514@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 14:18:24 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Aug 2012 12:18:24 +0000 Subject: [issue15514] Correct __sizeof__ support for cpu_set In-Reply-To: <1343724004.49.0.263322089559.issue15514@psf.upfronthosting.co.za> Message-ID: <3WpS2k3JS6zPk6@mail.python.org> Roundup Robot added the comment: New changeset 463d3ad22cdb by Jesus Cea in branch 'default': Closes #15514: Correct __sizeof__ support for cpu_set http://hg.python.org/cpython/rev/463d3ad22cdb ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 14:19:59 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 03 Aug 2012 12:19:59 +0000 Subject: [issue15478] UnicodeDecodeError on OSError on Windows with undecodable (bytes) filename In-Reply-To: <1343479745.83.0.410557070565.issue15478@psf.upfronthosting.co.za> Message-ID: <1343996399.2.0.254667747311.issue15478@psf.upfronthosting.co.za> STINNER Victor added the comment: Attached patch modifies all functions of the os module taking filenames to keep the filename unmodified in OSError.filename. The patch changes also os.link(), os.rename() and os.replace() to use the source, not the destination, in the error message. It is maybe a mistake because these functions can also fail in the directory of the destination does not exist. ---------- keywords: +patch Added file: http://bugs.python.org/file26675/oserror_filename.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 14:20:10 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 03 Aug 2012 12:20:10 +0000 Subject: [issue15512] Correct __sizeof__ support for parser In-Reply-To: <1343723513.03.0.835632561476.issue15512@psf.upfronthosting.co.za> Message-ID: <1343996410.89.0.0647412550514.issue15512@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 14:26:00 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 03 Aug 2012 12:26:00 +0000 Subject: [issue15548] Mention all new os functions in What's New in Python 3.3 Message-ID: <1343996760.47.0.232563077305.issue15548@psf.upfronthosting.co.za> New submission from STINNER Victor: The os module has a lot of new functions in Python 3.3. It looks like only a few are documented in What's New in Python 3.3. Examples : truncate(), ftruncate() and sync() are not mentionned. Does Sphinx have a function to list of new functions added to Python 3.3? At least to check that the What's New in Python 3.3 is complete. I would like to have the full list to check that new functions are consistent. See for example the issue #15547. ---------- assignee: docs at python components: Documentation messages: 167315 nosy: docs at python, georg.brandl, haypo, larry, rhettinger priority: normal severity: normal status: open title: Mention all new os functions in What's New in Python 3.3 versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 14:26:11 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 03 Aug 2012 12:26:11 +0000 Subject: [issue15547] Why do we have os.truncate() and os.ftruncate() whereas os.truncate() accepts a file descriptor? In-Reply-To: <1343995984.36.0.909130129312.issue15547@psf.upfronthosting.co.za> Message-ID: <1343996771.18.0.275066562548.issue15547@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 14:26:33 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 03 Aug 2012 12:26:33 +0000 Subject: [issue15544] math.isnan fails with some Decimal NaNs In-Reply-To: <1343962443.78.0.878505736017.issue15544@psf.upfronthosting.co.za> Message-ID: <1343996793.31.0.751630257687.issue15544@psf.upfronthosting.co.za> Mark Dickinson added the comment: > IEEE 754 doesn't help here, since it doesn't cover decimal > floating-point <-> binary floating-point conversions. OTOH, IEEE 754 *does* cover floating-point to int conversions (5.4.1, 5.8): those fall under 'general-computational operations', and as such should signal when given an sNaN (6.2: "Signaling NaNs shall be reserved operands that, under default exception handling, signal the invalid operation exception (see 7.2) for every general-computational and signaling-computational operation except for the conversions described in 5.12. For non-default treatment, see 8."). It feels to me as though decimal -> binary conversions should follow the same pattern. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 14:27:08 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 03 Aug 2012 12:27:08 +0000 Subject: [issue15547] Why do we have os.truncate() and os.ftruncate() whereas os.truncate() accepts a file descriptor? In-Reply-To: <1343995984.36.0.909130129312.issue15547@psf.upfronthosting.co.za> Message-ID: <1343996828.65.0.148496596686.issue15547@psf.upfronthosting.co.za> STINNER Victor added the comment: To check if os.truncate() supports file description, "os.truncate in os.supports_fd" checek can be used. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 14:29:48 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Aug 2012 12:29:48 +0000 Subject: [issue15512] Correct __sizeof__ support for parser In-Reply-To: <1343723513.03.0.835632561476.issue15512@psf.upfronthosting.co.za> Message-ID: <3WpSHv3C49zPWr@mail.python.org> Roundup Robot added the comment: New changeset aceb975c4832 by Jesus Cea in branch '2.7': Closes #15512: Correct __sizeof__ support for parser http://hg.python.org/cpython/rev/aceb975c4832 New changeset 91884d04de06 by Jesus Cea in branch '3.2': Closes #15512: Correct __sizeof__ support for parser http://hg.python.org/cpython/rev/91884d04de06 New changeset f7248550059c by Jesus Cea in branch 'default': MERGE: Closes #15512: Correct __sizeof__ support for parser http://hg.python.org/cpython/rev/f7248550059c ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 14:35:29 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 03 Aug 2012 12:35:29 +0000 Subject: [issue15530] Enhance Py_MIN and Py_MAX In-Reply-To: <1343996120.86.0.149995813205.issue15530@psf.upfronthosting.co.za> Message-ID: <1343997178.3377.4.camel@localhost.localdomain> Antoine Pitrou added the comment: Le vendredi 03 ao?t 2012 ? 12:15 +0000, Martin v. L?wis a ?crit : > So compared to the traditional type checks: > a) this gives a hard compile error, whereas the existing check would > only produce warnings Warnings are quite visible already, and we try to silence them. > I think the feature is somewhat desirable; I agree code combining > different types in MIN or MAX is flawed - if it is intentional, asking > for an explicit cast is not asking too much. I don't agree. Trying to battle with C's semantics doesn't seem very productive, especially if it's only done in a single pair of macros. If we think that implicit type conversions are too laxist, we should probably use a different set of compiler options. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 14:52:41 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Aug 2012 12:52:41 +0000 Subject: [issue15469] Correct __sizeof__ support for deque In-Reply-To: <1343404078.66.0.00721941905437.issue15469@psf.upfronthosting.co.za> Message-ID: <3WpSpG6wnSzPch@mail.python.org> Roundup Robot added the comment: New changeset a3d49f1de893 by Jesus Cea in branch '2.7': Closes #15469: Correct __sizeof__ support for deque http://hg.python.org/cpython/rev/a3d49f1de893 New changeset b0725c1b3068 by Jesus Cea in branch '3.2': Closes #15469: Correct __sizeof__ support for deque http://hg.python.org/cpython/rev/b0725c1b3068 New changeset b80a780514dd by Jesus Cea in branch 'default': MERGE: Closes #15469: Correct __sizeof__ support for deque http://hg.python.org/cpython/rev/b80a780514dd ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 14:57:22 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 03 Aug 2012 12:57:22 +0000 Subject: [issue15512] Correct __sizeof__ support for parser In-Reply-To: <1343723513.03.0.835632561476.issue15512@psf.upfronthosting.co.za> Message-ID: <1343998642.46.0.205688840811.issue15512@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Compilation of 2.7 under Windows is broken: http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%202.7/builds/75 ---------- assignee: -> jcea nosy: +pitrou status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 14:59:07 2012 From: report at bugs.python.org (Ross Lagerwall) Date: Fri, 03 Aug 2012 12:59:07 +0000 Subject: [issue15548] Mention all new os functions in What's New in Python 3.3 In-Reply-To: <1343996760.47.0.232563077305.issue15548@psf.upfronthosting.co.za> Message-ID: <1343998747.06.0.260619070622.issue15548@psf.upfronthosting.co.za> Ross Lagerwall added the comment: Attached is a diff between dir(os) in 3.2 and 3.3 ---------- keywords: +patch nosy: +rosslagerwall Added file: http://bugs.python.org/file26676/oschanges.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 15:03:37 2012 From: report at bugs.python.org (Steven D'Aprano) Date: Fri, 03 Aug 2012 13:03:37 +0000 Subject: [issue15544] math.isnan fails with some Decimal NaNs In-Reply-To: <1343995605.27.0.275832929857.issue15544@psf.upfronthosting.co.za> Message-ID: <501BCC1F.2050007@pearwood.info> Steven D'Aprano added the comment: On 03/08/12 22:06, Mark Dickinson wrote: > >> Decimal('snan').is_nan() just returns true and I am under the impression >> that IEEE 754 specifies the same. > > Sure, but IEEE 754 also specifies that math.sqrt() should > signal. Since both math.sqrt and math.isnan are going through __float__, > we can't keep everyone happy here. Is it necessarily a given that math.isnan *must* go through __float__? If it were written in Python, it would be a simple matter of including if isinstance(x, Decimal) and x.isnan(): return True before the conversion to float. By I have no idea whether that is practical in the math module. > The question for me is really what __float__ should do. IEEE 754 doesn't > help here, since it doesn't cover decimal floating-point<-> binary > floating-point conversions. Until such time that floats officially support snans, I think ValueError is the right behaviour. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 15:08:48 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Aug 2012 13:08:48 +0000 Subject: [issue15512] Correct __sizeof__ support for parser In-Reply-To: <1343723513.03.0.835632561476.issue15512@psf.upfronthosting.co.za> Message-ID: <1343999328.14.0.830027697974.issue15512@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Oops, I forgot to remove the remnants of debugging code. Here's the patch. Sorry. ---------- Added file: http://bugs.python.org/file26677/parser_sizeof_cleanup.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 15:12:28 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 03 Aug 2012 13:12:28 +0000 Subject: [issue15473] importlib no longer uses imp.NullImporter In-Reply-To: <1343414217.14.0.255366402583.issue15473@psf.upfronthosting.co.za> Message-ID: <1343999548.03.0.762484916691.issue15473@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 15:29:52 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Aug 2012 13:29:52 +0000 Subject: [issue15512] Correct __sizeof__ support for parser In-Reply-To: <1343723513.03.0.835632561476.issue15512@psf.upfronthosting.co.za> Message-ID: <1344000592.54.0.542271572306.issue15512@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Compilation of 2.7 under Windows is broken: Here is a patch for declarations reorganizing. ---------- Added file: http://bugs.python.org/file26678/parser_methods_declaration_move-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 15:33:34 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 03 Aug 2012 13:33:34 +0000 Subject: [issue15544] math.isnan fails with some Decimal NaNs In-Reply-To: <1343962443.78.0.878505736017.issue15544@psf.upfronthosting.co.za> Message-ID: <1344000814.35.0.218453626805.issue15544@psf.upfronthosting.co.za> Mark Dickinson added the comment: > before the conversion to float. By I have no idea whether that is > practical in the math module. That's a much bigger discussion: as it is, most of the math module functions just provide simple wrappers around the system math library, which deals purely with floats. *Some* of the math module functions have been made more generic, like floor and ceil (which look for special __floor__ and __ceil__ methods), but isnan isn't one of those: like most of the math module functions, it simply converts whatever it's given to float, then passes it on to the system library and returns whatever it gets back. Changing that would be feature request targeted at 3.4 or later; I'm not saying that it shouldn't be considered, but it doesn't belong in this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 15:41:12 2012 From: report at bugs.python.org (=?utf-8?b?T25kxZllaiDEjGVydMOtaw==?=) Date: Fri, 03 Aug 2012 13:41:12 +0000 Subject: [issue15540] Python 3.3 and numpy In-Reply-To: <1343941846.47.0.970447396436.issue15540@psf.upfronthosting.co.za> Message-ID: <1344001272.06.0.672628157891.issue15540@psf.upfronthosting.co.za> Ond?ej ?ert?k added the comment: Martin, > So if the byte swapping is done before the Unicode object is created: > why did Dave and Ond?ej run into problems then? As I wrote above (http://bugs.python.org/msg167280), this happened because of wrong NumPy tests, that need to be fixed. They are testing some byte swapping issues and they do produce an invalid unicode in the process --- this is a bug and we need to fix it in NumPy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 15:51:36 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Aug 2012 13:51:36 +0000 Subject: [issue15512] Correct __sizeof__ support for parser In-Reply-To: <1343723513.03.0.835632561476.issue15512@psf.upfronthosting.co.za> Message-ID: <3WpV6F4tPzzPk7@mail.python.org> Roundup Robot added the comment: New changeset 0827fef8652d by Jesus Cea in branch '2.7': #15512: Remove remnants of debugging code http://hg.python.org/cpython/rev/0827fef8652d New changeset 0bda3f00b60a by Jesus Cea in branch '3.2': #15512: Remove remnants of debugging code http://hg.python.org/cpython/rev/0bda3f00b60a New changeset 593eba5e867c by Jesus Cea in branch 'default': MERGE: #15512: Remove remnants of debugging code http://hg.python.org/cpython/rev/593eba5e867c New changeset c5bf5a82a3f2 by Jesus Cea in branch '2.7': #15512: Declarations reorganization http://hg.python.org/cpython/rev/c5bf5a82a3f2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 15:56:41 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Aug 2012 13:56:41 +0000 Subject: [issue15513] Correct __sizeof__ support for pickle In-Reply-To: <1343723739.69.0.648602242607.issue15513@psf.upfronthosting.co.za> Message-ID: <1344002201.11.0.689196934446.issue15513@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In any case do not commit the patch for the time being. Probably it should be improved to include the size of the internal Python objects (see discussion in issue15490). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 16:10:57 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Aug 2012 14:10:57 +0000 Subject: [issue6471] errno and strerror attributes incorrectly set on socket errors wrapped by urllib In-Reply-To: <1247432074.99.0.825435411389.issue6471@psf.upfronthosting.co.za> Message-ID: <1344003057.42.0.879857766927.issue6471@psf.upfronthosting.co.za> R. David Murray added the comment: This is an interesting idea and should at least improve matters. I'm wondering, though...I seem to remember writing code that fished the wrapped error out using one of those attributrs...but I'm not at a computer where I can try to check on that. Hopefully I can check on it this weekend. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 16:26:47 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 03 Aug 2012 14:26:47 +0000 Subject: [issue15544] math.isnan fails with some Decimal NaNs In-Reply-To: <1343962443.78.0.878505736017.issue15544@psf.upfronthosting.co.za> Message-ID: <1344004007.42.0.0332245405287.issue15544@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Why not add a is_nan() method to float numbers instead? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 16:27:01 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Aug 2012 14:27:01 +0000 Subject: [issue15512] Correct __sizeof__ support for parser In-Reply-To: <1343723513.03.0.835632561476.issue15512@psf.upfronthosting.co.za> Message-ID: <1344004021.47.0.846523799278.issue15512@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Compilation of 2.7 under Windows is successful: http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%202.7/builds/77 ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 16:37:22 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Aug 2012 14:37:22 +0000 Subject: [issue13498] os.makedirs exist_ok documentation is incorrect, as is some of the behavior In-Reply-To: <1322574123.12.0.756700598965.issue13498@psf.upfronthosting.co.za> Message-ID: <1344004642.86.0.797441715821.issue13498@psf.upfronthosting.co.za> R. David Murray added the comment: I want the opposite: a way to say I don't care what the mode is as long as it exists. Currently there is no way to do that, as far as I remember. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 16:52:09 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Aug 2012 14:52:09 +0000 Subject: [issue15492] textwrap.wrap expand_tabs does not behave as expected In-Reply-To: <1343596317.09.0.0346303694102.issue15492@psf.upfronthosting.co.za> Message-ID: <1344005529.6.0.474726377296.issue15492@psf.upfronthosting.co.za> R. David Murray added the comment: I think that expanding them before wrapping is correct. Any lining up would be true only for the original unwrapped input text. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 16:56:47 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Aug 2012 14:56:47 +0000 Subject: [issue15494] Move test/support.py into a test.support subpackage In-Reply-To: <1343612231.54.0.0439576601623.issue15494@psf.upfronthosting.co.za> Message-ID: <1344005807.1.0.100816997219.issue15494@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 16:57:44 2012 From: report at bugs.python.org (=?utf-8?b?T25kxZllaiDEjGVydMOtaw==?=) Date: Fri, 03 Aug 2012 14:57:44 +0000 Subject: [issue15540] Python 3.3 and numpy In-Reply-To: <1343941846.47.0.970447396436.issue15540@psf.upfronthosting.co.za> Message-ID: <1344005864.41.0.109756068768.issue15540@psf.upfronthosting.co.za> Ond?ej ?ert?k added the comment: Here is my new patch: https://github.com/numpy/numpy/pull/372 It implements what I was talking about (and fixes the NumPy tests bug). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 17:09:36 2012 From: report at bugs.python.org (Cory Mintz) Date: Fri, 03 Aug 2012 15:09:36 +0000 Subject: [issue15549] openssl version in windows builds does not support renegotiation Message-ID: <1344006576.37.0.61147044371.issue15549@psf.upfronthosting.co.za> New submission from Cory Mintz: The Python 2.7.3 and 2.6.8 Windows builds are both built against "OpenSSL 0.9.8l 5 Nov 2009". This specific version of OpenSSL had renegotiation removed due a security vulnerability. Except from http://svn.python.org/projects/external/openssl-0.9.8x/NEWS. Major changes between OpenSSL 0.9.8l and OpenSSL 0.9.8m: ... o Support for RFC5746 TLS renegotiation extension. ... Major changes between OpenSSL 0.9.8k and OpenSSL 0.9.8l: o Temporary work around for CVE-2009-3555: disable renegotiation. Can the OpenSSL version be updated to at least OpenSSL 0.9.8m so renegotiation is supported? ---------- components: Windows messages: 167336 nosy: cory.mintz priority: normal severity: normal status: open title: openssl version in windows builds does not support renegotiation type: enhancement versions: Python 2.6, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 17:38:37 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 03 Aug 2012 15:38:37 +0000 Subject: [issue15486] Standardised mechanism for stripping importlib frames from tracebacks In-Reply-To: <1343558803.76.0.656342797945.issue15486@psf.upfronthosting.co.za> Message-ID: <1344008317.36.0.951919623135.issue15486@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 17:40:15 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Aug 2012 15:40:15 +0000 Subject: [issue15550] Trailing white spaces Message-ID: <1344008415.84.0.0454996292543.issue15550@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: My editors are configured to remove trailing spaces (this is useful for removing artifacts of indentation). The flip side of this is that my patches sometimes contain unrelated trailing spaces fixes. Trailing spaces are not significant in any CPython source file, their presence I believe mistake. Easier once we remove all spaces and then prevent the appearance of new, than constantly face to unrelated changes. I'm not attaching a patch (it is too big, over 5 MB), anyone can create it by the following commands: hg status -cn | tr '\n' '\0' | xargs -0 sed -i -re 's/[ \t]+$//' It would be good if the Mercurial would had hook, which automatically remove trailing spaces or prohibit to commit patches that contain trailing spaces. ---------- messages: 167337 nosy: storchaka priority: normal severity: normal status: open title: Trailing white spaces type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 17:40:30 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 03 Aug 2012 15:40:30 +0000 Subject: [issue15425] Another strange Tracebacks with importlib In-Reply-To: <1342987622.49.0.633292920923.issue15425@psf.upfronthosting.co.za> Message-ID: <1344008430.33.0.868741214719.issue15425@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 17:43:05 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 03 Aug 2012 15:43:05 +0000 Subject: [issue15487] Correct __sizeof__ support for buffered I/O In-Reply-To: <1343567445.16.0.656305805275.issue15487@psf.upfronthosting.co.za> Message-ID: <1344008585.03.0.462510169485.issue15487@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 17:59:14 2012 From: report at bugs.python.org (Travis Oliphant) Date: Fri, 03 Aug 2012 15:59:14 +0000 Subject: [issue15540] Python 3.3 and numpy In-Reply-To: <20120803083522.Horde.FdzmXqGZi1VQG3EqdU-WNkA@webmail.df.eu> Message-ID: Travis Oliphant added the comment: On Aug 3, 2012, at 1:35 AM, Martin v. L?wis wrote: > > Martin v. L?wis added the comment: > >> This is a mis-understanding of what NumPy does and why. There is >> a need to byte-swap only when the data is stored on disk in the >> reverse order from the native machine > > So is there ever a need to byte-swap Unicode strings? I can see how *numeric* > data are stored using the internal representation on disk; this is a common > technique. For strings, there is the notion of encodings which makes the > relationship between internal and disk representations. So if NumPy applies > the numeric concept to string data, then this is a flaw. Apologies for not using correct terminology. I had to spend a lot of time getting to know Unicode when I wrote NumPy, but am rusty on the key points and so I may communicate incorrectly. The NumPy representation of Unicode strings is always UTF-32BE or UTF-32LE (depending on the data-type of the array). The question is what to do when extracting this data into an array-scalar (which for Unicode objects has exactly the same representation as a PyUnicodeObject). In fact, the NumPy Unicode array scalar is a C-sub-type of PyUnicodeObject and inherits from both the PyUnicodeObject and the NumPy "Character" interface --- a likely rare example of dual-inheritance at the C-level. > > It may be that people really do store text data in the same memory blob > as numeric data and dump it to a file, but they really should think of this > data as "UTF-16-BE" or "UTF-32-LE" and the like, not in terms of byte > swapping. > You can use PyUnicode_Decode to create a Unicode object given a void*, > a length, and a codec name. The concept "native Unicode representation" > does not exist - people use all of two-byte, four-byte and UTF-8 > representations > in memory, on a single processor architecture and operating system. I understand all the representations of Unicode data. There is, however, a native byte-order and that's what I was talking about. > >> The byte-swapping must be done prior to conversion to a Python >> Unicode-Object when selecting data out of the array. > > So if the byte swapping is done before the Unicode object is created: > why did Dave and Ond?ej run into problems then? There were at least 2 issues: 1) a bad test that was written by someone who didn't understand you shouldn't have "byte-swapped" unicode strings as "strings" and 2) a mis-understanding of what was happening going from the data stored in a NumPy array and the Python "scalar" object that was being created. . Thank you for your explanations. It's very helpful. Also, thank you for the PEP and improvements in Python 3.3. The situation is *much* nicer now as NumPy is doing all kinds of hackery to support both narrow and wide builds. This hackery could likely be improved even pre Python 3.3, but it's more clear how to handle the situation now in Python 3.3 > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 18:40:01 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 03 Aug 2012 16:40:01 +0000 Subject: [issue15549] openssl version in windows builds does not support renegotiation In-Reply-To: <1344006576.37.0.61147044371.issue15549@psf.upfronthosting.co.za> Message-ID: <1344012001.45.0.990498927921.issue15549@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 19:02:33 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 03 Aug 2012 17:02:33 +0000 Subject: [issue15510] textwrap.wrap('') returns empty list In-Reply-To: <1343697979.41.0.629576632811.issue15510@psf.upfronthosting.co.za> Message-ID: <1344013353.68.0.439654014334.issue15510@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: I think this is a bug. The question to ponder is backwards compatibility, specially if this is going to be backported to 2.7/3.2. Chris, could you possibly ask for opinions in python-dev and/or python-list? ---------- stage: patch review -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 19:32:46 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 03 Aug 2012 17:32:46 +0000 Subject: [issue15510] textwrap.wrap('') returns empty list In-Reply-To: <1343697979.41.0.629576632811.issue15510@psf.upfronthosting.co.za> Message-ID: <1344015166.43.0.608768469913.issue15510@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 20:08:18 2012 From: report at bugs.python.org (Jason Baker) Date: Fri, 03 Aug 2012 18:08:18 +0000 Subject: [issue15551] Unit tests that return generators silently fail Message-ID: <1344017298.6.0.769704462398.issue15551@psf.upfronthosting.co.za> New submission from Jason Baker: The following test will pass silently: class SomeTest(unittest.TestCase): def testSomething(self): yield 1 self.fail() ---------- components: None messages: 167340 nosy: Jason.Baker priority: normal severity: normal status: open title: Unit tests that return generators silently fail versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 20:08:58 2012 From: report at bugs.python.org (Alex Gaynor) Date: Fri, 03 Aug 2012 18:08:58 +0000 Subject: [issue15551] Unit tests that return generators silently fail In-Reply-To: <1344017298.6.0.769704462398.issue15551@psf.upfronthosting.co.za> Message-ID: <1344017338.95.0.880014746351.issue15551@psf.upfronthosting.co.za> Changes by Alex Gaynor : ---------- nosy: +alex _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 20:37:32 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 03 Aug 2012 18:37:32 +0000 Subject: [issue15510] textwrap.wrap('') returns empty list In-Reply-To: <1343697979.41.0.629576632811.issue15510@psf.upfronthosting.co.za> Message-ID: <1344019052.74.0.186605238229.issue15510@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > I think this is a bug. Do you have any argument? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 20:57:37 2012 From: report at bugs.python.org (Larry Hastings) Date: Fri, 03 Aug 2012 18:57:37 +0000 Subject: [issue15547] Why do we have os.truncate() and os.ftruncate() whereas os.truncate() accepts a file descriptor? In-Reply-To: <1343995984.36.0.909130129312.issue15547@psf.upfronthosting.co.za> Message-ID: <1344020257.11.0.0481195989318.issue15547@psf.upfronthosting.co.za> Larry Hastings added the comment: Because both functions were available in 3.2, and we can't remove old functions without a full deprecation cycle. ---------- resolution: -> wont fix stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 21:11:08 2012 From: report at bugs.python.org (Dominique Leuenberger) Date: Fri, 03 Aug 2012 19:11:08 +0000 Subject: [issue15552] gettext: if looking for .mo in default locations, also look in locale-bundle location Message-ID: <1344021068.11.0.875930388835.issue15552@psf.upfronthosting.co.za> New submission from Dominique Leuenberger: Coming from openSUSE, might be a bit special, but worthy the discussion. Background: - Language files are per design split off from the main application rpm (package-lang). Rational is 'space concerns for live CDs' - We offer bundle-lang- packages, with a set of commonly used applications translations bundled in one 'Please translate my system to LANG' RPM. Again: for the Live CD, we do bundle a limited set of language files (thus installing a subset of all .mo files provided by all packages). => now as rpm does not like a file at the same location to be owned by two packages, the bundle-lang- package 'moves' it's own .mo files to /usr/share/locale-bundle, wheras the -lang rpm installs the .mo files under /usr/share/locale (default path). Now, the issue is gettext.py checks the path proposed by the calling app using bindtextdomain(domain,[path]). If path is defined, it's being used, otherwise /usr/share/locale is being used. The attached patch extends the logic to: - If path is being used - If path = _default_localedir - Check for .mo in _default_bundlelocaledir - if not found in bundle, check in _default_localedir - Use path - if path is not defined - use _default_bundlelocaledir - if not found, use _default_localedir => so in any case, if default_bundlelocaledir is not used, it falls back to _default_localedir, and as such I'd argue is unintrusive and keeping the patch in upstream codebase (instead of downstream package) would make sense. Best regards, ---------- components: Library (Lib) files: python-bundle-lang.patch keywords: patch messages: 167343 nosy: Dominique.Leuenberger priority: normal severity: normal status: open title: gettext: if looking for .mo in default locations, also look in locale-bundle location versions: Python 2.7 Added file: http://bugs.python.org/file26679/python-bundle-lang.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 21:12:41 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 03 Aug 2012 19:12:41 +0000 Subject: [issue15464] ssl: add set_msg_callback function In-Reply-To: <1343352856.85.0.212414509347.issue15464@psf.upfronthosting.co.za> Message-ID: <1344021161.29.0.679324644264.issue15464@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thi?baud, I haven't reviewed the patch in detail, but why does the callback only receive the buffer contents? At the minimum, I think it should also receive write_p (whether the packet is an incoming or outgoing message is a rather useful piece of information). ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 21:27:29 2012 From: report at bugs.python.org (Georg Brandl) Date: Fri, 03 Aug 2012 19:27:29 +0000 Subject: [issue15548] Mention all new os functions in What's New in Python 3.3 In-Reply-To: <1343996760.47.0.232563077305.issue15548@psf.upfronthosting.co.za> Message-ID: <1344022049.29.0.460402203978.issue15548@psf.upfronthosting.co.za> Georg Brandl added the comment: Victor: try "make changes". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 21:41:48 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 03 Aug 2012 19:41:48 +0000 Subject: [issue15544] math.isnan fails with some Decimal NaNs In-Reply-To: <1343962443.78.0.878505736017.issue15544@psf.upfronthosting.co.za> Message-ID: <1344022908.17.0.617770348728.issue15544@psf.upfronthosting.co.za> Stefan Krah added the comment: > OTOH, IEEE 754 *does* cover floating-point to int conversions (5.4.1, 5.8): those fall under 'general-computational operations', and as such should signal when given an sNaN. That sounds good. Let's keep the ValueError then. We could consider InvalidOperation like with Decimal('snan').to_integral(), but that's probably confusing in the context of the math module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 21:47:36 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 03 Aug 2012 19:47:36 +0000 Subject: [issue15544] math.isnan fails with some Decimal NaNs In-Reply-To: <1343962443.78.0.878505736017.issue15544@psf.upfronthosting.co.za> Message-ID: <1344023256.24.0.235062758077.issue15544@psf.upfronthosting.co.za> Stefan Krah added the comment: > Why not add a is_nan() method to float numbers instead? Do you mean replacing math.isnan(x) by x.is_nan() to avoid the issue altogether? I'm not sure that's possible given that math just wraps the C library. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 21:49:31 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 03 Aug 2012 19:49:31 +0000 Subject: [issue15544] math.isnan fails with some Decimal NaNs In-Reply-To: <1344023256.24.0.235062758077.issue15544@psf.upfronthosting.co.za> Message-ID: <1344023218.3377.10.camel@localhost.localdomain> Antoine Pitrou added the comment: > > Why not add a is_nan() method to float numbers instead? > > Do you mean replacing math.isnan(x) by x.is_nan() to avoid the issue > altogether? I'm not sure that's possible given that math just wraps > the C library. Yup. By calling x.is_nan() you would by construction get an implementation that's correct for x's type. If x is a float, it would obviously re-use math.isnan() (or have a similar implementation). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 21:58:36 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Aug 2012 19:58:36 +0000 Subject: [issue15550] Trailing white spaces In-Reply-To: <1344008415.84.0.0454996292543.issue15550@psf.upfronthosting.co.za> Message-ID: <1344023916.67.0.798404116019.issue15550@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Because CPython repository contains binary files too, they should be reverted: hg diff | sed -nre 's/^Binary file (.*) has changed/\1/p' | tr '\n' '\0' | xargs -0 hg revert ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 22:16:15 2012 From: report at bugs.python.org (Ned Deily) Date: Fri, 03 Aug 2012 20:16:15 +0000 Subject: [issue15550] Trailing white spaces In-Reply-To: <1344008415.84.0.0454996292543.issue15550@psf.upfronthosting.co.za> Message-ID: <1344024975.95.0.173827371264.issue15550@psf.upfronthosting.co.za> Ned Deily added the comment: There already is a hook in place for the main python.org repository that checks for and rejects changesets that include files with space issues: http://hg.python.org/hooks/file/bd04c6b37749/checkwhitespace.py You can add it to your local repo to check patches before they are pushed. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 22:23:02 2012 From: report at bugs.python.org (Ned Deily) Date: Fri, 03 Aug 2012 20:23:02 +0000 Subject: [issue15551] Unit tests that return generators silently fail In-Reply-To: <1344017298.6.0.769704462398.issue15551@psf.upfronthosting.co.za> Message-ID: <1344025382.03.0.801815271363.issue15551@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +ezio.melotti, michael.foord _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 22:25:37 2012 From: report at bugs.python.org (Michael Foord) Date: Fri, 03 Aug 2012 20:25:37 +0000 Subject: [issue15551] Unit tests that return generators silently fail In-Reply-To: <1344017298.6.0.769704462398.issue15551@psf.upfronthosting.co.za> Message-ID: <1344025537.99.0.64980154102.issue15551@psf.upfronthosting.co.za> Michael Foord added the comment: unittest calls test methods to execute tests. Generator functions do nothing (except create a generator) when you call them. Test methods as generators therefore do nothing in unittest. ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 23:00:11 2012 From: report at bugs.python.org (Ethan Furman) Date: Fri, 03 Aug 2012 21:00:11 +0000 Subject: [issue15510] textwrap.wrap('') returns empty list In-Reply-To: <1343697979.41.0.629576632811.issue15510@psf.upfronthosting.co.za> Message-ID: <1344027611.21.0.466370753997.issue15510@psf.upfronthosting.co.za> Ethan Furman added the comment: The documentation says, "Returns a list of output lines"; an empty list is not a list of lines. ---------- nosy: +stoneleaf _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 23:01:41 2012 From: report at bugs.python.org (Ethan Furman) Date: Fri, 03 Aug 2012 21:01:41 +0000 Subject: [issue15510] textwrap.wrap('') returns empty list In-Reply-To: <1343697979.41.0.629576632811.issue15510@psf.upfronthosting.co.za> Message-ID: <1344027701.7.0.254292288534.issue15510@psf.upfronthosting.co.za> Ethan Furman added the comment: Not sure I would worry about fixing it in 2.7, although I don't have strong feelings about that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 23:09:11 2012 From: report at bugs.python.org (Jason Baker) Date: Fri, 03 Aug 2012 21:09:11 +0000 Subject: [issue15551] Unit tests that return generators silently fail In-Reply-To: <1344017298.6.0.769704462398.issue15551@psf.upfronthosting.co.za> Message-ID: <1344028151.69.0.728351412155.issue15551@psf.upfronthosting.co.za> Jason Baker added the comment: I can play this game too! Since generator functions do nothing when used as a unittest test method, there is no value in having a test method that is a generator function. Therefore, it is an error to give a test method that is a generator function. Since it is an error to have a generator function as a test method, the test I gave should fail. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 23:09:18 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 03 Aug 2012 21:09:18 +0000 Subject: [issue15510] textwrap.wrap('') returns empty list In-Reply-To: <1343697979.41.0.629576632811.issue15510@psf.upfronthosting.co.za> Message-ID: <1344028158.14.0.538557489922.issue15510@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > an empty list is not a list of lines Really? >>> "".splitlines() [] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 23:10:01 2012 From: report at bugs.python.org (Michael Foord) Date: Fri, 03 Aug 2012 21:10:01 +0000 Subject: [issue15551] Unit tests that return generators silently fail In-Reply-To: <1344017298.6.0.769704462398.issue15551@psf.upfronthosting.co.za> Message-ID: <1344028201.11.0.888581114994.issue15551@psf.upfronthosting.co.za> Michael Foord added the comment: It's not a game. Have a test method as a generator function is clearly programmer error. Doing nothing is the expected behaviour. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 23:12:05 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 03 Aug 2012 21:12:05 +0000 Subject: [issue15550] Trailing white spaces In-Reply-To: <1344008415.84.0.0454996292543.issue15550@psf.upfronthosting.co.za> Message-ID: <1344028325.81.0.654727358569.issue15550@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Or you can use "make patchcheck" which will (hopefully) warn you of such issues. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 23:17:58 2012 From: report at bugs.python.org (Ethan Furman) Date: Fri, 03 Aug 2012 21:17:58 +0000 Subject: [issue15510] textwrap.wrap('') returns empty list In-Reply-To: <1344028158.14.0.538557489922.issue15510@psf.upfronthosting.co.za> Message-ID: <501C4369.2060102@stoneleaf.us> Ethan Furman added the comment: Antoine Pitrou wrote: > Antoine Pitrou added the comment: > >> an empty list is not a list of lines > > Really? > >>>> "".splitlines() > [] Really. --> ''.split('\n') [''] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 23:24:42 2012 From: report at bugs.python.org (Ethan Furman) Date: Fri, 03 Aug 2012 21:24:42 +0000 Subject: [issue15510] textwrap.wrap('') returns empty list In-Reply-To: <501C4369.2060102@stoneleaf.us> Message-ID: <501C4504.2010403@stoneleaf.us> Ethan Furman added the comment: Ethan Furman wrote: >> Antoine Pitrou added the comment: >> >>>>> "".splitlines() >> [] > > --> ''.split('\n') > [''] I see the docs have been fixed in 3 to explain the not present last empty line. However, sure this is still not correct? --> wrap(' ') [] So if you have code that loops over the return and prints it out: for line in wrap(blah): print(line) you will have different output with [] than with ['']. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 23:24:50 2012 From: report at bugs.python.org (Jason Baker) Date: Fri, 03 Aug 2012 21:24:50 +0000 Subject: [issue15551] Unit tests that return generators silently fail In-Reply-To: <1344017298.6.0.769704462398.issue15551@psf.upfronthosting.co.za> Message-ID: <1344029090.37.0.972180281653.issue15551@psf.upfronthosting.co.za> Jason Baker added the comment: Who expects this behavior? Can you give me an example of when someone would rely upon a generator test to do nothing? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 23:25:30 2012 From: report at bugs.python.org (Michael Foord) Date: Fri, 03 Aug 2012 21:25:30 +0000 Subject: [issue15551] Unit tests that return generators silently fail In-Reply-To: <1344017298.6.0.769704462398.issue15551@psf.upfronthosting.co.za> Message-ID: <1344029130.65.0.971731500289.issue15551@psf.upfronthosting.co.za> Michael Foord added the comment: It's the expected behaviour according to the unittest specification. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 23:28:30 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 03 Aug 2012 21:28:30 +0000 Subject: [issue15510] textwrap.wrap('') returns empty list In-Reply-To: <501C4369.2060102@stoneleaf.us> Message-ID: <1344029158.3377.17.camel@localhost.localdomain> Antoine Pitrou added the comment: > Really. > > --> ''.split('\n') > [''] You claimed that an empty list is not a list of lines. I countered that splitlines(), which *by definition* returns a list of lines, can return an empty list, therefore textwrap.wrap() is not exotic in its behaviour. Whether or not split() behaves differently is irrelevant. > So if you have code that loops over the return and prints it out: > > for line in wrap(blah): > print(line) > > you will have different output with [] than with ['']. Indeed, which is a good reason *not* to change textwrap.wrap's behaviour. The current behaviour is as reasonable as any other, and changing it would break compatibility. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 23:31:57 2012 From: report at bugs.python.org (Jason Baker) Date: Fri, 03 Aug 2012 21:31:57 +0000 Subject: [issue15551] Unit tests that return generators silently fail In-Reply-To: <1344017298.6.0.769704462398.issue15551@psf.upfronthosting.co.za> Message-ID: <1344029517.74.0.00514176566253.issue15551@psf.upfronthosting.co.za> Jason Baker added the comment: I would like to verify this. Link the specification, and highlight where it says that the expected behavior for a test method that is a generator function is to do nothing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 23:39:28 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 03 Aug 2012 21:39:28 +0000 Subject: [issue15547] Why do we have os.truncate() and os.ftruncate() whereas os.truncate() accepts a file descriptor? In-Reply-To: <1344020257.11.0.0481195989318.issue15547@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Oh, I see: os.ftruncate() is present in Python 3.2; but os.truncate() was added to Python 3.3. Ok, it's an excellent reason to not remove os.ftruncate() ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 23:39:34 2012 From: report at bugs.python.org (Ethan Furman) Date: Fri, 03 Aug 2012 21:39:34 +0000 Subject: [issue15510] textwrap.wrap('') returns empty list In-Reply-To: <1344029158.3377.17.camel@localhost.localdomain> Message-ID: <501C4881.4060802@stoneleaf.us> Ethan Furman added the comment: Antoine Pitrou wrote: > Antoine Pitrou added the comment: > >> Really. >> >> --> ''.split('\n') >> [''] > > You claimed that an empty list is not a list of lines. I countered that > splitlines(), which *by definition* returns a list of lines, can return > an empty list, therefore textwrap.wrap() is not exotic in its behaviour. > Whether or not split() behaves differently is irrelevant. Not at all -- it's a warning to think "Why does this shortcut function exist? How is it different?" Something I will pay more attention to. ;) >> So if you have code that loops over the return and prints it out: >> >> for line in wrap(blah): >> print(line) >> >> you will have different output with [] than with ['']. > > Indeed, which is a good reason *not* to change textwrap.wrap's > behaviour. The current behaviour is as reasonable as any other, and > changing it would break compatibility. For an empty string, sure -- for a string with nothing but white space, no: --> wrap(' ') [] --> ' '.splitlines() [' '] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 3 23:42:48 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 03 Aug 2012 21:42:48 +0000 Subject: [issue15510] textwrap.wrap('') returns empty list In-Reply-To: <1343697979.41.0.629576632811.issue15510@psf.upfronthosting.co.za> Message-ID: <1344030168.51.0.861309944323.issue15510@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > For an empty string, sure -- for a string with nothing but white space, > no: > --> wrap(' ') > [] That's because wrap() suppresses extra whitespace by default. Once extra whitespace is suppressed, you are left with an empty text, meaning an empty list of lines. That's perfectly logical. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 00:18:21 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 03 Aug 2012 22:18:21 +0000 Subject: [issue15530] Enhance Py_MIN and Py_MAX In-Reply-To: <1343997178.3377.4.camel@localhost.localdomain> Message-ID: <20120804001819.Horde.3MMmdqGZi1VQHE4rqsTXyVA@webmail.df.eu> Martin v. L?wis added the comment: >> I think the feature is somewhat desirable; I agree code combining >> different types in MIN or MAX is flawed - if it is intentional, asking >> for an explicit cast is not asking too much. > > I don't agree. Trying to battle with C's semantics doesn't seem very > productive, especially if it's only done in a single pair of macros. What do you disagree with? That "combining different types in MIN and MAX is flawed"? Or that "asking for an explicit cast is not asking too much"? Whether or not the patch is an appropriate measure is only the second question - what I said is that the kind of code that it detects is indeed flawed. If you disagree, can you kindly give an example where mixing types in min and max would be legitimate? For the specific case of mixing signed and unsigned, there is wide-spread agreement that people should avoid it, and some compilers detect the flawed code quite well. Some cases are defined to have undefined behavior; other cases do have well-defined behavior, but many C developers are unaware of what the exact semantics is. Mixing integers with pointers is already detected by compilers sufficiently. Mixing integers with floating point isn't really an issue in Python's source code, so I don't worry about this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 00:23:44 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 03 Aug 2012 22:23:44 +0000 Subject: [issue15530] Enhance Py_MIN and Py_MAX In-Reply-To: <20120804001819.Horde.3MMmdqGZi1VQHE4rqsTXyVA@webmail.df.eu> Message-ID: <1344032470.3377.27.camel@localhost.localdomain> Antoine Pitrou added the comment: > >> I think the feature is somewhat desirable; I agree code combining > >> different types in MIN or MAX is flawed - if it is intentional, asking > >> for an explicit cast is not asking too much. > > > > I don't agree. Trying to battle with C's semantics doesn't seem very > > productive, especially if it's only done in a single pair of macros. > > What do you disagree with? That "combining different types in MIN and MAX > is flawed"? Or that "asking for an explicit cast is not asking too much"? The former. If C allows it then what's the point of special-casing Py_MIN and Py_MAX to disallow it? It will only catch a very small fraction of cases anyway. Again, if this is a serious issue (which I don't think it is), it would be better handled by choosing the appropriate compiler options. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 00:27:40 2012 From: report at bugs.python.org (Nadeem Vawda) Date: Fri, 03 Aug 2012 22:27:40 +0000 Subject: [issue15546] Iteration breaks with bz2.open(filename,'rt') In-Reply-To: <1343984674.35.0.733492369263.issue15546@psf.upfronthosting.co.za> Message-ID: <1344032860.6.0.461945849168.issue15546@psf.upfronthosting.co.za> Nadeem Vawda added the comment: The cause of this problem is that BZ2File.read1() sometimes returns b"", even though the file is not at EOF. This happens when the underlying BZ2Decompressor cannot produce any decompressed data from just the block passed to it in _fill_buffer(); in this case, it needs to read more of the compressed stream to make progress. It would seem that BZ2File cannot satisfy the contract of the read1() method - we can't guarantee that a single call to the read() method of the underlying file will allow us to return a non-empty result, whereas returning b"" is reserved for the case where we have reached EOF. Simply removing the read1() method would simply trade this problem for a bigger one (resurrecting issue 10791), so I propose amending BZ2File.read1() to make as many reads from the underlying file as necessary to return a non-empty result. Antoine, what do you think of this? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 00:29:48 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 03 Aug 2012 22:29:48 +0000 Subject: [issue15546] Iteration breaks with bz2.open(filename,'rt') In-Reply-To: <1343984674.35.0.733492369263.issue15546@psf.upfronthosting.co.za> Message-ID: <1344032988.49.0.0483300991628.issue15546@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > I propose amending BZ2File.read1() to make as many reads > from the underlying file as necessary to return a non-empty result. Agreed. IMO, read1()'s contract should be read as a best-effort thing, not an absolute guarantee. Returning an empty string when there is still data available is wrong. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 00:41:37 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 03 Aug 2012 22:41:37 +0000 Subject: [issue15510] textwrap.wrap('') returns empty list In-Reply-To: <1343697979.41.0.629576632811.issue15510@psf.upfronthosting.co.za> Message-ID: <1344033697.63.0.832635975428.issue15510@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > That's because wrap() suppresses extra whitespace by default. But the documentation for drop_whitespace clearly states that, after wrapping, "leading whitespace in the first line is always preserved, though." > Once extra whitespace is suppressed, you are left with an empty text, meaning an empty list of lines. That's perfectly logical. I wouldn't say that it is "perfectly" logical. String methods that drop characters from the beginning or end of a string return an empty string for empty text. >>> " ".strip() '' > Furthermore, by "fixing" this, you may break existing software. Issue 1859 is an arguably larger change that will also break existing software, and that issue has been kept open. One scenario to consider: if we agree to fix issue 1859 in some versions, might that change whether we should address this issue in those versions as well? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 00:45:05 2012 From: report at bugs.python.org (Meador Inge) Date: Fri, 03 Aug 2012 22:45:05 +0000 Subject: [issue15530] Enhance Py_MIN and Py_MAX In-Reply-To: <1343845195.3.0.786704958428.issue15530@psf.upfronthosting.co.za> Message-ID: <1344033905.22.0.579175105205.issue15530@psf.upfronthosting.co.za> Changes by Meador Inge : ---------- nosy: +meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 00:45:56 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 03 Aug 2012 22:45:56 +0000 Subject: [issue15510] textwrap.wrap('') returns empty list In-Reply-To: <1344033697.63.0.832635975428.issue15510@psf.upfronthosting.co.za> Message-ID: <1344033804.3377.30.camel@localhost.localdomain> Antoine Pitrou added the comment: > > That's because wrap() suppresses extra whitespace by default. > > But the documentation for drop_whitespace clearly states that, after > wrapping, "leading whitespace in the first line is always preserved, > though." Ok, then it's a bit fuzzy. That whitespace is as much trailing as leading, after all :) > I wouldn't say that it is "perfectly" logical. String methods that > drop characters from the beginning or end of a string return an empty > string for empty text. > > >>> " ".strip() > '' I'm not sure I see the relevance. strip() returns an empty string because its return type is a string, what else could it return? > > Furthermore, by "fixing" this, you may break existing software. > > Issue 1859 is an arguably larger change that will also break existing > software, and that issue has been kept open. Agreed. I'm gonna post on that issue too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 00:48:19 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 03 Aug 2012 22:48:19 +0000 Subject: [issue1859] textwrap doesn't linebreak on "\n" In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za> Message-ID: <1344034099.93.0.865523992724.issue1859@psf.upfronthosting.co.za> Antoine Pitrou added the comment: After discussing issue15510, I think this should probably be left as-is, or be implemented in a separate function so as to avoid breaking compatibility. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 01:03:00 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 03 Aug 2012 23:03:00 +0000 Subject: [issue15530] Enhance Py_MIN and Py_MAX In-Reply-To: <1344032470.3377.27.camel@localhost.localdomain> Message-ID: <20120804010258.Horde.xaYPMqGZi1VQHFiir_NwYYA@webmail.df.eu> Martin v. L?wis added the comment: > The former. If C allows it then what's the point of special-casing > Py_MIN and Py_MAX to disallow it? "C allows it" includes cases like "C allows an the result to be implementation-defined, or an implementation-defined signal to be raised", and indeed, some compilers do raise signals in the cases where they are allowed to. I'd rather not have code in the Python implementation that raises implementation-defined signals on some systems and gives implementation-defined results on other systems. > Again, if this is a serious issue (which I don't think it is) I agree. > it would be better handled by choosing the appropriate compiler options. It might well be that this *is* the appropriate compiler option (even though it's not a compiler command line flag, but a compiler language extension). In any case, there seems to be agrement that this is not a serious issue (Victor said he didn't catch any new errors when using this), so I'm rejecting the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 01:03:08 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 03 Aug 2012 23:03:08 +0000 Subject: [issue15530] Enhance Py_MIN and Py_MAX In-Reply-To: <1343845195.3.0.786704958428.issue15530@psf.upfronthosting.co.za> Message-ID: <1344034988.43.0.207452279238.issue15530@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 01:06:36 2012 From: report at bugs.python.org (Eric Snow) Date: Fri, 03 Aug 2012 23:06:36 +0000 Subject: [issue14905] zipimport.c needs to support namespace packages when no 'directory' entry exists In-Reply-To: <1337905627.12.0.841961188355.issue14905@psf.upfronthosting.co.za> Message-ID: <1344035196.38.0.582510078221.issue14905@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 01:09:08 2012 From: report at bugs.python.org (Meador Inge) Date: Fri, 03 Aug 2012 23:09:08 +0000 Subject: [issue15530] Enhance Py_MIN and Py_MAX In-Reply-To: <1343845195.3.0.786704958428.issue15530@psf.upfronthosting.co.za> Message-ID: <1344035348.46.0.272644411432.issue15530@psf.upfronthosting.co.za> Meador Inge added the comment: I am indifferent with respect to the use of the GCC extensions, but getting rid of the umpteen different implementations of MIN/MAX is a nice , albeit very minor, cleanup. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 01:10:05 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 03 Aug 2012 23:10:05 +0000 Subject: [issue15543] central documentation for 'universal newlines' In-Reply-To: <1343953234.25.0.0555174882779.issue15543@psf.upfronthosting.co.za> Message-ID: <1344035405.38.0.00382164562085.issue15543@psf.upfronthosting.co.za> Chris Jerdonek added the comment: See also: f17a1410ebe5 ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 01:12:54 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 03 Aug 2012 23:12:54 +0000 Subject: [issue15543] central documentation for 'universal newlines' In-Reply-To: <1343953234.25.0.0555174882779.issue15543@psf.upfronthosting.co.za> Message-ID: <1344035574.69.0.93128834228.issue15543@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Since universal newline mode is discouraged and getting deprecated in > the built-in open() function There may (or may not :-)) be a misunderstanding. Universal newlines are not discouraged; it's the legacy "U" flag which is deprecated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 01:13:14 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 03 Aug 2012 23:13:14 +0000 Subject: [issue15530] Enhance Py_MIN and Py_MAX In-Reply-To: <1344035348.46.0.272644411432.issue15530@psf.upfronthosting.co.za> Message-ID: <20120804011313.Horde.r5tDQ6GZi1VQHFsJGi1nVwA@webmail.df.eu> Martin v. L?wis added the comment: > I am indifferent with respect to the use of the GCC extensions, but > getting rid of the umpteen different implementations of MIN/MAX is a > nice , albeit very minor, cleanup. I think that's a different issue from the one we have here, though (which specifically targets using GCC extensions). I also agree that combining the MIN/MAX implementation (naturally into Py_MIN/Py_MAX) is desirable - I don't think that needs an issue. I'm opposed to reducing the number of times of expression evaluation on GCC (i.e. statement expressions). If there are cases where the double evaluation has side effects, I'd rather have it fail on GCC as well (and not just on MSVC). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 01:31:58 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Aug 2012 23:31:58 +0000 Subject: [issue13119] Newline for print() is \n on Windows, and not \r\n as expected In-Reply-To: <1317934788.08.0.425265217585.issue13119@psf.upfronthosting.co.za> Message-ID: <3Wpkzw3f80zPnN@mail.python.org> Roundup Robot added the comment: New changeset c55dbb84f3b4 by Victor Stinner in branch 'default': Close #13119: use "\r\n" newline for sys.stdout/err on Windows http://hg.python.org/cpython/rev/c55dbb84f3b4 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 01:33:09 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 03 Aug 2012 23:33:09 +0000 Subject: [issue15543] central documentation for 'universal newlines' In-Reply-To: <1343953234.25.0.0555174882779.issue15543@psf.upfronthosting.co.za> Message-ID: <1344036789.25.0.970877724308.issue15543@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > There may (or may not :-)) be a misunderstanding. Universal newlines are not discouraged; it's the legacy "U" flag which is deprecated. Already understood. :) (I said "in the built-in open() function" above and meant "mode" as in "flag".) I nosied you only because you copy and pasted information about universal newlines that might benefit from a glossary entry or some such about universal newlines. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 01:37:34 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 03 Aug 2012 23:37:34 +0000 Subject: [issue1859] textwrap doesn't linebreak on "\n" In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za> Message-ID: <1344037054.61.0.352232295136.issue1859@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > After discussing issue15510, I think this should probably be left as-is, or be implemented in a separate function so as to avoid breaking compatibility. Note that this issue can be addressed without affecting backwards compatibility in the documented supported cases. textwrap.wrap()'s documentation says that it only supports single paragraph input and even warns against "strange output" otherwise. Also, as Mark pointed out above, what use case does replace_whitespace=False have if this issue is not addressed? http://bugs.python.org/issue1859#msg96064 Addressing this issue would give that argument meaning (for multi-paragraph input). Finally, just to be clear, I marked issue 15510 as a dependency in the sense that I felt it should be decided before addressing this issue -- not that the issue needed to be addressed in the affirmative. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 01:38:38 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 03 Aug 2012 23:38:38 +0000 Subject: [issue12605] Enhancements to gdb 7 debugging hooks In-Reply-To: <1311282134.06.0.337847665651.issue12605@psf.upfronthosting.co.za> Message-ID: <1344037118.93.0.120770638841.issue12605@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 01:42:20 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Aug 2012 23:42:20 +0000 Subject: [issue13119] Newline for print() is \n on Windows, and not \r\n as expected In-Reply-To: <1317934788.08.0.425265217585.issue13119@psf.upfronthosting.co.za> Message-ID: <3WplCt5fG8zPns@mail.python.org> Roundup Robot added the comment: New changeset 09408b990ca5 by Victor Stinner in branch '3.2': Close #13119: use "\r\n" newline for sys.stdout/err on Windows http://hg.python.org/cpython/rev/09408b990ca5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 01:53:33 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 03 Aug 2012 23:53:33 +0000 Subject: [issue10841] binary stdio In-Reply-To: <1294279917.2.0.685442041198.issue10841@psf.upfronthosting.co.za> Message-ID: <1344038013.06.0.830476482036.issue10841@psf.upfronthosting.co.za> STINNER Victor added the comment: For the record, this change (always set stdout and stderr in binary mode on Windows) introduced (at least???) the following regressions: - #11272: "input() has trailing carriage return on windows", fixed in Python 3.2.1 - #11395: "print(s) fails on Windows with long strings", fixed in Python 3.2.1 - #13119: "Newline for print() is \n on Windows, and not \r\n as expected", will be fixed in Python 3.2.4 and 3.3 (not released yet) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 02:05:24 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 04 Aug 2012 00:05:24 +0000 Subject: [issue15510] textwrap.wrap('') returns empty list In-Reply-To: <1343697979.41.0.629576632811.issue15510@psf.upfronthosting.co.za> Message-ID: <1344038724.28.0.898759875962.issue15510@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > > wrapping, "leading whitespace in the first line is always preserved, > > though." > Ok, then it's a bit fuzzy. That whitespace is as much trailing as > leading, after all :) That's why the word "always" is there. :) > I'm not sure I see the relevance. strip() returns an empty string > because its return type is a string, what else could it return? My point was that your line of logic was not as clear-cut as you suggested. One could argue that dropping whitespace to become the empty string is more reasonable than dropping it become "no string". Is it your opinion that no changes to textwrap should be made in any versions that change existing behavior on some input? Otherwise, what are your criteria? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 02:12:46 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 Aug 2012 00:12:46 +0000 Subject: [issue15510] textwrap.wrap('') returns empty list In-Reply-To: <1344038724.28.0.898759875962.issue15510@psf.upfronthosting.co.za> Message-ID: <1344039013.3377.37.camel@localhost.localdomain> Antoine Pitrou added the comment: Le samedi 04 ao?t 2012 ? 00:05 +0000, Chris Jerdonek a ?crit : > Chris Jerdonek added the comment: > > > > wrapping, "leading whitespace in the first line is always preserved, > > > though." > > Ok, then it's a bit fuzzy. That whitespace is as much trailing as > > leading, after all :) > > That's why the word "always" is there. :) I'm not sure that's the right interpretation. The only point of preserving whitespace is to preserve indentation, which is pointless when there's nothing after the whitespace. > > I'm not sure I see the relevance. strip() returns an empty string > > because its return type is a string, what else could it return? > > My point was that your line of logic was not as clear-cut as you > suggested. One could argue that dropping whitespace to become the > empty string is more reasonable than dropping it become "no string". Of course. The point is, if the alternative is no better than the current behaviour, the status quo wins. > Is it your opinion that no changes to textwrap should be made in any > versions that change existing behavior on some input? As far as these changes don't fix obvious bugs, no, they shouldn't. People certainly rely on the current behaviour, and they will start getting extraneous newlines if you change it (because they will call '\n'.join(...)). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 02:31:31 2012 From: report at bugs.python.org (STINNER Victor) Date: Sat, 04 Aug 2012 00:31:31 +0000 Subject: [issue12655] Expose sched.h functions In-Reply-To: <1311959395.98.0.305576868025.issue12655@psf.upfronthosting.co.za> Message-ID: <1344040291.57.0.498667679316.issue12655@psf.upfronthosting.co.za> STINNER Victor added the comment: I'm sorry, I missed this issue. I just saw its API and I have remarks on the cpu_set type: * Why not reusing the set type for input parameters and the result of sched_getaffinity? * Method names of cpu_set are very different than names of the set type * Why do I need to specify the number of CPU? signal.pthread_sigmask() accepts any iterable object as input, convert it to a sigset_t. For the result, it converts the new sigset_t to a classic Python set object. Is it possible to get the number of CPU to be able to convert a Python set to a cpu_set? ---------- nosy: +haypo resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 02:32:03 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 04 Aug 2012 00:32:03 +0000 Subject: [issue15510] textwrap.wrap('') returns empty list In-Reply-To: <1343697979.41.0.629576632811.issue15510@psf.upfronthosting.co.za> Message-ID: <1344040323.77.0.258834556013.issue15510@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > As far as these changes don't fix obvious bugs, no, they shouldn't. People certainly rely on the current behaviour, and they will start getting extraneous newlines if you change it (because they will call '\n'.join(...)). That line of reasoning is acceptable to me. And I said from the beginning that I'm open to resolving this issue via changes to the documentation. But I feel this criterion was not applied to issue 1859. wrap()'s behavior on newlines is broken to the point that multi-paragraph input is acknowledged as not working. Additionally, because of that the keyword argument replace_whitespace has no clear use case. That seems like an obvious bug to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 02:33:40 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 Aug 2012 00:33:40 +0000 Subject: [issue15510] textwrap.wrap('') returns empty list In-Reply-To: <1344040323.77.0.258834556013.issue15510@psf.upfronthosting.co.za> Message-ID: <1344040267.3377.38.camel@localhost.localdomain> Antoine Pitrou added the comment: Le samedi 04 ao?t 2012 ? 00:32 +0000, Chris Jerdonek a ?crit : > But I feel this criterion was not applied to issue 1859. wrap()'s > behavior on newlines is broken to the point that multi-paragraph input > is acknowledged as not working. Additionally, because of that the > keyword argument replace_whitespace has no clear use case. That seems > like an obvious bug to me. Ok, I probably read the issue too quickly. Feel free to ignore my comment then :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 02:35:02 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 Aug 2012 00:35:02 +0000 Subject: [issue12655] Expose sched.h functions In-Reply-To: <1311959395.98.0.305576868025.issue12655@psf.upfronthosting.co.za> Message-ID: <1344040502.04.0.954359099876.issue12655@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Is it possible to get the number of CPU to be able to convert a Python > set to a cpu_set? sched_getaffinity returns EINVAL if the cpu_set is too small, so it should be easy enough to iterate. I agree the API should be changed for something saner, and before 3.3. Sorry for not looking at the patch in more detail when it was first submitted. I will try to cook up a new patch this week-end. ---------- nosy: +georg.brandl priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 02:44:34 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 Aug 2012 00:44:34 +0000 Subject: [issue15543] central documentation for 'universal newlines' In-Reply-To: <1343953234.25.0.0555174882779.issue15543@psf.upfronthosting.co.za> Message-ID: <1344041074.54.0.285651693781.issue15543@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > I nosied you only because you copy and pasted information about > universal newlines that might benefit from a glossary entry or some > such about universal newlines. Yes, it might benefit from a glossary entry. On the other hand, the details of the *newline* argument should probably remain in the API descriptions themselves. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 02:54:10 2012 From: report at bugs.python.org (STINNER Victor) Date: Sat, 04 Aug 2012 00:54:10 +0000 Subject: [issue15553] Segfault in test_6_daemon_threads() of test_threading, on Mac OS X Lion Message-ID: <1344041649.82.0.110527224272.issue15553@psf.upfronthosting.co.za> New submission from STINNER Victor: http://buildbot.python.org/all/builders/AMD64%20Lion%203.2/builds/80/steps/test/logs/stdio [ 54/355/1] test_threading test_acquire_contended (test.test_threading.LockTests) ... ok test_acquire_destroy (test.test_threading.LockTests) ... ok test_acquire_release (test.test_threading.LockTests) ... ok test_constructor (test.test_threading.LockTests) ... ok test_different_thread (test.test_threading.LockTests) ... ok test_reacquire (test.test_threading.LockTests) ... ok test_state_after_timeout (test.test_threading.LockTests) ... ok test_thread_leak (test.test_threading.LockTests) ... ok test_timeout (test.test_threading.LockTests) ... ok test_try_acquire (test.test_threading.LockTests) ... ok test_try_acquire_contended (test.test_threading.LockTests) ... ok test_with (test.test_threading.LockTests) ... ok test__is_owned (test.test_threading.PyRLockTests) ... ok test_acquire_contended (test.test_threading.PyRLockTests) ... ok test_acquire_destroy (test.test_threading.PyRLockTests) ... ok test_acquire_release (test.test_threading.PyRLockTests) ... ok test_constructor (test.test_threading.PyRLockTests) ... ok test_different_thread (test.test_threading.PyRLockTests) ... ok test_reacquire (test.test_threading.PyRLockTests) ... ok test_release_unacquired (test.test_threading.PyRLockTests) ... ok test_thread_leak (test.test_threading.PyRLockTests) ... ok test_timeout (test.test_threading.PyRLockTests) ... ok test_try_acquire (test.test_threading.PyRLockTests) ... ok test_try_acquire_contended (test.test_threading.PyRLockTests) ... ok test_with (test.test_threading.PyRLockTests) ... ok test__is_owned (test.test_threading.CRLockTests) ... ok test_acquire_contended (test.test_threading.CRLockTests) ... ok test_acquire_destroy (test.test_threading.CRLockTests) ... ok test_acquire_release (test.test_threading.CRLockTests) ... ok test_constructor (test.test_threading.CRLockTests) ... ok test_different_thread (test.test_threading.CRLockTests) ... ok test_reacquire (test.test_threading.CRLockTests) ... ok test_release_unacquired (test.test_threading.CRLockTests) ... ok test_thread_leak (test.test_threading.CRLockTests) ... ok test_timeout (test.test_threading.CRLockTests) ... ok test_try_acquire (test.test_threading.CRLockTests) ... ok test_try_acquire_contended (test.test_threading.CRLockTests) ... ok test_with (test.test_threading.CRLockTests) ... ok test_is_set (test.test_threading.EventTests) ... ok test_notify (test.test_threading.EventTests) ... ok test_set_and_clear (test.test_threading.EventTests) ... ok test_timeout (test.test_threading.EventTests) ... ok test__is_owned (test.test_threading.ConditionAsRLockTests) ... ok test_acquire_contended (test.test_threading.ConditionAsRLockTests) ... ok test_acquire_destroy (test.test_threading.ConditionAsRLockTests) ... ok test_acquire_release (test.test_threading.ConditionAsRLockTests) ... ok test_constructor (test.test_threading.ConditionAsRLockTests) ... ok test_different_thread (test.test_threading.ConditionAsRLockTests) ... ok test_reacquire (test.test_threading.ConditionAsRLockTests) ... ok test_release_unacquired (test.test_threading.ConditionAsRLockTests) ... ok test_thread_leak (test.test_threading.ConditionAsRLockTests) ... ok test_timeout (test.test_threading.ConditionAsRLockTests) ... ok test_try_acquire (test.test_threading.ConditionAsRLockTests) ... ok test_try_acquire_contended (test.test_threading.ConditionAsRLockTests) ... ok test_with (test.test_threading.ConditionAsRLockTests) ... ok test_acquire (test.test_threading.ConditionTests) ... ok test_notify (test.test_threading.ConditionTests) ... ok test_timeout (test.test_threading.ConditionTests) ... ok test_unacquired_notify (test.test_threading.ConditionTests) ... ok test_unacquired_wait (test.test_threading.ConditionTests) ... ok test_waitfor (test.test_threading.ConditionTests) ... ok test_waitfor_timeout (test.test_threading.ConditionTests) ... ok test_acquire (test.test_threading.SemaphoreTests) ... ok test_acquire_contended (test.test_threading.SemaphoreTests) ... ok test_acquire_destroy (test.test_threading.SemaphoreTests) ... ok test_acquire_timeout (test.test_threading.SemaphoreTests) ... ok test_constructor (test.test_threading.SemaphoreTests) ... ok test_default_value (test.test_threading.SemaphoreTests) ... ok test_release_unacquired (test.test_threading.SemaphoreTests) ... ok test_try_acquire (test.test_threading.SemaphoreTests) ... ok test_try_acquire_contended (test.test_threading.SemaphoreTests) ... ok test_with (test.test_threading.SemaphoreTests) ... ok test_acquire (test.test_threading.BoundedSemaphoreTests) ... ok test_acquire_contended (test.test_threading.BoundedSemaphoreTests) ... ok test_acquire_destroy (test.test_threading.BoundedSemaphoreTests) ... ok test_acquire_timeout (test.test_threading.BoundedSemaphoreTests) ... ok test_constructor (test.test_threading.BoundedSemaphoreTests) ... ok test_default_value (test.test_threading.BoundedSemaphoreTests) ... ok test_release_unacquired (test.test_threading.BoundedSemaphoreTests) ... ok test_try_acquire (test.test_threading.BoundedSemaphoreTests) ... ok test_try_acquire_contended (test.test_threading.BoundedSemaphoreTests) ... ok test_with (test.test_threading.BoundedSemaphoreTests) ... ok test_PyThreadState_SetAsyncExc (test.test_threading.ThreadTests) ... started worker thread trying nonsensical thread id waiting for worker thread to get started verifying worker hasn't exited attempting to raise asynch exception in worker waiting for worker to say it caught the exception all OK -- joining worker ok test_dummy_thread_after_fork (test.test_threading.ThreadTests) ... ok test_enumerate_after_join (test.test_threading.ThreadTests) ... ok test_finalize_runnning_thread (test.test_threading.ThreadTests) ... ok test_finalize_with_trace (test.test_threading.ThreadTests) ... ok test_foreign_thread (test.test_threading.ThreadTests) ... ok test_ident_of_no_threading_threads (test.test_threading.ThreadTests) ... ok test_join_nondaemon_on_shutdown (test.test_threading.ThreadTests) ... ok test_limbo_cleanup (test.test_threading.ThreadTests) ... ok test_no_refcycle_through_target (test.test_threading.ThreadTests) ... ok test_old_threading_api (test.test_threading.ThreadTests) ... ok test_repr_daemon (test.test_threading.ThreadTests) ... ok test_various_ops (test.test_threading.ThreadTests) ... task will run for 24.7 usec 1 tasks are running task will run for 90.2 usec 2 tasks are running task done is finished. 1 tasks are running task will run for 95.2 usec 2 tasks are running task done is finished. 1 tasks are running task will run for 40.1 usec 2 tasks are running task done is finished. 1 tasks are running task will run for 56.5 usec 2 tasks are running task done is finished. 1 tasks are running task will run for 13.6 usec 2 tasks are running task done is finished. 1 tasks are running task will run for 32.9 usec 2 tasks are running task done is finished. 1 tasks are running task done is finished. 0 tasks are running task will run for 26.2 usec 1 tasks are running task will run for 62.7 usec 2 tasks are running task done is finished. 1 tasks are running task done is finished. 0 tasks are running task will run for 31.9 usec 1 tasks are running waiting for all tasks to complete task done is finished. 0 tasks are running all tasks done ok test_various_ops_large_stack (test.test_threading.ThreadTests) ... with 1MB thread stack size... task will run for 44.6 usec 1 tasks are running task done is finished. 0 tasks are running task will run for 38.3 usec 1 tasks are running task will run for 85.7 usec 2 tasks are running task will run for 98.3 usec 3 tasks are running task done is finished. 2 tasks are running task done is finished. 1 tasks are running task will run for 22.0 usec 2 tasks are running task will run for 49.5 usec 3 tasks are running task will run for 60.1 usec task done is finished. 2 tasks are running task done is finished. 1 tasks are running task done is finished. 0 tasks are running 1 tasks are running task will run for 63.6 usec 2 tasks are running task will run for 92.0 usec 3 tasks are running task will run for 60.7 usec task done is finished. 2 tasks are running task done is finished. 1 tasks are running task done is finished. 0 tasks are running 1 tasks are running task done is finished. 0 tasks are running waiting for all tasks to complete all tasks done ok test_various_ops_small_stack (test.test_threading.ThreadTests) ... with 256kB thread stack size... task will run for 27.1 usec 1 tasks are running task will run for 23.9 usec 2 tasks are running task will run for 33.1 usec 3 tasks are running task done is finished. 2 tasks are running task done is finished. 1 tasks are running task will run for 34.7 usec 2 tasks are running task will run for 73.9 usec 3 tasks are running task will run for 80.9 usec task done is finished. 2 tasks are running task done is finished. 1 tasks are running task done is finished. 0 tasks are running 1 tasks are running task will run for 97.1 usec 2 tasks are running task will run for 99.2 usec 3 tasks are running task done is finished. 2 tasks are running task done is finished. 1 tasks are running task will run for 29.3 usec 2 tasks are running task will run for 70.3 usec 3 tasks are running waiting for all tasks to complete task done is finished. 2 tasks are running task done is finished. 1 tasks are running task done is finished. 0 tasks are running all tasks done ok test_1_join_on_shutdown (test.test_threading.ThreadJoinOnShutdown) ... ok test_2_join_in_forked_process (test.test_threading.ThreadJoinOnShutdown) ... ok test_3_join_in_forked_from_thread (test.test_threading.ThreadJoinOnShutdown) ... ok test_4_joining_across_fork_in_worker_thread (test.test_threading.ThreadJoinOnShutdown) ... ok test_5_clear_waiter_locks_to_avoid_crash (test.test_threading.ThreadJoinOnShutdown) ... ok test_6_daemon_threads (test.test_threading.ThreadJoinOnShutdown) ... FAIL test_reinit_tls_after_fork (test.test_threading.ThreadJoinOnShutdown) ... ok test_daemonize_active_thread (test.test_threading.ThreadingExceptionTests) ... ok test_joining_current_thread (test.test_threading.ThreadingExceptionTests) ... ok test_joining_inactive_thread (test.test_threading.ThreadingExceptionTests) ... ok test_recursion_limit (test.test_threading.ThreadingExceptionTests) ... ok test_start_thread_again (test.test_threading.ThreadingExceptionTests) ... ok test_abort (test.test_threading.BarrierTests) ... ok test_abort_and_reset (test.test_threading.BarrierTests) ... ok test_action (test.test_threading.BarrierTests) ... ok test_barrier (test.test_threading.BarrierTests) ... ok test_barrier_10 (test.test_threading.BarrierTests) ... ok test_default_timeout (test.test_threading.BarrierTests) ... ok test_reset (test.test_threading.BarrierTests) ... ok test_single_thread (test.test_threading.BarrierTests) ... ok test_timeout (test.test_threading.BarrierTests) ... ok test_wait_return (test.test_threading.BarrierTests) ... ok ====================================================================== FAIL: test_6_daemon_threads (test.test_threading.ThreadJoinOnShutdown) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/ambv/Buildbot/3.2.langa-lion/build/Lib/test/test_threading.py", line 696, in test_6_daemon_threads rc, out, err = assert_python_ok('-c', script) File "/Users/ambv/Buildbot/3.2.langa-lion/build/Lib/test/script_helper.py", line 53, in assert_python_ok return _assert_python(True, *args, **env_vars) File "/Users/ambv/Buildbot/3.2.langa-lion/build/Lib/test/script_helper.py", line 45, in _assert_python "stderr follows:\n%s" % (rc, err.decode('ascii', 'ignore'))) AssertionError: Process return code is -11, stderr follows: ---------------------------------------------------------------------- Ran 119 tests in 19.978s FAILED (failures=1) test test_threading failed ---------- assignee: ronaldoussoren components: Interpreter Core, Macintosh messages: 167391 nosy: haypo, ronaldoussoren priority: normal severity: normal status: open title: Segfault in test_6_daemon_threads() of test_threading, on Mac OS X Lion versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 04:16:49 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 04 Aug 2012 02:16:49 +0000 Subject: [issue15510] textwrap.wrap('') returns empty list In-Reply-To: <1343697979.41.0.629576632811.issue15510@psf.upfronthosting.co.za> Message-ID: <1344046609.9.0.781019767768.issue15510@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > Ok, I probably read the issue too quickly. Feel free to ignore my > comment then :-) Thanks. I will prepare another patch for this issue with documentation and test cases of existing behavior. The discussion can of course continue if anyone would like to weigh in further. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 04:21:09 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 04 Aug 2012 02:21:09 +0000 Subject: [issue15543] central documentation for 'universal newlines' In-Reply-To: <1343953234.25.0.0555174882779.issue15543@psf.upfronthosting.co.za> Message-ID: <1344046869.51.0.832702190683.issue15543@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > On the other hand, the details of the *newline* argument should probably remain in the API descriptions themselves. Correct. It would be a high-level entry for "universal newlines" -- independent of any API and suitable for linking to wherever universal newlines are mentioned (e.g. in the documentation of str.splitlines()). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 04:39:38 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 04 Aug 2012 02:39:38 +0000 Subject: [issue15554] correct and clarify str.splitlines() documentation Message-ID: <1344047978.01.0.683229635888.issue15554@psf.upfronthosting.co.za> New submission from Chris Jerdonek: The documentation for str.splitlines()-- http://docs.python.org/dev/library/stdtypes.html#str.splitlines includes a statement that is not quite correct: "Unlike split(), if the string ends with line boundary characters the returned list does not have an empty last element." For example, >>> '\n'.splitlines() [''] >>> '\n\n'.splitlines() ['', ''] >>> '\r\n'.splitlines() [''] >>> '\n\r\n'.splitlines() ['', ''] >>> '\r'.splitlines() [''] >>> 'a\n\n'.splitlines() ['a', ''] Also, the note about split() only applies when split() is passed a separator. For example-- >>> 'a\n'.split('\n') ['a', ''] >>> 'a\n'.split() ['a'] Finally, the function's behavior on the empty string is another difference worth mentioning that is not covered by the existing note. I am attaching a patch that addresses these points. Notice also that the patch phrases it not as whether the list *has* an empty last element, but whether an *additional* last element should be added, which is the more important point. ---------- assignee: docs at python components: Documentation files: issue-splitlines-docs-1.patch keywords: easy, patch messages: 167394 nosy: cjerdonek, docs at python, jcea, pitrou priority: normal severity: normal stage: patch review status: open title: correct and clarify str.splitlines() documentation versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file26680/issue-splitlines-docs-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 05:19:48 2012 From: report at bugs.python.org (Eric Snow) Date: Sat, 04 Aug 2012 03:19:48 +0000 Subject: [issue15352] importlib.h should be regenerated when the marshaling code changes In-Reply-To: <1342294865.71.0.8673703337.issue15352@psf.upfronthosting.co.za> Message-ID: <1344050388.52.0.773727132839.issue15352@psf.upfronthosting.co.za> Eric Snow added the comment: Meador, is this still a problem? There was a flurry of activity in this area. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 06:02:13 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 04 Aug 2012 04:02:13 +0000 Subject: [issue12655] Expose sched.h functions In-Reply-To: <1311959395.98.0.305576868025.issue12655@psf.upfronthosting.co.za> Message-ID: <1344052933.51.0.319012650413.issue12655@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Using a Python set is fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 08:53:19 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Aug 2012 06:53:19 +0000 Subject: [issue15546] Iteration breaks with bz2.open(filename,'rt') In-Reply-To: <1343984674.35.0.733492369263.issue15546@psf.upfronthosting.co.za> Message-ID: <1344063199.73.0.261102944769.issue15546@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I encountered this when implemented bzip2 support in zipfile (issue14371). I solved this also by rewriting read and read1 to make as many reads from the underlying file as necessary to return a non-empty result. ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 10:00:22 2012 From: report at bugs.python.org (abael) Date: Sat, 04 Aug 2012 08:00:22 +0000 Subject: [issue15522] impove 27 percent performance on stringpbject.c( by prefetch and loop optimization) In-Reply-To: <1343826295.99.0.343585939153.issue15522@psf.upfronthosting.co.za> Message-ID: abael added the comment: added my implement( with some enhancement, got better performance, at less for my apps. ). test result: with small chunk of str, got double performanc, and 111% for big chunks; it ## Util funcion for text definition: def pf(f,n): a=time() for i in xrange(n): f() b=time() print n/(b-a) ############################################################################# >>> s=['abcd',u'\u548c\u6613\u541b'] * 1000 >>> pf(lambda:''.join(s), 10000) 2289.28293164 >>> pf(lambda:text.join('',s), 10000) 4457.27947763 >>> s=['abcd'*1000,u'\u548c\u6613\u541b'*1000] * 1000 >>> pf(lambda:''.join(s), 100) 15.2374868484 >>> pf(lambda:text.join('',s), 100) 16.939913023 ############################################################################## 2012/8/1 Antoine Pitrou > > Antoine Pitrou added the comment: > > Hi, several points: > > - Python 2.7 is in bugfix mode; you need to work from the default > Mercurial branch as explained in http://docs.python.org/devguide/ . In > practice, this means your patch will target the future Python 3.4, and > therefore either PyUnicode_Join or _PyBytes_Join. > > - please provide an actual patch (a Mercurial diff, probably) > > - please provide benchmarks (using e.g. timeit) which demonstrate the > performance improvement you are proposing > > ---------- > nosy: +pitrou > versions: +Python 3.4 -Python 2.7 > > _______________________________________ > Python tracker > > _______________________________________ > ---------- Added file: http://bugs.python.org/file26681/stringjoin.c _______________________________________ Python tracker _______________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: stringjoin.c Type: text/x-csrc Size: 2831 bytes Desc: not available URL: From report at bugs.python.org Sat Aug 4 10:13:46 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Aug 2012 08:13:46 +0000 Subject: [issue15522] impove 27 percent performance on stringpbject.c( by prefetch and loop optimization) In-Reply-To: <1343813632.92.0.115452555082.issue15522@psf.upfronthosting.co.za> Message-ID: <1344068026.07.0.113802309689.issue15522@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Please port your code to Python 3.3 and compare with it. Python 3.3 implementation of str.join() already more than twice faster then Python 2.7. Maybe your optimization will have no effect. ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 12:59:53 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sat, 04 Aug 2012 10:59:53 +0000 Subject: [issue13498] os.makedirs exist_ok documentation is incorrect, as is some of the behavior In-Reply-To: <1344004642.86.0.797441715821.issue13498@psf.upfronthosting.co.za> Message-ID: Hynek Schlawack added the comment: do you want it by default or a new flag? default sounds like a source for obscure bugs to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 13:08:07 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 Aug 2012 11:08:07 +0000 Subject: [issue12655] Expose sched.h functions In-Reply-To: <1311959395.98.0.305576868025.issue12655@psf.upfronthosting.co.za> Message-ID: <1344078487.0.0.632850791781.issue12655@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a patch removing cpu_set and using sets of integers instead. ---------- Added file: http://bugs.python.org/file26682/cpuset.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 13:13:05 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 Aug 2012 11:13:05 +0000 Subject: [issue12655] Expose sched.h functions In-Reply-To: <1311959395.98.0.305576868025.issue12655@psf.upfronthosting.co.za> Message-ID: <1344078785.89.0.421230459962.issue12655@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file26682/cpuset.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 13:13:11 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 Aug 2012 11:13:11 +0000 Subject: [issue12655] Expose sched.h functions In-Reply-To: <1311959395.98.0.305576868025.issue12655@psf.upfronthosting.co.za> Message-ID: <1344078791.59.0.0907081431518.issue12655@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Added file: http://bugs.python.org/file26683/cpuset.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 13:49:26 2012 From: report at bugs.python.org (Oscar Campos) Date: Sat, 04 Aug 2012 11:49:26 +0000 Subject: [issue14565] is_cgi doesn't function as documented for cgi_directories In-Reply-To: <1334254866.64.0.659489278184.issue14565@psf.upfronthosting.co.za> Message-ID: <1344080966.56.0.11755503665.issue14565@psf.upfronthosting.co.za> Oscar Campos added the comment: Greetings, I did a diff patch based on the previous work of Glenn Linderman and Pierre Quentel. I did some test and is working well so now the implementation is doing what the docstring says. I already passed the full test suite without problems. I add two patches: CGIHTTPServer.patch is for Python 2.7 http-server.patch is for Python 3.2 This is my first contribution to the Python Core althrough I did follow the Developers Gruide and I already send my Contributor Agreement to the PSF maybe there is something I did wrong, if this is the case just tell me, I'm here to help and learn. Regards. Oscar Campos. ---------- keywords: +patch nosy: +oscar.campos Added file: http://bugs.python.org/file26684/CGIHTTPServer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 13:50:10 2012 From: report at bugs.python.org (Oscar Campos) Date: Sat, 04 Aug 2012 11:50:10 +0000 Subject: [issue14565] is_cgi doesn't function as documented for cgi_directories In-Reply-To: <1334254866.64.0.659489278184.issue14565@psf.upfronthosting.co.za> Message-ID: <1344081010.82.0.952535796662.issue14565@psf.upfronthosting.co.za> Changes by Oscar Campos : Added file: http://bugs.python.org/file26685/http-server.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 15:00:58 2012 From: report at bugs.python.org (STINNER Victor) Date: Sat, 04 Aug 2012 13:00:58 +0000 Subject: [issue12655] Expose sched.h functions In-Reply-To: <1344078791.62.0.253376763697.issue12655@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: sched_getaffinity() does not fail if the set is smaller than the number of CPU. Try with an initial value of ncpus=1. So we cannot start the heuristic with ncpus=16, because it would only return 16 even if the computer has more cpus. Instead of this heuristic, why not simply alway using ncpus = CPU_SETSIZE? I don't know if CPU_SETSIZE is part of the standard (POSIX?). You may also use a constant size (CPU_SETSIZE) of the set used by sched_setaffinity() to simplify the code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 15:01:52 2012 From: report at bugs.python.org (Oscar Campos) Date: Sat, 04 Aug 2012 13:01:52 +0000 Subject: [issue14565] is_cgi doesn't function as documented for cgi_directories In-Reply-To: <1334254866.64.0.659489278184.issue14565@psf.upfronthosting.co.za> Message-ID: <1344085312.5.0.61267514691.issue14565@psf.upfronthosting.co.za> Changes by Oscar Campos : Added file: http://bugs.python.org/file26686/http-server.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 15:03:11 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 Aug 2012 13:03:11 +0000 Subject: [issue12655] Expose sched.h functions In-Reply-To: <1311959395.98.0.305576868025.issue12655@psf.upfronthosting.co.za> Message-ID: <1344085391.34.0.374671131855.issue12655@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Try with an initial value of ncpus=1. Well, I've tried and it works: >>> os.sched_getaffinity(0) {0, 1, 2, 3} > I don't know if CPU_SETSIZE is part of the standard (POSIX?). These are Linux-specific functions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 15:10:54 2012 From: report at bugs.python.org (STINNER Victor) Date: Sat, 04 Aug 2012 13:10:54 +0000 Subject: [issue12655] Expose sched.h functions In-Reply-To: <1344085391.34.0.374671131855.issue12655@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: >> Try with an initial value of ncpus=1. > Well, I've tried and it works: Oh, you're right :-) I only checked ncpus (1), not the final result. It works because CPU_ALLOC_SIZE() rounds the size using sizeof(unsigned long) (64 bits on my CPU). So CPU_ALLOC_SIZE(1) returns 8, and sched_getaffinity() takes the size of the set in bytes, and not the number of CPU. sched_getaffinity(0) returns {0, 1, 2, 3, 4, 5, 6, 7} with ncpus=1 and setsize=8. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 15:11:32 2012 From: report at bugs.python.org (Giampaolo Rodola') Date: Sat, 04 Aug 2012 13:11:32 +0000 Subject: [issue12655] Expose sched.h functions In-Reply-To: <1311959395.98.0.305576868025.issue12655@psf.upfronthosting.co.za> Message-ID: <1344085892.63.0.17845222213.issue12655@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: +1 for Antoine's patch/approach: it's more usable and pythonic. I think documentation should mention and link the existence of: http://docs.python.org/library/multiprocessing.html#multiprocessing.cpu_count ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 15:39:11 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Aug 2012 13:39:11 +0000 Subject: [issue15546] Iteration breaks with bz2.open(filename,'rt') In-Reply-To: <1343984674.35.0.733492369263.issue15546@psf.upfronthosting.co.za> Message-ID: <3Wq5nV0ZwfzPX8@mail.python.org> Roundup Robot added the comment: New changeset cdf27a213bd2 by Nadeem Vawda in branch 'default': #15546: Fix BZ2File.read1()'s handling of pathological input data. http://hg.python.org/cpython/rev/cdf27a213bd2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 15:41:50 2012 From: report at bugs.python.org (Nadeem Vawda) Date: Sat, 04 Aug 2012 13:41:50 +0000 Subject: [issue15546] Iteration breaks with bz2.open(filename,'rt') In-Reply-To: <1343984674.35.0.733492369263.issue15546@psf.upfronthosting.co.za> Message-ID: <1344087710.77.0.435445193694.issue15546@psf.upfronthosting.co.za> Nadeem Vawda added the comment: OK, BZ2File should now be fixed. It looks like LZMAFile and GzipFile may be susceptible to the same problem; I'll push fixes for them shortly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 15:44:28 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Aug 2012 13:44:28 +0000 Subject: [issue12655] Expose sched.h functions In-Reply-To: <1311959395.98.0.305576868025.issue12655@psf.upfronthosting.co.za> Message-ID: <1344087868.73.0.663240232677.issue12655@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > You may also use a constant size (CPU_SETSIZE) of the set used by sched_setaffinity() to simplify the code. As Antoine pointed out to me (and I was convinced itself, experimented with an example from man:CPU_SET(3)) the cpu_set functions work with a sets of more than CPU_SETSIZE processors. ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 16:00:09 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Sat, 04 Aug 2012 14:00:09 +0000 Subject: [issue1859] textwrap doesn't linebreak on "\n" In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za> Message-ID: <1344088809.09.0.544294145824.issue1859@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 16:19:50 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Aug 2012 14:19:50 +0000 Subject: [issue12655] Expose sched.h functions In-Reply-To: <1311959395.98.0.305576868025.issue12655@psf.upfronthosting.co.za> Message-ID: <3Wq6hP0GkFzNqj@mail.python.org> Roundup Robot added the comment: New changeset d6745ddbccbd by Antoine Pitrou in branch 'default': Issue #12655: Instead of requiring a custom type, os.sched_getaffinity and http://hg.python.org/cpython/rev/d6745ddbccbd ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 16:20:56 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 Aug 2012 14:20:56 +0000 Subject: [issue12655] Expose sched.h functions In-Reply-To: <1311959395.98.0.305576868025.issue12655@psf.upfronthosting.co.za> Message-ID: <1344090056.66.0.859203927236.issue12655@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, I've improved the default ncpus value and committed. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 17:26:37 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Aug 2012 15:26:37 +0000 Subject: [issue1859] textwrap doesn't linebreak on "\n" In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za> Message-ID: <1344093997.07.0.27288162918.issue1859@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I believe that the method of work with newlines is too application specific. Someone may prefer empty line separated paragraphs, here is another recipe: def wrap_paragraphs(text, width=70, **kwargs): return [line for para in re.split(r'\n\s*\n', text) for line in (textwrap.wrap(para, width, **kwargs) + [''])][:-1] And here is another application-specific recipe: def format_html_paragraphs(text, width=70, **kwargs): return ''.join('

%s

' % '
'.join(textwrap.wrap(html.escape(para), width, **kwargs)) para in re.split(r'\n\s*\n', text)) I don't see a one obvious way to solve this problem, so I suggest a recipe, not a patch. In any case the specialized text-processing applications are not likely to use textwrap because most output now uses non-monowidth fonts. Textwrap is only for the simplest applications. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 17:59:58 2012 From: report at bugs.python.org (Atsuo Ishimoto) Date: Sat, 04 Aug 2012 15:59:58 +0000 Subject: [issue15555] Default newlines of io.TextIOWrapper Message-ID: <1344095998.81.0.573935781933.issue15555@psf.upfronthosting.co.za> New submission from Atsuo Ishimoto: In http://docs.python.org/dev/library/io.html: "if newline is None, any '\n' characters written are translated to the system default line separator, os.linesep. " But os.linesep is not referred at all. On Windows default newline is always '\r\n' on Windows, '\n' otherwise. ---------- assignee: docs at python components: Documentation messages: 167413 nosy: docs at python, ishimoto priority: normal severity: normal status: open title: Default newlines of io.TextIOWrapper _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 18:07:43 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Sat, 04 Aug 2012 16:07:43 +0000 Subject: [issue15556] os.stat fails for file pending delete on Windows Message-ID: <1344096463.0.0.611888237472.issue15556@psf.upfronthosting.co.za> New submission from Jeremy Kloth: os.stat fails when called on a file that is pending delete but is still in the directory listing. This in turn causes os.path.exists to return the wrong result. Attached is a test case demonstrating this broken behavior. ---------- components: Library (Lib), Windows files: stat-bug.py messages: 167414 nosy: jkloth priority: normal severity: normal status: open title: os.stat fails for file pending delete on Windows versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file26687/stat-bug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 18:10:12 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Sat, 04 Aug 2012 16:10:12 +0000 Subject: [issue15556] os.stat fails for file pending delete on Windows In-Reply-To: <1344096463.0.0.611888237472.issue15556@psf.upfronthosting.co.za> Message-ID: <1344096612.96.0.559479909229.issue15556@psf.upfronthosting.co.za> Changes by Jeremy Kloth : ---------- nosy: +brian.curtin, loewis, pitrou, tim.golden -jkloth _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 18:10:35 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Sat, 04 Aug 2012 16:10:35 +0000 Subject: [issue15556] os.stat fails for file pending delete on Windows In-Reply-To: <1344096463.0.0.611888237472.issue15556@psf.upfronthosting.co.za> Message-ID: <1344096635.17.0.551219108836.issue15556@psf.upfronthosting.co.za> Changes by Jeremy Kloth : ---------- nosy: +jkloth _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 18:17:20 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 Aug 2012 16:17:20 +0000 Subject: [issue15556] os.stat fails for file pending delete on Windows In-Reply-To: <1344096463.0.0.611888237472.issue15556@psf.upfronthosting.co.za> Message-ID: <1344097040.07.0.662045591434.issue15556@psf.upfronthosting.co.za> Antoine Pitrou added the comment: How does it fail? Please paste the precise exception. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 18:22:25 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Sat, 04 Aug 2012 16:22:25 +0000 Subject: [issue15556] os.stat fails for file pending delete on Windows In-Reply-To: <1344096463.0.0.611888237472.issue15556@psf.upfronthosting.co.za> Message-ID: <1344097345.88.0.503115553149.issue15556@psf.upfronthosting.co.za> Jeremy Kloth added the comment: Traceback (most recent call last): File "stat-bug.py", line 12, in print('stat', os.stat(pathname)) PermissionError: [Error 5] Access is denied: '\\Users\\Jeremy\\test.tmp' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 18:34:17 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 04 Aug 2012 16:34:17 +0000 Subject: [issue15556] os.stat fails for file pending delete on Windows In-Reply-To: <1344096463.0.0.611888237472.issue15556@psf.upfronthosting.co.za> Message-ID: <1344098057.17.0.326039220619.issue15556@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Why do you think the behavior is broken? It looks right to me - it's not possible to get file information for a file that is scheduled for deletion. ISTM that rather os.path.exists has non-intuitive behavior; it shouldn't infer from the PermissionError that the file does not exist, but that it is not able to tell. However, this is not a bug, but documented behavior, see http://docs.python.org/library/os.path.html#os.path.exists ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 18:38:44 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Sat, 04 Aug 2012 16:38:44 +0000 Subject: [issue15556] os.stat fails for file pending delete on Windows In-Reply-To: <1344098057.17.0.326039220619.issue15556@psf.upfronthosting.co.za> Message-ID: Jeremy Kloth added the comment: > Why do you think the behavior is broken? It looks right to me - it's not possible to get file information for a file that is scheduled for deletion. However you can when using MSVCRT's stat() function or even FindFirstFile directly. ---------- nosy: +jeremy.kloth _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 18:39:27 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Aug 2012 16:39:27 +0000 Subject: [issue15528] Better support for finalization with weakrefs In-Reply-To: <1343837927.06.0.561023898829.issue15528@psf.upfronthosting.co.za> Message-ID: <1344098367.46.0.565558269514.issue15528@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I don't quite understand the purpose of your suggestions. What can you do with it help, what you can not do with contextlib.ExitStack, atexit, __del__ method, weakref.WeakKeyDictionary or weakref.ref? I read the documentation, but the meaning eludes me. ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 18:52:44 2012 From: report at bugs.python.org (Glenn Linderman) Date: Sat, 04 Aug 2012 16:52:44 +0000 Subject: [issue14565] is_cgi doesn't function as documented for cgi_directories In-Reply-To: <1334254866.64.0.659489278184.issue14565@psf.upfronthosting.co.za> Message-ID: <1344099164.46.0.42538289483.issue14565@psf.upfronthosting.co.za> Glenn Linderman added the comment: Thanks for the patch, Oscar, I've not had more time to follow up on this issue, and haven't yet learned how to generate the patches. While you dropped the "return False" line, which surprised me, the implicit "return None" is sufficiently false, that there no real concern with the correctness of the code in the patch. Hopefully, with your contribution, this issue can progress to completion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 19:04:37 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 04 Aug 2012 17:04:37 +0000 Subject: [issue15556] os.stat fails for file pending delete on Windows In-Reply-To: <1344096463.0.0.611888237472.issue15556@psf.upfronthosting.co.za> Message-ID: <1344099877.59.0.971712173699.issue15556@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 19:10:46 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 04 Aug 2012 17:10:46 +0000 Subject: [issue15550] Trailing white spaces In-Reply-To: <1344008415.84.0.0454996292543.issue15550@psf.upfronthosting.co.za> Message-ID: <1344100246.54.0.711268061169.issue15550@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > There already is a hook in place for the main python.org repository that checks for and rejects changesets that include files with space issues: If there is already a hook, then why do some files have spurious white space (i.e. at the end of a line)? Is that because those issues were present prior to putting the hook in place? ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 19:45:29 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 04 Aug 2012 17:45:29 +0000 Subject: [issue15544] math.isnan fails with some Decimal NaNs In-Reply-To: <1343962443.78.0.878505736017.issue15544@psf.upfronthosting.co.za> Message-ID: <1344102329.03.0.136141685812.issue15544@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Why not add a is_nan() method to float numbers instead? That could work. The duplication of float.is_nan and math.isnan (not to mention the different spellings) would be a bit ugly, but perhaps worth it. It would make sense to add float.is_infinite and (possibly) float.is_finite methods at the same time. Looks like we've got two separate issues here, that should probably be split into two separate bug reports. The first issue is that Decimal.__float__ is brain-dead when it comes to NaNs with payloads; I consider that a clear bug, and Steven's patch fixes it nicely for the Python version of decimal. The second has to do with finding a nice type-agnostic way of determing whether something is a NaN---anyone mind if I open a separate issue for this? W.r.t. the first issue: Steven, thanks for the patch; looks fine to me at first glance. Two questions: (1) What would you think about raising ValueError explicitly for the signaling NaN case rather than falling back to the ValueError coming from the string-to-float conversion. I think the intentions of the code would be a little clearer that way; and we get to choose a more informative error message that way, too. (2) Should we apply the fix to 2.7 and/or 3.2 as well? I'll look at extending Steven's fix to the cdecimal code, unless Stefan really wants to do it (which would be fine with me :-). ---------- assignee: -> mark.dickinson versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 19:52:58 2012 From: report at bugs.python.org (Anton Barkovsky) Date: Sat, 04 Aug 2012 17:52:58 +0000 Subject: [issue15557] Tests for webbrowser module Message-ID: <1344102778.31.0.864118033074.issue15557@psf.upfronthosting.co.za> New submission from Anton Barkovsky: Attaching a patch with some tests for webbrowser module. The tests fail unless #15509 is fixed. They also print lots of warnings unless #15447 is fixed. ---------- components: Tests files: test_webbrowser.patch keywords: patch messages: 167423 nosy: anton.barkovsky, r.david.murray priority: normal severity: normal status: open title: Tests for webbrowser module versions: Python 3.3 Added file: http://bugs.python.org/file26688/test_webbrowser.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 19:54:41 2012 From: report at bugs.python.org (Anton Barkovsky) Date: Sat, 04 Aug 2012 17:54:41 +0000 Subject: [issue15447] A file is not properly closed by webbrowser._invoke In-Reply-To: <1343222113.7.0.837887359823.issue15447@psf.upfronthosting.co.za> Message-ID: <1344102881.2.0.41474150212.issue15447@psf.upfronthosting.co.za> Anton Barkovsky added the comment: Added tests in #15557. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 19:55:06 2012 From: report at bugs.python.org (Anton Barkovsky) Date: Sat, 04 Aug 2012 17:55:06 +0000 Subject: [issue15509] webbrowser.open sometimes passes zero-length argument to the browser. In-Reply-To: <1343687718.2.0.882765777761.issue15509@psf.upfronthosting.co.za> Message-ID: <1344102906.9.0.942524965497.issue15509@psf.upfronthosting.co.za> Anton Barkovsky added the comment: Added tests in #15557. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 20:45:49 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Aug 2012 18:45:49 +0000 Subject: [issue13052] IDLE: replace ending with '\' causes crash In-Reply-To: <1317177843.04.0.691154940707.issue13052@psf.upfronthosting.co.za> Message-ID: <3WqDbG0G24zPkW@mail.python.org> Roundup Robot added the comment: New changeset 0f38948cc6df by Andrew Svetlov in branch '3.2': Issue #13052: Fix IDLE crashing when replace string in Search/Replace dialog ended with '\'. http://hg.python.org/cpython/rev/0f38948cc6df New changeset 9dcfba4d0357 by Andrew Svetlov in branch 'default': Issue #13052: Fix IDLE crashing when replace string in Search/Replace dialog ended with '\'. http://hg.python.org/cpython/rev/9dcfba4d0357 New changeset 44c00de723b3 by Andrew Svetlov in branch '2.7': Issue #13052: Fix IDLE crashing when replace string in Search/Replace dialog ended with '\'. http://hg.python.org/cpython/rev/44c00de723b3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 20:48:06 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Sat, 04 Aug 2012 18:48:06 +0000 Subject: [issue13052] IDLE: replace ending with '\' causes crash In-Reply-To: <1317177843.04.0.691154940707.issue13052@psf.upfronthosting.co.za> Message-ID: <1344106086.18.0.873162606899.issue13052@psf.upfronthosting.co.za> Andrew Svetlov added the comment: While there are no unittests for Roger's patch I have pushed it in after strong manual testing as important enough. Thanks, Roger. ---------- resolution: -> fixed stage: test needed -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 20:52:19 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 04 Aug 2012 18:52:19 +0000 Subject: [issue15544] math.isnan fails with some Decimal NaNs In-Reply-To: <1344102329.03.0.136141685812.issue15544@psf.upfronthosting.co.za> Message-ID: <20120804185218.GA18594@sleipnir.bytereef.org> Stefan Krah added the comment: Mark Dickinson wrote: > Looks like we've got two separate issues here, that should probably be > split into two separate bug reports. The first issue is that > Decimal.__float__ is brain-dead when it comes to NaNs with payloads; > I consider that a clear bug, and Steven's patch fixes it nicely for > the Python version of decimal. If we are viewing the whole issue in terms of decimal -> float conversion, I'm not so sure anymore: Not all Decimal payloads have a meaning for floats (and payloads get lost in the conversion). On the other hand it doesn't matter since I doubt anyone is using payloads. :) > The second has to do with finding a nice type-agnostic way of determing > whether something is a NaN---anyone mind if I open a separate issue for this? Yes, that should probably be another issue. > Two questions: (1) What would you think about raising ValueError explicitly > for the signaling NaN case rather than falling back to the ValueError coming > from the string-to-float conversion. If we use your latest rationale for raising in case of Decimal('snan').__float__(), I think that indeed __float__() should raise like Decimal.to_integral() does for example. If we are aiming for sNaN support in floats in the long term and at some point allow carrying over sNaNs from decimal to float, then perhaps the error message could say that sNaN conversion is currently not supported. > (2) Should we apply the fix to 2.7 and/or 3.2 as well? Yes, I think so. > I'll look at extending Steven's fix to the cdecimal code, unless Stefan > really wants to do it (which would be fine with me :-). Please go ahead! For this year, I've seen more than enough of _decimal.c already. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 21:01:45 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Aug 2012 19:01:45 +0000 Subject: [issue12655] Expose sched.h functions In-Reply-To: <1311959395.98.0.305576868025.issue12655@psf.upfronthosting.co.za> Message-ID: <3WqDxg6B9kzPk6@mail.python.org> Roundup Robot added the comment: New changeset fb975cb8fb45 by Victor Stinner in branch 'default': Issue #12655: Mention multiprocessing.cpu_count() in os.sched_getaffinity() doc http://hg.python.org/cpython/rev/fb975cb8fb45 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 21:14:55 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 Aug 2012 19:14:55 +0000 Subject: [issue15550] Trailing white spaces In-Reply-To: <1344008415.84.0.0454996292543.issue15550@psf.upfronthosting.co.za> Message-ID: <1344107695.09.0.0984311682985.issue15550@psf.upfronthosting.co.za> Antoine Pitrou added the comment: AFAIR the hook only applies to Python and reST files, not C files. I think Georg wrote it, perhaps he knows the reasons. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 21:24:10 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 04 Aug 2012 19:24:10 +0000 Subject: [issue15492] textwrap.wrap expand_tabs does not behave as expected In-Reply-To: <1343596317.09.0.0346303694102.issue15492@psf.upfronthosting.co.za> Message-ID: <1344108250.89.0.530285350095.issue15492@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 21:24:31 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Sat, 04 Aug 2012 19:24:31 +0000 Subject: [issue15528] Better support for finalization with weakrefs In-Reply-To: <1343837927.06.0.561023898829.issue15528@psf.upfronthosting.co.za> Message-ID: <1344108271.0.0.326102479203.issue15528@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > I don't quite understand the purpose of your suggestions. What can you do > with it help, what you can not do with contextlib.ExitStack, atexit, > __del__ method, weakref.WeakKeyDictionary or weakref.ref? I read the > documentation, but the meaning eludes me. finalize does not "compete" with contextlib.ExitStack, atexit and weakref.WeakKeyDictionary. It only competes with __del__ and weakref callbacks. Points 1 and 2 in my first message are the main points. Also, read the warning at http://docs.python.org/py3k/reference/datamodel.html#object.__del__ which also applies to weakref callbacks. Other problems with __del__: * Ref cycles which contain an object with a __del__ method are immortal * __del__ methods can "ressurect" the object. There was actually a proposal to remove or replace __del__ methods in Python 3000. See the "Removing __del__" thread(s): http://mail.python.org/pipermail/python-3000/2006-September/thread.html#3797 As for weakref callbacks, I think they are just too difficult to use correctly unless you are very familiar with them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 21:28:23 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 04 Aug 2012 19:28:23 +0000 Subject: [issue13498] os.makedirs exist_ok documentation is incorrect, as is some of the behavior In-Reply-To: <1322574123.12.0.756700598965.issue13498@psf.upfronthosting.co.za> Message-ID: <1344108503.77.0.969247417693.issue13498@psf.upfronthosting.co.za> R. David Murray added the comment: I *want* it to be the default, since I think that is the typical use case, but the existing default behavior means that such a backward incompatible change would not be acceptable for exactly the reason you state. So yes, I want it as a new flag. ("exist_really_ok", he says with tongue in cheek.) I haven't given much thought to the API, but perhaps there could be a value for the umask that means "don't care"? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 21:35:29 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Aug 2012 19:35:29 +0000 Subject: [issue15550] Trailing white spaces In-Reply-To: <1344024975.95.0.173827371264.issue15550@psf.upfronthosting.co.za> Message-ID: <201208042235.11296.storchaka@gmail.com> Serhiy Storchaka added the comment: > There already is a hook in place for the main python.org repository that > checks for and rejects changesets that include files with space issues: Now I understand why there is no problem with .py files. But there are a lot of other files (including .c and .h) with trailing whitespaces. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 21:43:30 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 04 Aug 2012 19:43:30 +0000 Subject: [issue15550] Trailing white spaces In-Reply-To: <1344008415.84.0.0454996292543.issue15550@psf.upfronthosting.co.za> Message-ID: <1344109410.31.0.488104868364.issue15550@psf.upfronthosting.co.za> Georg Brandl added the comment: Well, I'm -0 on extending the hook to C files. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 21:50:13 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 04 Aug 2012 19:50:13 +0000 Subject: [issue15510] textwrap.wrap('') returns empty list In-Reply-To: <1343697979.41.0.629576632811.issue15510@psf.upfronthosting.co.za> Message-ID: <1344109813.49.0.389242355348.issue15510@psf.upfronthosting.co.za> R. David Murray added the comment: FTR I agree with Antoine that returning the empty list is the more logical behavior here. Wrap is turning a string into a list of lines...if there is no content, the list of lines *should* be empty, IMO. That is what I would expect, so for me the empty list follows the principle of least surprise here. Consider, for example, the fact that [] is False, while [''] is True. I consider that definitive in favor of returning an empty list when there is no content to wrap, even ignoring the backward compatibility issue. The issue of preserving whitespace-only is fuzzier, but given that it is fuzzy I also am inclined to leave the current behavior alone (and document it properly). As Antoine said, there is no point in preserving whitespace unless it is preserving indentation, and if there is nothing but whitespace there is nothing to be indented. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 21:51:09 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 04 Aug 2012 19:51:09 +0000 Subject: [issue1859] textwrap doesn't linebreak on "\n" In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za> Message-ID: <1344109869.53.0.270998806381.issue1859@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 22:13:04 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 04 Aug 2012 20:13:04 +0000 Subject: [issue15500] Python should support naming threads In-Reply-To: <1343650770.87.0.181202709436.issue15500@psf.upfronthosting.co.za> Message-ID: <1344111184.59.0.508641260632.issue15500@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 22:17:39 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 04 Aug 2012 20:17:39 +0000 Subject: [issue14330] don't use host python, use host search paths for host compiler In-Reply-To: <1331856850.28.0.590122825265.issue14330@psf.upfronthosting.co.za> Message-ID: <1344111459.65.0.484806840282.issue14330@psf.upfronthosting.co.za> Georg Brandl added the comment: Matthias: ping. I don't want to hold up beta2 indefinitely. In order to resolve this blocker, we will revert the batch of cross-compiling patches in a few days if there is no progress here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 22:32:21 2012 From: report at bugs.python.org (Florent Xicluna) Date: Sat, 04 Aug 2012 20:32:21 +0000 Subject: [issue15500] Python should support naming threads In-Reply-To: <1343650770.87.0.181202709436.issue15500@psf.upfronthosting.co.za> Message-ID: <1344112341.95.0.139449338673.issue15500@psf.upfronthosting.co.za> Changes by Florent Xicluna : ---------- nosy: +flox _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 22:36:08 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Aug 2012 20:36:08 +0000 Subject: [issue15528] Better support for finalization with weakrefs In-Reply-To: <1344108271.0.0.326102479203.issue15528@psf.upfronthosting.co.za> Message-ID: <201208042335.53774.storchaka@gmail.com> Serhiy Storchaka added the comment: > finalize does not "compete" with contextlib.ExitStack, atexit and > weakref.WeakKeyDictionary. It only competes with __del__ and weakref > callbacks. What kind of problems you solve with __del__ and weakref callbacks? For most of them contextlib.ExitStack and atexit are safer and better fit. > Points 1 and 2 in my first message are the main points. Also, read the > warning at For point 1: global weakref.WeakKeyDictionary is good store for weak refs with callbacks. global weakdict weakdict[kenny] = weakref.ref(kenny, lambda _: print("you killed kenny!")) If you do not want to work at a low level, in most cases fit the above- mentioned high-level tools. For point 2 Antoine has noted that it is a known issue and there is a solution (issue812369). > http://docs.python.org/py3k/reference/datamodel.html#object.__del__ > > which also applies to weakref callbacks. Is this your point 2? > Other problems with __del__: > > * Ref cycles which contain an object with a __del__ method are immortal It is use case for weakrefs which break reference loops. > * __del__ methods can "ressurect" the object. What you are meaning? Relying on GC is dangerous thing for resource releasing. And it even more dangerous for alternative implementations without reference counting. That is why in recent times in Python there has been a tendency to RAII strategy (context managers). Can you give examples, where the use of finalize necessary or more convenient the other ways? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 22:49:51 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Aug 2012 20:49:51 +0000 Subject: [issue15550] Trailing white spaces In-Reply-To: <1344008415.84.0.0454996292543.issue15550@psf.upfronthosting.co.za> Message-ID: <1344113391.26.0.140392970821.issue15550@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I found a few files where trailing spaces are significant (patches, RTF, test data). Excluding them and three generated file (Unicode data, generating scripts should be smarter), I divided the remaining into several parts: 1) the libffi library; 2) the libmpdec library; 3) other C?sources; 4) the rest of the files (mainly readme-like files and build scripts). ---------- keywords: +patch Added file: http://bugs.python.org/file26689/libffi_trailing_whitespaces.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 22:50:56 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Aug 2012 20:50:56 +0000 Subject: [issue15550] Trailing white spaces In-Reply-To: <1344008415.84.0.0454996292543.issue15550@psf.upfronthosting.co.za> Message-ID: <1344113456.55.0.703090342262.issue15550@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file26690/libmpdec_trailing_whitespaces.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 22:51:52 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Aug 2012 20:51:52 +0000 Subject: [issue15550] Trailing white spaces In-Reply-To: <1344008415.84.0.0454996292543.issue15550@psf.upfronthosting.co.za> Message-ID: <1344113512.86.0.178357327086.issue15550@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file26691/c_trailing_whitespaces.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 22:54:07 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Aug 2012 20:54:07 +0000 Subject: [issue15550] Trailing white spaces In-Reply-To: <1344008415.84.0.0454996292543.issue15550@psf.upfronthosting.co.za> Message-ID: <1344113647.64.0.268996982725.issue15550@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file26692/other_trailing_whitespaces.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 22:56:34 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 04 Aug 2012 20:56:34 +0000 Subject: [issue15531] os.path symlink docs missing In-Reply-To: <1343847603.27.0.526292718618.issue15531@psf.upfronthosting.co.za> Message-ID: <1344113794.75.0.924029348999.issue15531@psf.upfronthosting.co.za> R. David Murray added the comment: The first of those acts as I would expect: os.path.realpath is operating only on the path, so if the last element is a symbolic link it doesn't have any reason to look for the target of that link. The second one does seem less intuitive. I'm not sure the first case is worth a patch...I'd have to see a suggested wording. The second probably is, assuming it is not in fact a bug. ---------- nosy: +larry, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 22:59:41 2012 From: report at bugs.python.org (Ned Deily) Date: Sat, 04 Aug 2012 20:59:41 +0000 Subject: [issue15550] Trailing white spaces In-Reply-To: <1344008415.84.0.0454996292543.issue15550@psf.upfronthosting.co.za> Message-ID: <1344113981.13.0.300966244375.issue15550@psf.upfronthosting.co.za> Ned Deily added the comment: -1 for making wholesale whitespace changes. It potentially makes merging harder for little benefit. Imported files from other projects should definitely not be touched. IMO, the only thing potentially worth considering is extending the existing hook to C files. I'm +0 on that myself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 23:07:14 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 04 Aug 2012 21:07:14 +0000 Subject: [issue15536] re.split doesn't respect MULTILINE In-Reply-To: <1343918479.14.0.936812287244.issue15536@psf.upfronthosting.co.za> Message-ID: <1344114434.56.0.257117391924.issue15536@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> MULTILINE confuses re.split _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 23:15:54 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Sat, 04 Aug 2012 21:15:54 +0000 Subject: [issue15496] harden directory removal for tests on Windows In-Reply-To: <1343614495.69.0.283818579392.issue15496@psf.upfronthosting.co.za> Message-ID: <1344114954.21.0.172323952284.issue15496@psf.upfronthosting.co.za> Jeremy Kloth added the comment: I've updated the comment in the patch to reflect Martin's concern. Martin is partially correct in that the handle opened in the stat() call will not prolong the pending status. It is due to the fact that it does not open the handle with any sharing mode set, thus effectively blocking any other process from grabbing another handle to the file while the stat function has its handle open. ---------- Added file: http://bugs.python.org/file26693/support.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 23:26:12 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 04 Aug 2012 21:26:12 +0000 Subject: [issue15539] Fixing Tools/scripts/pindent.py In-Reply-To: <1343924676.33.0.76595941249.issue15539@psf.upfronthosting.co.za> Message-ID: <1344115572.45.0.871316066126.issue15539@psf.upfronthosting.co.za> R. David Murray added the comment: There is now a test_tools, so it would be great to have tests to go along with this patch. I haven't looked at the patch in detail, but as long as you are modernizing it please kill those "# end ..." lines. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 23:28:53 2012 From: report at bugs.python.org (=?utf-8?q?Juancarlo_A=C3=B1ez?=) Date: Sat, 04 Aug 2012 21:28:53 +0000 Subject: [issue15558] webbrowser output to console Message-ID: <1344115733.09.0.946491153947.issue15558@psf.upfronthosting.co.za> New submission from Juancarlo A?ez: Under Ubuntu Linux 11.10 and 12.04, webbroser.open() will output the following message to the console: Created new window in existing browser session. The behavior is both unexpected and troublesome. ---------- components: Library (Lib) messages: 167443 nosy: apalala priority: normal severity: normal status: open title: webbrowser output to console type: behavior versions: Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 23:35:56 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 04 Aug 2012 21:35:56 +0000 Subject: [issue15550] Trailing white spaces In-Reply-To: <1344008415.84.0.0454996292543.issue15550@psf.upfronthosting.co.za> Message-ID: <1344116156.49.0.0122644714077.issue15550@psf.upfronthosting.co.za> Stefan Krah added the comment: I'm not against whitespace cleanup every now and then, but also -0 on a hook for C files. I think that (for C) the annoyance of having a patch rejected because of trailing whitespace outweighs the overall benefit. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 23:44:03 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 04 Aug 2012 21:44:03 +0000 Subject: [issue15541] logging.exception doesn't accept 'extra' In-Reply-To: <1343944333.27.0.175563876294.issue15541@psf.upfronthosting.co.za> Message-ID: <1344116643.75.0.575503809118.issue15541@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 23:47:39 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Sat, 04 Aug 2012 21:47:39 +0000 Subject: [issue15496] harden directory removal for tests on Windows In-Reply-To: <1344114954.21.0.172323952284.issue15496@psf.upfronthosting.co.za> Message-ID: Jeremy Kloth added the comment: With the latest changes, is there anything left preventing the inclusion of this patch? Without some change, the Win64 buildbot is relatively irrelevant as it is nearly always in a state of failure due to these errors. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 23:53:50 2012 From: report at bugs.python.org (Brian Curtin) Date: Sat, 04 Aug 2012 21:53:50 +0000 Subject: [issue15496] harden directory removal for tests on Windows In-Reply-To: <1343614495.69.0.283818579392.issue15496@psf.upfronthosting.co.za> Message-ID: <1344117230.12.0.92847947444.issue15496@psf.upfronthosting.co.za> Brian Curtin added the comment: > Without some change, the Win64 buildbot is relatively irrelevant as it is nearly always in a state of failure due to these errors. Not that some change isn't necessary, but what else are you running on your build slave? I ran a Windows 2008 R2 x64 slave for some time and it never had issues around file/directory removal. I only had to decommission it because the physical machine became unreliable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 23:54:39 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 04 Aug 2012 21:54:39 +0000 Subject: [issue15551] Unit tests that return generators silently fail In-Reply-To: <1344017298.6.0.769704462398.issue15551@psf.upfronthosting.co.za> Message-ID: <1344117279.58.0.680475433791.issue15551@psf.upfronthosting.co.za> R. David Murray added the comment: This is not something that is specific to unittest. In Python, if you call a generator function *it returns a generator-iterator*. Unless you *do* something with the the iterator, nothing else happens. This is true in *any* python code. Unittest calls whatever test method you define, and handles (reports) the exceptions that result from that call. That's the fundamental design of unittest. Your generator test method does not raise any exceptions when called, therefore the test passed. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 4 23:58:19 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Sat, 04 Aug 2012 21:58:19 +0000 Subject: [issue15496] harden directory removal for tests on Windows In-Reply-To: <1344117230.12.0.92847947444.issue15496@psf.upfronthosting.co.za> Message-ID: Jeremy Kloth added the comment: > Not that some change isn't necessary, but what else are you running on your build slave? I ran a Windows 2008 R2 x64 slave for some time and it never had issues around file/directory removal. I only had to decommission it because the physical machine became unreliable. The errors only started happening after upgrading the HD from a PATA Ultra133 to an SATA3 SSD. The super-fast HD is allowing for these timing errors to show through. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 00:11:14 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 Aug 2012 22:11:14 +0000 Subject: [issue13119] Newline for print() is \n on Windows, and not \r\n as expected In-Reply-To: <1317934788.08.0.425265217585.issue13119@psf.upfronthosting.co.za> Message-ID: <1344118274.79.0.153576263795.issue13119@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Windows buildbots now show failures in the test suite. ---------- status: closed -> open versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 00:13:55 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 04 Aug 2012 22:13:55 +0000 Subject: [issue15554] correct and clarify str.splitlines() documentation In-Reply-To: <1344047978.01.0.683229635888.issue15554@psf.upfronthosting.co.za> Message-ID: <1344118435.76.0.441695334299.issue15554@psf.upfronthosting.co.za> R. David Murray added the comment: Sigh. ;) At this point in my Python programming I intuitively understand what splitlines does, but every time we try to explain it in detail it gets messier and messier. I wasn't really happy with the addition of that sentence about split in the first place. I don't understand what your splitlines examples are trying to say, they all look clear to me based on the fact that we are splitting *lines*. I don't find your proposed language in the patch to be clearer. The existing sentence describes the concrete behavior, while your version is sort-of describing (ascribing?) some syntax to the line separators ("does not delimit"). The problem is that there *is* a syntax here, that of universal-newline-delimited-text, but that is too big a topic to explain in the splitlines doc. There's another issue for creating a central description of universal-newline parsing, perhaps this entry could link to that discussion (and that discussion could perhaps mention splitlines). The split behavior without a specified separator might actually be a bug (if so, it is not a fixable one), but in any case you are right that that clarification should be added if the existing sentence is kept. ---------- nosy: +ncoghlan, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 00:26:51 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 04 Aug 2012 22:26:51 +0000 Subject: [issue15555] Default newlines of io.TextIOWrapper In-Reply-To: <1344095998.81.0.573935781933.issue15555@psf.upfronthosting.co.za> Message-ID: <1344119211.02.0.225221175362.issue15555@psf.upfronthosting.co.za> R. David Murray added the comment: And that is the value of os.linesep at Python startup. I'm don't think that we really support the mutability of os.linesep, we just don't bother to make it immutable. I'm not sure how this would be documented, since code that does use "os.linesep" is indeed affected by changing it. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 00:29:45 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Aug 2012 22:29:45 +0000 Subject: [issue13119] Newline for print() is \n on Windows, and not \r\n as expected In-Reply-To: <1317934788.08.0.425265217585.issue13119@psf.upfronthosting.co.za> Message-ID: <3WqKYf3lDKzPkm@mail.python.org> Roundup Robot added the comment: New changeset 4efad7fba42a by Antoine Pitrou in branch '3.2': Fix test_sys under Windows (issue #13119) http://hg.python.org/cpython/rev/4efad7fba42a New changeset e4a87f0253e9 by Antoine Pitrou in branch 'default': Merge universal newlines-related fixes (issue #13119) http://hg.python.org/cpython/rev/e4a87f0253e9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 00:31:55 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 04 Aug 2012 22:31:55 +0000 Subject: [issue15558] webbrowser output to console In-Reply-To: <1344115733.09.0.946491153947.issue15558@psf.upfronthosting.co.za> Message-ID: <1344119515.46.0.818703245808.issue15558@psf.upfronthosting.co.za> R. David Murray added the comment: This message does not come from the Python webbrowser module. You should report this upstream to the bug tracker for your browser. ---------- nosy: +r.david.murray resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 00:35:53 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Aug 2012 22:35:53 +0000 Subject: [issue13119] Newline for print() is \n on Windows, and not \r\n as expected In-Reply-To: <1317934788.08.0.425265217585.issue13119@psf.upfronthosting.co.za> Message-ID: <3WqKhm0QLgzPkm@mail.python.org> Roundup Robot added the comment: New changeset f8e435d6a801 by Antoine Pitrou in branch 'default': Fix test_venv to work with universal newlines (issue #13119) http://hg.python.org/cpython/rev/f8e435d6a801 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 00:38:05 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 Aug 2012 22:38:05 +0000 Subject: [issue13837] test_shutil fails with symlinks enabled under Windows In-Reply-To: <1327255807.39.0.63998442373.issue13837@psf.upfronthosting.co.za> Message-ID: <1344119884.93.0.627347622211.issue13837@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ping? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 00:43:33 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Aug 2012 22:43:33 +0000 Subject: [issue15541] logging.exception doesn't accept 'extra' In-Reply-To: <1343944333.27.0.175563876294.issue15541@psf.upfronthosting.co.za> Message-ID: <3WqKsb3C31zPkm@mail.python.org> Roundup Robot added the comment: New changeset 322da186cced by Vinay Sajip in branch '2.7': Issue #15541: Correct anomaly in logging.exception. Thanks to Ned Batchelder for the report. http://hg.python.org/cpython/rev/322da186cced ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 00:44:18 2012 From: report at bugs.python.org (Vinay Sajip) Date: Sat, 04 Aug 2012 22:44:18 +0000 Subject: [issue15541] logging.exception doesn't accept 'extra' In-Reply-To: <1343944333.27.0.175563876294.issue15541@psf.upfronthosting.co.za> Message-ID: <1344120258.13.0.462201965981.issue15541@psf.upfronthosting.co.za> Changes by Vinay Sajip : ---------- assignee: -> vinay.sajip resolution: -> fixed status: open -> closed versions: -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 00:46:33 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 Aug 2012 22:46:33 +0000 Subject: [issue13119] Newline for print() is \n on Windows, and not \r\n as expected In-Reply-To: <1317934788.08.0.425265217585.issue13119@psf.upfronthosting.co.za> Message-ID: <1344120393.54.0.520911232292.issue13119@psf.upfronthosting.co.za> Antoine Pitrou added the comment: test_httpservers still fails, it's the CGI tests... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 00:58:30 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Sat, 04 Aug 2012 22:58:30 +0000 Subject: [issue15528] Better support for finalization with weakrefs In-Reply-To: <1343837927.06.0.561023898829.issue15528@psf.upfronthosting.co.za> Message-ID: <1344121110.68.0.487857273177.issue15528@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > For point 1: global weakref.WeakKeyDictionary is good store for weak refs with > callbacks. > > global weakdict > weakdict[kenny] = weakref.ref(kenny, lambda _: print("you killed kenny!")) That depends on kenny being hashable. It also surprises me a bit that it works. It seems to depend on unguaranteed implementation details: PyObject_ClearWeakRefs() copies all weakrefs with callbacks to a tuple before invoking callbacks. If this were not the case then I think the weakref you created (which is scheduled to fire second) would be garbage collected before its callback could be invoked. I think users should have a documented way to schedule callbacks without having to explicitly save the weakref. > For point 2 Antoine has noted that it is a known issue and there is a solution > (issue812369). That has been languishing for 9 years. I would not hold your breath. > > http://docs.python.org/py3k/reference/datamodel.html#object.__del__ > > > > which also applies to weakref callbacks. > > Is this your point 2? Yes. > Relying on GC is dangerous thing for resource releasing. And it even more > dangerous for alternative implementations without reference counting. That is > why in recent times in Python there has been a tendency to RAII strategy > (context managers). I agree that explicit clean up using context managers to be strongly encouraged. But resources should still be released if the object is garbage collected. Or do you think that file objects should stop bothering to close their fds when they are deallocated? > Can you give examples, where the use of finalize necessary or more convenient > the other ways? multiprocessing (which I orginally wrote) makes extensive use of finalizers, (although with a different implementation and api). In some cases that is because at the time I wanted to support versions of Python which did not have the with statement. But there are various things there that depend on finalizers, and on being able to guarantee that they get called on exit (in a predictable order). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 01:25:29 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 Aug 2012 23:25:29 +0000 Subject: [issue15500] Python should support naming threads In-Reply-To: <1343650770.87.0.181202709436.issue15500@psf.upfronthosting.co.za> Message-ID: <1344122729.11.0.46340072039.issue15500@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I don't think this should be done by default as it will break people's expectations and, perhaps worse, compatibility. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 01:41:43 2012 From: report at bugs.python.org (Atsuo Ishimoto) Date: Sat, 04 Aug 2012 23:41:43 +0000 Subject: [issue13119] Newline for print() is \n on Windows, and not \r\n as expected In-Reply-To: <1317934788.08.0.425265217585.issue13119@psf.upfronthosting.co.za> Message-ID: <1344123703.22.0.456496547387.issue13119@psf.upfronthosting.co.za> Atsuo Ishimoto added the comment: Fix for test_httpservers ---------- Added file: http://bugs.python.org/file26694/issue13119_httpserver.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 02:19:51 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Aug 2012 00:19:51 +0000 Subject: [issue15546] Iteration breaks with bz2.open(filename,'rt') In-Reply-To: <1343984674.35.0.733492369263.issue15546@psf.upfronthosting.co.za> Message-ID: <3WqN0P5TSfzPl1@mail.python.org> Roundup Robot added the comment: New changeset 5284e65e865b by Nadeem Vawda in branch 'default': #15546: Fix {GzipFile,LZMAFile}.read1()'s handling of pathological input data. http://hg.python.org/cpython/rev/5284e65e865b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 02:28:18 2012 From: report at bugs.python.org (Nadeem Vawda) Date: Sun, 05 Aug 2012 00:28:18 +0000 Subject: [issue15546] Iteration breaks with bz2.open(filename,'rt') In-Reply-To: <1343984674.35.0.733492369263.issue15546@psf.upfronthosting.co.za> Message-ID: <1344126498.45.0.596413875671.issue15546@psf.upfronthosting.co.za> Nadeem Vawda added the comment: Done. Thanks for the bug report, David. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 02:36:24 2012 From: report at bugs.python.org (Larry Hastings) Date: Sun, 05 Aug 2012 00:36:24 +0000 Subject: [issue15531] os.path symlink docs missing In-Reply-To: <1343847603.27.0.526292718618.issue15531@psf.upfronthosting.co.za> Message-ID: <1344126984.43.0.669327729097.issue15531@psf.upfronthosting.co.za> Larry Hastings added the comment: I just tried it, and os.readlink('/tmp/broken-symlink') worked fine. What OS are you using? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 02:37:29 2012 From: report at bugs.python.org (Larry Hastings) Date: Sun, 05 Aug 2012 00:37:29 +0000 Subject: [issue15548] Mention all new os functions in What's New in Python 3.3 In-Reply-To: <1343996760.47.0.232563077305.issue15548@psf.upfronthosting.co.za> Message-ID: <1344127049.52.0.57729767268.issue15548@psf.upfronthosting.co.za> Larry Hastings added the comment: ftruncate isn't new. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 02:40:50 2012 From: report at bugs.python.org (Atsuo Ishimoto) Date: Sun, 05 Aug 2012 00:40:50 +0000 Subject: [issue13119] Newline for print() is \n on Windows, and not \r\n as expected In-Reply-To: <1317934788.08.0.425265217585.issue13119@psf.upfronthosting.co.za> Message-ID: <1344127250.91.0.9112254105.issue13119@psf.upfronthosting.co.za> Atsuo Ishimoto added the comment: Sorry, please ignore the patch 'issue13119_httpserver.patch' I posted above. Behavior of "-u" commandline option in Python3.3 is differ than in Python 2. We should not convert newline characters if "-u" specified? I'll investigate more. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 02:42:34 2012 From: report at bugs.python.org (Dave Abrahams) Date: Sun, 05 Aug 2012 00:42:34 +0000 Subject: [issue15531] os.path symlink docs missing In-Reply-To: <1343847603.27.0.526292718618.issue15531@psf.upfronthosting.co.za> Message-ID: <1344127354.58.0.204479632401.issue15531@psf.upfronthosting.co.za> Dave Abrahams added the comment: MacOS 10.7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 02:54:38 2012 From: report at bugs.python.org (Larry Hastings) Date: Sun, 05 Aug 2012 00:54:38 +0000 Subject: [issue15531] os.path symlink docs missing In-Reply-To: <1343847603.27.0.526292718618.issue15531@psf.upfronthosting.co.za> Message-ID: <1344128078.61.0.74577298399.issue15531@psf.upfronthosting.co.za> Larry Hastings added the comment: What does the following script print out? import os os.chdir('/tmp') os.symlink('--success--', 'foo') print("this should print --success-- :") print(os.readlink('foo')) os.unlink('foo') ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 03:02:02 2012 From: report at bugs.python.org (Atsuo Ishimoto) Date: Sun, 05 Aug 2012 01:02:02 +0000 Subject: [issue13119] Newline for print() is \n on Windows, and not \r\n as expected In-Reply-To: <1317934788.08.0.425265217585.issue13119@psf.upfronthosting.co.za> Message-ID: <1344128522.01.0.605110065416.issue13119@psf.upfronthosting.co.za> Atsuo Ishimoto added the comment: We should not convert \n with -u command line option or PYTHONUNBUFFERED was set. Added a patch to fix error in test_httpservers. ---------- Added file: http://bugs.python.org/file26695/issue13119_unbuffered.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 03:02:58 2012 From: report at bugs.python.org (Steven D'Aprano) Date: Sun, 05 Aug 2012 01:02:58 +0000 Subject: [issue15544] math.isnan fails with some Decimal NaNs In-Reply-To: <1344102329.03.0.136141685812.issue15544@psf.upfronthosting.co.za> Message-ID: <501DC636.9020400@pearwood.info> Steven D'Aprano added the comment: On 05/08/12 03:45, Mark Dickinson wrote: > It would make sense to add float.is_infinite and (possibly) float.is_finite > methods at the same time. If you don't add is_finite, you know someone is going to express surprise that it wasn't already done. Just as happened with math.isfinite :) http://bugs.python.org/issue9165#msg109326 > The second has to do with finding a nice > type-agnostic way of determing whether something is a NaN---anyone mind if > I open a separate issue for this? Please do. > Two questions: (1) What would you think about raising ValueError > explicitly for the signaling NaN case [...] (2) Should we apply > the fix to 2.7 and/or 3.2 as well? Agree to both. I think this counts as a bug report and not a new feature. > I'll look at extending Steven's fix to the cdecimal code Thank you :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 08:20:08 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Aug 2012 06:20:08 +0000 Subject: [issue15546] Iteration breaks with bz2.open(filename,'rt') In-Reply-To: <1343984674.35.0.733492369263.issue15546@psf.upfronthosting.co.za> Message-ID: <1344147608.65.0.589722106765.issue15546@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What about peek()? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 09:08:26 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Aug 2012 07:08:26 +0000 Subject: [issue15539] Fixing Tools/scripts/pindent.py In-Reply-To: <1343924676.33.0.76595941249.issue15539@psf.upfronthosting.co.za> Message-ID: <1344150506.13.0.52096722411.issue15539@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > 5. Fixed one type in help message. Typo. Should be "Fixed one typo in help message." Patch updated, unused experimental variable removed. ---------- Added file: http://bugs.python.org/file26696/pindent.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 09:09:03 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Aug 2012 07:09:03 +0000 Subject: [issue15539] Fixing Tools/scripts/pindent.py In-Reply-To: <1343924676.33.0.76595941249.issue15539@psf.upfronthosting.co.za> Message-ID: <1344150543.77.0.502412803515.issue15539@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file26665/pindent.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 09:29:39 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Aug 2012 07:29:39 +0000 Subject: [issue15539] Fixing Tools/scripts/pindent.py In-Reply-To: <1343924676.33.0.76595941249.issue15539@psf.upfronthosting.co.za> Message-ID: <1344151779.07.0.803511548529.issue15539@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > There is now a test_tools, so it would be great to have tests to go along with this patch. Well, I'll do it. But the tests most likely will be different for different versions of Python (in contrast to the pindent patch). "pindent -d" and then "pindent -c" on pindent.py must give the original of pindent.py. It exposes some of the above mentioned bugs. > I haven't looked at the patch in detail, but as long as you are modernizing it please kill those "# end ..." lines. This is done deliberately. It demonstrates the purpose of the script. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 09:45:13 2012 From: report at bugs.python.org (Brian Thorne) Date: Sun, 05 Aug 2012 07:45:13 +0000 Subject: [issue12428] functools test coverage In-Reply-To: <1309255638.21.0.342456839611.issue12428@psf.upfronthosting.co.za> Message-ID: <1344152713.39.0.104286338523.issue12428@psf.upfronthosting.co.za> Brian Thorne added the comment: Back to a simpler closure implementation of partial and skip the repr test for python implementation. ---------- Added file: http://bugs.python.org/file26697/functools.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 10:03:13 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 05 Aug 2012 08:03:13 +0000 Subject: [issue15559] Bad interaction between ipaddress addresses and the bytes constructor Message-ID: <1344153793.69.0.927408739195.issue15559@psf.upfronthosting.co.za> New submission from Nick Coghlan: I've been tinkering with the ipaddress module as I review Eli's documentation and have uncovered a *very* nasty interaction between ipaddress objects and the bytes constructor. Specifically, if you pass an integer to bytes() it will attempt to allocate and zero-initialise a buffer of that size. It uses operator.index() to check for integers. This creates a problem, because ipaddress objects currently implement __index__ so they can be treated as integers without an explicit cast. This does very bad things if, say, you do "bytes(ipaddress.IPv4Address('192.168.0.1'))" If I remove the __index__ implementation, then you can't call hex() directly on ipaddress objects anymore - you have to call hex(int(addr)) instead. I'm a *lot* happier with that approach, and will be implementing it in a moment. ---------- messages: 167474 nosy: georg.brandl, ncoghlan, pmoody priority: release blocker severity: normal status: open title: Bad interaction between ipaddress addresses and the bytes constructor type: crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 10:20:36 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Aug 2012 08:20:36 +0000 Subject: [issue15559] Bad interaction between ipaddress addresses and the bytes constructor In-Reply-To: <1344153793.69.0.927408739195.issue15559@psf.upfronthosting.co.za> Message-ID: <3WqZgQ67MczPkY@mail.python.org> Roundup Robot added the comment: New changeset 5abea8a43f19 by Nick Coghlan in branch 'default': Close #15559: Implementing __index__ creates a nasty interaction with the bytes constructor. At least for 3.3, ipaddress objects must now be explicitly converted with int() and thus can't be passed directly to the hex() builtin. http://hg.python.org/cpython/rev/5abea8a43f19 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 10:38:02 2012 From: report at bugs.python.org (Florent Xicluna) Date: Sun, 05 Aug 2012 08:38:02 +0000 Subject: [issue1553375] Add traceback.print_full_exception() Message-ID: <1344155882.15.0.9505173427.issue1553375@psf.upfronthosting.co.za> Florent Xicluna added the comment: Changeset ba014543ed2c (3.2a4) references this issue. ---------- nosy: +flox _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 10:41:42 2012 From: report at bugs.python.org (Florent Xicluna) Date: Sun, 05 Aug 2012 08:41:42 +0000 Subject: [issue15541] logging.exception doesn't accept 'extra' In-Reply-To: <1343944333.27.0.175563876294.issue15541@psf.upfronthosting.co.za> Message-ID: <1344156102.28.0.284276082584.issue15541@psf.upfronthosting.co.za> Florent Xicluna added the comment: Python 3.2 was already fixed with changeset ba014543ed2c. It would be nice to have some tests, though. ---------- nosy: +flox _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 11:03:38 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 05 Aug 2012 09:03:38 +0000 Subject: [issue15560] _sqlite3.so is built with wrong include file on OS X when using an SDK Message-ID: <1344157418.55.0.45856897604.issue15560@psf.upfronthosting.co.za> New submission from Ned Deily: setup.py supports building Python with an OS X SDK to allow building Python executables and libraries that will run on multiple versions of OS X. There is an error in the SDK support code in detect_modules() for building the _sqlite3 extension that has the effect of incorrectly using header files for libsqlite3 from the build system's installed /usr/include rather than the selected SDK's usr/include. Depending on which SDK version and which OS X version of the build system, the effects of this bug can range from a few compile warning messages (and possible subtle execution errors) to a catastrophic build failure of the _sqlite3 extension. The attached patches fix the problem. One consequence of fixing the bug is that it is more important than ever to supply a local newer version of libsqlite3 if building with the obsolete MacOSX10.4u.sdk since the version of libsqlite3 in 10.4 is 3.1.3 and there are several conditional tests in the _sqlite modules to work around bugs and missing features for versions that old, tests that were previously incorrectly checking the system libsqlite3 version. (By contrast, the version of libsqlite3 in MacOSX10.5.sdk is 3.4.0, old but usable; 10.6 has 3.6.12). ---------- assignee: ned.deily components: Build, Macintosh messages: 167478 nosy: ned.deily priority: high severity: normal stage: patch review status: open title: _sqlite3.so is built with wrong include file on OS X when using an SDK versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 11:08:31 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 05 Aug 2012 09:08:31 +0000 Subject: [issue15560] _sqlite3.so is built with wrong include file on OS X when using an SDK In-Reply-To: <1344157418.55.0.45856897604.issue15560@psf.upfronthosting.co.za> Message-ID: <1344157711.3.0.938780302246.issue15560@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- keywords: +patch Added file: http://bugs.python.org/file26698/issue15560_sqlite3_sdk.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 11:08:50 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 05 Aug 2012 09:08:50 +0000 Subject: [issue15560] _sqlite3.so is built with wrong include file on OS X when using an SDK In-Reply-To: <1344157418.55.0.45856897604.issue15560@psf.upfronthosting.co.za> Message-ID: <1344157730.32.0.991191531845.issue15560@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- stage: patch review -> commit review Added file: http://bugs.python.org/file26699/issue15560_sqlite3_sdk_27_32.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 12:26:05 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 05 Aug 2012 10:26:05 +0000 Subject: [issue13119] Newline for print() is \n on Windows, and not \r\n as expected In-Reply-To: <1344128522.01.0.605110065416.issue13119@psf.upfronthosting.co.za> Message-ID: <1344162209.3488.0.camel@localhost.localdomain> Antoine Pitrou added the comment: > We should not convert \n with -u command line option or PYTHONUNBUFFERED was set. Why that? What do universal newlines have to do with buffering? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 12:31:46 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Aug 2012 10:31:46 +0000 Subject: [issue15077] Regexp match goes into infinite loop In-Reply-To: <1339756870.03.0.464046287951.issue15077@psf.upfronthosting.co.za> Message-ID: <1344162706.67.0.625503828152.issue15077@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 12:35:38 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Aug 2012 10:35:38 +0000 Subject: [issue15239] Abandoned Tools/unicode/mkstringprep.py In-Reply-To: <1341164174.42.0.994750295138.issue15239@psf.upfronthosting.co.za> Message-ID: <1344162938.9.0.765399812849.issue15239@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +needs review -patch priority: normal -> low stage: -> patch review type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 12:37:03 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Aug 2012 10:37:03 +0000 Subject: [issue15239] Abandoned Tools/unicode/mkstringprep.py In-Reply-To: <1341164174.42.0.994750295138.issue15239@psf.upfronthosting.co.za> Message-ID: <1344163023.33.0.552897393851.issue15239@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 12:39:17 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Aug 2012 10:39:17 +0000 Subject: [issue15144] Possible integer overflow in operations with addresses and sizes. In-Reply-To: <1340395368.97.0.504662983992.issue15144@psf.upfronthosting.co.za> Message-ID: <1344163157.09.0.55548125404.issue15144@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: >?Ah; were the strict aliasing problems already there before the patch? I didn't check. Please open separate issue for this. ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 12:40:15 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Aug 2012 10:40:15 +0000 Subject: [issue15144] Possible integer overflow in operations with addresses and sizes. In-Reply-To: <1340395368.97.0.504662983992.issue15144@psf.upfronthosting.co.za> Message-ID: <1344163215.42.0.887432941004.issue15144@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +needs review priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 12:43:37 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Aug 2012 10:43:37 +0000 Subject: [issue15202] followlinks/follow_symlinks/symlinks flags unification In-Reply-To: <1340787578.87.0.498110156216.issue15202@psf.upfronthosting.co.za> Message-ID: <1344163417.47.0.985210755813.issue15202@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 12:44:37 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 05 Aug 2012 10:44:37 +0000 Subject: [issue13119] Newline for print() is \n on Windows, and not \r\n as expected In-Reply-To: <1317934788.08.0.425265217585.issue13119@psf.upfronthosting.co.za> Message-ID: <1344163477.2.0.770708346681.issue13119@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I wonder why this is a release blocker. It's a bug in Python 3.2, so why should it block the release of 3.3 (it's not a regression). If no complete solution is coming up, I recommend to revert all changes on this issue, and reconsider after the 3.3 release. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 12:46:03 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Aug 2012 10:46:03 +0000 Subject: [issue15378] Underported Tools/unicode/comparecodecs.py In-Reply-To: <1342512913.96.0.0337741529294.issue15378@psf.upfronthosting.co.za> Message-ID: <1344163563.8.0.837648095429.issue15378@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +needs review priority: normal -> low stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 12:47:33 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Aug 2012 10:47:33 +0000 Subject: [issue15379] Charmap decoding of no-BMP characters In-Reply-To: <1342512958.35.0.341191772548.issue15379@psf.upfronthosting.co.za> Message-ID: <1344163652.99.0.739606198872.issue15379@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +needs review priority: normal -> low stage: patch review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 12:48:52 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Aug 2012 10:48:52 +0000 Subject: [issue15379] Charmap decoding of no-BMP characters In-Reply-To: <1342512958.35.0.341191772548.issue15379@psf.upfronthosting.co.za> Message-ID: <1344163732.44.0.408396746464.issue15379@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 12:49:10 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 05 Aug 2012 10:49:10 +0000 Subject: [issue13119] Newline for print() is \n on Windows, and not \r\n as expected In-Reply-To: <1344163477.2.0.770708346681.issue13119@psf.upfronthosting.co.za> Message-ID: <1344163593.3488.2.camel@localhost.localdomain> Antoine Pitrou added the comment: > I wonder why this is a release blocker. It's a bug in Python 3.2, so > why should it block the release of 3.3 (it's not a regression). It's a blocker because the fix broke a couple of tests. And it's also a regression from 3.1 and 2.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 12:52:11 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 05 Aug 2012 10:52:11 +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: <1344163931.02.0.147882978972.issue15216@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I fail to see why this is a release blocker; no rationale is given in the original message, nor in the quoted message. So unblocking. ---------- nosy: +loewis priority: release blocker -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 12:58:09 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Aug 2012 10:58:09 +0000 Subject: [issue15475] Correct __sizeof__ support for itertools In-Reply-To: <1343418242.58.0.256146467281.issue15475@psf.upfronthosting.co.za> Message-ID: <1344164289.19.0.608741858677.issue15475@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +needs review stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 12:58:47 2012 From: report at bugs.python.org (Brian Thorne) Date: Sun, 05 Aug 2012 10:58:47 +0000 Subject: [issue4508] distutils compiler not handling spaces in path to output/src files In-Reply-To: <1228341537.43.0.522254260997.issue4508@psf.upfronthosting.co.za> Message-ID: <1344164327.39.0.187481612786.issue4508@psf.upfronthosting.co.za> Brian Thorne added the comment: I've put together a patch adding the test requested. There is no problem on my Ubuntu machine with python 3.3. There is a comment in the file saying Don't load the xx module more than once, I am unsure whether my patch (using a renamed c file) violates this? One extremely minor nitpick that I'll mention is inconsistency with spaces in the module name. One can create a python file "my file.py" and can import it with __import__("my file"). I couldn't do the same for a C extension. Building a C extension with distutils: module_name = 'ex ample' example_ext = Extension(module_name, [target_c]) dist = Distribution({'name': module_name, 'ext_modules': [example_ext]}) Doesn't work due to the import mechanism looks for a PyInit function with the new module name (including a space): ImportError: dynamic module does not define init function (PyInit_ex ample) I don't think this is worth making a ticket over. ---------- Added file: http://bugs.python.org/file26700/distutils_space_test.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 13:01:52 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Aug 2012 11:01:52 +0000 Subject: [issue15490] Correct __sizeof__ support for StringIO In-Reply-To: <1343591617.54.0.289047671129.issue15490@psf.upfronthosting.co.za> Message-ID: <1344164512.64.0.170736529424.issue15490@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 13:02:30 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Aug 2012 11:02:30 +0000 Subject: [issue15513] Correct __sizeof__ support for pickle In-Reply-To: <1343723739.69.0.648602242607.issue15513@psf.upfronthosting.co.za> Message-ID: <1344164550.22.0.553213550978.issue15513@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 13:03:29 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 05 Aug 2012 11:03:29 +0000 Subject: [issue13119] Newline for print() is \n on Windows, and not \r\n as expected In-Reply-To: <1344163593.3488.2.camel@localhost.localdomain> Message-ID: <20120805130327.Horde.uw4uRLuWis5QHlL-fx52hTA@webmail.df.eu> Martin v. L?wis added the comment: > It's a blocker because the fix broke a couple of tests. That cannot possibly be the explanation why haypo declared it a blocker on 2012-08-01; the fix was only applied on 2012-08-04. But I agree that it should block the release now; hence I propose to roll back the entire set of changes and revert to the 3.2 state. > And it's also a regression from 3.1 and 2.7. Since 3.2 was released with this behavior, this bug cannot manage to block 3.3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 13:03:49 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Aug 2012 11:03:49 +0000 Subject: [issue15539] Fixing Tools/scripts/pindent.py In-Reply-To: <1343924676.33.0.76595941249.issue15539@psf.upfronthosting.co.za> Message-ID: <1344164629.52.0.506414423934.issue15539@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +needs review priority: normal -> low stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 13:14:07 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Aug 2012 11:14:07 +0000 Subject: [issue4997] xml.sax.saxutils.XMLGenerator should write to io.RawIOBase. In-Reply-To: <1232361357.86.0.976302026477.issue4997@psf.upfronthosting.co.za> Message-ID: <1344165247.42.0.626156422129.issue4997@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> duplicate superseder: -> Bugfix for #1470540 (XMLGenerator cannot output UTF-16) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 13:16:14 2012 From: report at bugs.python.org (Atsuo Ishimoto) Date: Sun, 05 Aug 2012 11:16:14 +0000 Subject: [issue13119] Newline for print() is \n on Windows, and not \r\n as expected In-Reply-To: <1317934788.08.0.425265217585.issue13119@psf.upfronthosting.co.za> Message-ID: <1344165374.18.0.96449761285.issue13119@psf.upfronthosting.co.za> Atsuo Ishimoto added the comment: Antoine Pitrou added the comment: > >> We should not convert \n with -u command line option or PYTHONUNBUFFERED was set. > > Why that? What do universal newlines have to do with buffering? Man page of Python says -u Force stdin, stdout and stderr to be totally unbuffered. On systems where it matters, also put stdin, stdout and stderr in binary mode. test_httpservers depends on this behavior, but was implemented as documented in Python 3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 13:16:30 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Aug 2012 11:16:30 +0000 Subject: [issue15381] Optimize BytesIO to so less reallocations when written, similarly to StringIO In-Reply-To: <1342527166.53.0.694574948468.issue15381@psf.upfronthosting.co.za> Message-ID: <1344165390.52.0.642131017148.issue15381@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 13:19:31 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Aug 2012 11:19:31 +0000 Subject: [issue15424] __sizeof__ of array should include size of items In-Reply-To: <1342974161.65.0.374402048104.issue15424@psf.upfronthosting.co.za> Message-ID: <1344165571.03.0.208165501228.issue15424@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ludwig, you can use some helpers from test.support (see issue15467) for __sizeof__?testing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 13:20:39 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Aug 2012 11:20:39 +0000 Subject: [issue15522] impove 27 percent performance on stringpbject.c( by prefetch and loop optimization) In-Reply-To: <1343813632.92.0.115452555082.issue15522@psf.upfronthosting.co.za> Message-ID: <1344165639.88.0.00546830658458.issue15522@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 13:21:18 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 05 Aug 2012 11:21:18 +0000 Subject: [issue13119] Newline for print() is \n on Windows, and not \r\n as expected In-Reply-To: <1344165374.18.0.96449761285.issue13119@psf.upfronthosting.co.za> Message-ID: <1344165522.3488.5.camel@localhost.localdomain> Antoine Pitrou added the comment: > Man page of Python says > > -u Force stdin, stdout and stderr to be totally unbuffered. On > systems where it matters, also put stdin, stdout and stderr in > binary mode. I don't know which version it is, but current 3.3 says: ?Force the binary I/O layers of stdin, stdout and stderr to be unbuffered. The text I/O layer will still be line-buffered.? > test_httpservers depends on this behavior, but was implemented as > documented in Python 3. I would argue that test_httpservers is wrong, since it uses print() in a CGI script where sys.stdout.buffer.write() should really be used. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 13:28:46 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sun, 05 Aug 2012 11:28:46 +0000 Subject: [issue13498] os.makedirs exist_ok documentation is incorrect, as is some of the behavior In-Reply-To: <1344108503.77.0.969247417693.issue13498@psf.upfronthosting.co.za> Message-ID: Hynek Schlawack added the comment: How about something along of: new arg on_wrong_perm= 1. WRONG_PERM_IGNORE 2. WRONG_PERM_FAIL 3. callable that gets called with the directory name and maybe the existing perms to save stat call_ ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 14:02:28 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Aug 2012 12:02:28 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <3WqgbR3B00zPb1@mail.python.org> Roundup Robot added the comment: New changeset b513ad06d1fa by Nick Coghlan in branch 'default': Issue 14814: Docs work showed some more cases of networks pretending to be addresses and highlighted the weird approach to implementing the 'is_whatever' properties. Impl now illustrates far more clearly that networks have a property if both their network and broadcast addresses have that property http://hg.python.org/cpython/rev/b513ad06d1fa ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 14:07:22 2012 From: report at bugs.python.org (Eli Bendersky) Date: Sun, 05 Aug 2012 12:07:22 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <1344168442.14.0.665536026771.issue14814@psf.upfronthosting.co.za> Eli Bendersky added the comment: Nick, your commit incorporates my latest patch (ipaddr_refdoc_network.2.patch), right? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 14:11:01 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 05 Aug 2012 12:11:01 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <1344168661.95.0.632461351394.issue14814@psf.upfronthosting.co.za> Nick Coghlan added the comment: It actually wasn't meant to, as I only meant to commit the code changes (I was still working on the docs, using your patch as a starting point). However, it makes more sense to just finish my changes and commit them rather than reverting anything. (Good attempt by the way, but it was your 'networks have all the attributes of addresses' that got me digging deeper, since that isn't meant to be true any more) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 14:11:35 2012 From: report at bugs.python.org (Nadeem Vawda) Date: Sun, 05 Aug 2012 12:11:35 +0000 Subject: [issue15546] Iteration breaks with bz2.open(filename,'rt') In-Reply-To: <1343984674.35.0.733492369263.issue15546@psf.upfronthosting.co.za> Message-ID: <1344168695.15.0.281133921723.issue15546@psf.upfronthosting.co.za> Nadeem Vawda added the comment: Before these fixes, it looks like all three classes' peek() methods were susceptible to the same problem as read1(). The fixes for BZ2File.read1() and LZMAFile.read1() should have fixed peek() as well; both methods are implemented in terms of _fill_buffer(). For GzipFile, peek() is still potentially broken - I'll push a fix shortly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 14:32:48 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Aug 2012 12:32:48 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <3WqhGR0HLJzPm2@mail.python.org> Roundup Robot added the comment: New changeset cf8d42596a44 by Nick Coghlan in branch 'default': Issue #14814: Finish review of ipaddress network object docs (initial patch was by Eli Bendersky) http://hg.python.org/cpython/rev/cf8d42596a44 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 14:45:33 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Aug 2012 12:45:33 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <3WqhY76FX6zPkS@mail.python.org> Roundup Robot added the comment: New changeset cf9526db1a7e by Nick Coghlan in branch 'default': Issue #14814: Remove redundant property from interface objects - prefixlen can be accessed via the associated network object http://hg.python.org/cpython/rev/cf9526db1a7e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 14:46:00 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 05 Aug 2012 12:46:00 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <1344170760.55.0.00030350587064.issue14814@psf.upfronthosting.co.za> Nick Coghlan added the comment: I'm still not overjoyed with the "this isn't documented here, go read it over there" situation. However, duplicating the text everywhere isn't ideal either. So, let's finish it up with my current approach: explicitly listing the methods and attributes on each class where the documentation is elsewhere. For Interface objects, there's no need to repeat the documentation for the corresponding Address object, since there's a real inheritance relationship there. Fortunately, that makes the list of attributes still to be documented fairly short: ip (raw address with no network info) network (the network definition) with_prefixlen with_hostmask with_netmask ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 14:48:09 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Aug 2012 12:48:09 +0000 Subject: [issue15546] Iteration breaks with bz2.open(filename,'rt') In-Reply-To: <1343984674.35.0.733492369263.issue15546@psf.upfronthosting.co.za> Message-ID: <3Wqhc80ZP8zPb1@mail.python.org> Roundup Robot added the comment: New changeset 8c07ff7f882f by Nadeem Vawda in branch 'default': #15546: Also fix GzipFile.peek(). http://hg.python.org/cpython/rev/8c07ff7f882f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 14:52:48 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Aug 2012 12:52:48 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <3WqhjW3z7SzPk7@mail.python.org> Roundup Robot added the comment: New changeset abbae7314b52 by Nick Coghlan in branch 'default': Issue #14814: Attempt to clarify network address and broadcast address for less experienced users http://hg.python.org/cpython/rev/abbae7314b52 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 14:56:33 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Aug 2012 12:56:33 +0000 Subject: [issue13119] Newline for print() is \n on Windows, and not \r\n as expected In-Reply-To: <1317934788.08.0.425265217585.issue13119@psf.upfronthosting.co.za> Message-ID: <3Wqhnr0jTQzPl8@mail.python.org> Roundup Robot added the comment: New changeset bc4fdb758b8c by Antoine Pitrou in branch '3.2': Fix CGI tests to take into account the platform's line ending (issue #13119) http://hg.python.org/cpython/rev/bc4fdb758b8c New changeset ee185c6b2880 by Antoine Pitrou in branch 'default': Fix CGI tests to take into account the platform's line ending (issue #13119) http://hg.python.org/cpython/rev/ee185c6b2880 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 15:22:34 2012 From: report at bugs.python.org (STINNER Victor) Date: Sun, 05 Aug 2012 13:22:34 +0000 Subject: [issue13119] Newline for print() is \n on Windows, and not \r\n as expected In-Reply-To: <1317934788.08.0.425265217585.issue13119@psf.upfronthosting.co.za> Message-ID: <1344172954.92.0.959286561932.issue13119@psf.upfronthosting.co.za> STINNER Victor added the comment: Buildbots are happy, the issue can be closed again. Thanks Antoine. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 15:27:45 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Aug 2012 13:27:45 +0000 Subject: [issue15546] Iteration breaks with bz2.open(filename,'rt') In-Reply-To: <1343984674.35.0.733492369263.issue15546@psf.upfronthosting.co.za> Message-ID: <1344173265.91.0.445935735726.issue15546@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I have a doubts. Is it not a dead cycle if the end of the compressed data will happen on the end of reading block? Maybe instead of "while self.extrasize <= 0:" worth to write "while self.extrasize <= 0 and self.fileobj is not None:"? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 15:28:06 2012 From: report at bugs.python.org (Atsuo Ishimoto) Date: Sun, 05 Aug 2012 13:28:06 +0000 Subject: [issue13119] Newline for print() is \n on Windows, and not \r\n as expected In-Reply-To: <1317934788.08.0.425265217585.issue13119@psf.upfronthosting.co.za> Message-ID: <1344173286.5.0.9786875361.issue13119@psf.upfronthosting.co.za> Atsuo Ishimoto added the comment: > I don't know which version it is, but current 3.3 says: Ah, sorry, I thought I was reading latest Man page. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 15:55:05 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Sun, 05 Aug 2012 13:55:05 +0000 Subject: [issue15528] Better support for finalization with weakrefs In-Reply-To: <1343837927.06.0.561023898829.issue15528@psf.upfronthosting.co.za> Message-ID: <1344174905.57.0.124221419648.issue15528@psf.upfronthosting.co.za> Richard Oudkerk added the comment: Updated patch. get() and put() replaced by peek() and detach(). Added isalive(). Now finalizer class has no state, i.e. __slots__ == (). ---------- Added file: http://bugs.python.org/file26701/finalize.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 16:00:46 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Aug 2012 14:00:46 +0000 Subject: [issue15548] Mention all new os functions in What's New in Python 3.3 In-Reply-To: <1343996760.47.0.232563077305.issue15548@psf.upfronthosting.co.za> Message-ID: <3WqkCx3S8fzPl8@mail.python.org> Roundup Robot added the comment: New changeset b7b8e4ada3e5 by Victor Stinner in branch 'default': Issue #15548: Update and complete What's New in Python 3.3, especially the "os" section http://hg.python.org/cpython/rev/b7b8e4ada3e5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 16:25:57 2012 From: report at bugs.python.org (Nadeem Vawda) Date: Sun, 05 Aug 2012 14:25:57 +0000 Subject: [issue15546] Iteration breaks with bz2.open(filename,'rt') In-Reply-To: <1343984674.35.0.733492369263.issue15546@psf.upfronthosting.co.za> Message-ID: <1344176757.43.0.477499461508.issue15546@psf.upfronthosting.co.za> Nadeem Vawda added the comment: No, if _read() is called once the file is already at EOF, it raises an EOFError (http://hg.python.org/cpython/file/8c07ff7f882f/Lib/gzip.py#l433), which will then break out of the loop. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 18:16:58 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 05 Aug 2012 16:16:58 +0000 Subject: [issue15492] textwrap.wrap expand_tabs does not behave as expected In-Reply-To: <1343596317.09.0.0346303694102.issue15492@psf.upfronthosting.co.za> Message-ID: <1344183418.54.0.590765907042.issue15492@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I didn't have a chance to respond before you closed this issue. I will add more information later if that is okay. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 19:03:17 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 05 Aug 2012 17:03:17 +0000 Subject: [issue15528] Better support for finalization with weakrefs In-Reply-To: <1343837927.06.0.561023898829.issue15528@psf.upfronthosting.co.za> Message-ID: <1344186197.65.0.534268597108.issue15528@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I don't understand why you have two names: finalize and Finalizer. Let's keep only one of them. isalive() could be a read-only property named "alive" instead. In _make_callback, I still think the default error reporting mechanism should be kept. It can be improved separately. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 19:32:17 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 05 Aug 2012 17:32:17 +0000 Subject: [issue15554] correct and clarify str.splitlines() documentation In-Reply-To: <1344047978.01.0.683229635888.issue15554@psf.upfronthosting.co.za> Message-ID: <1344187937.0.0.747301031876.issue15554@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > I wasn't really happy with the addition of that sentence about split in the first place. I think the instinct to put that sentence in there is a good one. It is a key, perhaps subtle difference. > I don't understand what your splitlines examples are trying to say, they all look clear to me based on the fact that we are splitting *lines*. I perhaps included too many examples and so clouded my point. :) I just needed one. The examples were simply to show why the existing language is not correct. The current language says, "if the string ends with line boundary characters the returned list does not have an empty last element." However, the examples are of strings that do end with line boundary characters but that *do* have an empty last element. The point is that splitlines() does not count a terminal line break as an additional line, while split('\n') (for example) does. But this is different from whether the returned list *has* an empty last element, which is what the current language says. The returned list can have empty last elements because of line breaks at the end. It's just that the one at the *very* end doesn't count towards that -- unlike the case for split(): >>> 'a'.splitlines() ['a'] >>> 'a\n'.splitlines() ['a'] >>> 'a\n\n'.splitlines() ['a', ''] >>> 'a\n\n\n'.splitlines() ['a', '', ''] >>> 'a\n\n\n'.split('\n') # counts terminal line break as an extra line ['a', '', '', ''] I'm open to improving the language. Maybe "does not count a terminal line break as an additional line" instead of the original "a terminal line break does not delimit an additional empty line"? > There's another issue for creating a central description of universal-newline parsing, perhaps this entry could link to that discussion (and that discussion could perhaps mention splitlines). I created that issue (issue 15543), and a patch is in the works along the lines you suggest. ;) > The split behavior without a specified separator might actually be a bug (if so, it is not a fixable one), but in any case you are right that that clarification should be added if the existing sentence is kept. Perhaps, but at least split() documents the behavior. :) "runs of consecutive whitespace are regarded as a single separator, and the result will contain no empty strings at the start or end if the string has leading or trailing whitespace." (from http://docs.python.org/dev/library/stdtypes.html#str.split ) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 20:20:25 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 05 Aug 2012 18:20:25 +0000 Subject: [issue15554] correct and clarify str.splitlines() documentation In-Reply-To: <1344047978.01.0.683229635888.issue15554@psf.upfronthosting.co.za> Message-ID: <1344190825.91.0.45065510021.issue15554@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Attaching patch with simplified wording in response to R. David Murray's feedback. In particular, "a terminal line break does not delimit an additional empty line" -> "a terminal line break does not result in an extra line." ---------- Added file: http://bugs.python.org/file26702/issue-15554-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 21:02:57 2012 From: report at bugs.python.org (Dave Abrahams) Date: Sun, 05 Aug 2012 19:02:57 +0000 Subject: [issue15531] os.path symlink docs missing In-Reply-To: <1344128078.61.0.74577298399.issue15531@psf.upfronthosting.co.za> (Larry Hastings's message of "Sun, 05 Aug 2012 00:54:38 +0000") Message-ID: Dave Abrahams added the comment: on Sat Aug 04 2012, Larry Hastings wrote: > Larry Hastings added the comment: > > What does the following script print out? > > import os > > os.chdir('/tmp') > os.symlink('--success--', 'foo') > print("this should print --success-- :") > print(os.readlink('foo')) > os.unlink('foo') --8<---------------cut here---------------start------------->8--- this should print --success-- : --success-- --8<---------------cut here---------------end--------------->8--- So, I guess I don't know what was causing the symptom I observed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 21:10:52 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 05 Aug 2012 19:10:52 +0000 Subject: [issue15163] pydoc displays __loader__ as module data In-Reply-To: <1340546990.34.0.0743968242792.issue15163@psf.upfronthosting.co.za> Message-ID: <1344193852.0.0.691508948896.issue15163@psf.upfronthosting.co.za> Brett Cannon added the comment: Can you still not commit this patch, Eric? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 21:51:57 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 05 Aug 2012 19:51:57 +0000 Subject: [issue15561] update subprocess docs to reference io.TextIOWrapper Message-ID: <1344196317.87.0.366111796882.issue15561@psf.upfronthosting.co.za> New submission from Chris Jerdonek: This is an issue to update the subprocess module documentation after updates to io.TextIOWrapper's documentation here: http://hg.python.org/cpython/rev/f17a1410ebe5 This issue was discussed briefly on python-dev: http://mail.python.org/pipermail/python-dev/2012-August/121239.html Patch attached. ---------- assignee: docs at python components: Documentation files: issue-subprocess-docs-1.patch keywords: easy, patch messages: 167512 nosy: cjerdonek, docs at python, haypo priority: normal severity: normal stage: patch review status: open title: update subprocess docs to reference io.TextIOWrapper versions: Python 3.3 Added file: http://bugs.python.org/file26703/issue-subprocess-docs-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 23:19:07 2012 From: report at bugs.python.org (Larry Hastings) Date: Sun, 05 Aug 2012 21:19:07 +0000 Subject: [issue15531] os.path symlink docs missing In-Reply-To: <1343847603.27.0.526292718618.issue15531@psf.upfronthosting.co.za> Message-ID: <1344201547.89.0.88068300658.issue15531@psf.upfronthosting.co.za> Larry Hastings added the comment: Since everything is working fine, and the documentation arguably needs no update, I'm closing this. ---------- resolution: -> works for me stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 23:30:13 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 05 Aug 2012 21:30:13 +0000 Subject: [issue15239] Abandoned Tools/unicode/mkstringprep.py In-Reply-To: <1341164174.42.0.994750295138.issue15239@psf.upfronthosting.co.za> Message-ID: <1344202213.05.0.0766052710198.issue15239@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The difference is in the reverse direction, right? I.e. the special case for U+0130 is removed. This is harmless: it just means that we don't need to special-case that anymore. I'm puzzled though that b3_exceptions doesn't become empty in 3.3. Supposedly, B.3 is CaseFolding.txt, and supposedly, Python 3.3 supports CaseFolding.txt. For example, CaseFolding maps U+00B5 to U+03BC in lower case, yet Python 3.3 maps it to U+00B5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 23:39:36 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 05 Aug 2012 21:39:36 +0000 Subject: [issue15562] CaseFolding not working properly Message-ID: <1344202776.28.0.0609772465169.issue15562@psf.upfronthosting.co.za> New submission from Martin v. L?wis: IIUC, Python 3.3 is intended to support CaseFolding.txt. In http://unicode.org/Public/UNIDATA/CaseFolding.txt U+00B5 maps to U+03BC. However, in 3.3.0b1 (80a1ae3a1b39), ascii('\u00b5'.lower()) gives '\xb5'. ---------- messages: 167515 nosy: benjamin.peterson, loewis priority: normal severity: normal status: open title: CaseFolding not working properly versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 23:56:09 2012 From: report at bugs.python.org (Florent Xicluna) Date: Sun, 05 Aug 2012 21:56:09 +0000 Subject: [issue15562] CaseFolding not working properly In-Reply-To: <1344202776.28.0.0609772465169.issue15562@psf.upfronthosting.co.za> Message-ID: <1344203769.33.0.191212734122.issue15562@psf.upfronthosting.co.za> Changes by Florent Xicluna : ---------- nosy: +flox _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 23:57:44 2012 From: report at bugs.python.org (STINNER Victor) Date: Sun, 05 Aug 2012 21:57:44 +0000 Subject: [issue15562] CaseFolding not working properly In-Reply-To: <1344202776.28.0.0609772465169.issue15562@psf.upfronthosting.co.za> Message-ID: <1344203864.44.0.781518741896.issue15562@psf.upfronthosting.co.za> STINNER Victor added the comment: Hum, strange. $ ./python Python 3.3.0b1 (default:b7b8e4ada3e5+, Aug 5 2012, 16:19:18) [GCC 4.6.3 20120306 (Red Hat 4.6.3-2)] on linux >>> print(ascii('\xb5'.casefold())) '\u03bc' ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 23:58:44 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 05 Aug 2012 21:58:44 +0000 Subject: [issue15562] CaseFolding not working properly In-Reply-To: <1344202776.28.0.0609772465169.issue15562@psf.upfronthosting.co.za> Message-ID: <1344203924.78.0.949175401137.issue15562@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Naturally, you have to use casefold(): >>> hex(ord("\u00b5".casefold())) '0x3bc' ---------- resolution: -> invalid status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 5 23:59:08 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 05 Aug 2012 21:59:08 +0000 Subject: [issue15562] CaseFolding not working properly In-Reply-To: <1344202776.28.0.0609772465169.issue15562@psf.upfronthosting.co.za> Message-ID: <1344203948.19.0.541360311204.issue15562@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 00:00:34 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 05 Aug 2012 22:00:34 +0000 Subject: [issue15562] CaseFolding not working properly In-Reply-To: <1344202776.28.0.0609772465169.issue15562@psf.upfronthosting.co.za> Message-ID: <1344204034.42.0.910910033377.issue15562@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Yes, the documentation for str.casefold() suggests that lower() is not meant to casefold: "For example, the German lowercase letter '?' is equivalent to "ss". Since it is already lowercase, lower() would do nothing to '?'; casefold() converts it to "ss"." http://docs.python.org/dev/library/stdtypes.html#str.casefold ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 00:17:38 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Aug 2012 22:17:38 +0000 Subject: [issue15560] _sqlite3.so is built with wrong include file on OS X when using an SDK In-Reply-To: <1344157418.55.0.45856897604.issue15560@psf.upfronthosting.co.za> Message-ID: <3WqxFF243HzPhm@mail.python.org> Roundup Robot added the comment: New changeset ef6c6d8adcf5 by Ned Deily in branch '2.7': Issue #15560: Fix building _sqlite3 extension on OS X with an SDK. http://hg.python.org/cpython/rev/ef6c6d8adcf5 New changeset ee0ac9a0461f by Ned Deily in branch '3.2': Issue #15560: Fix building _sqlite3 extension on OS X with an SDK. http://hg.python.org/cpython/rev/ee0ac9a0461f New changeset d706a6f4724c by Ned Deily in branch 'default': Issue #15560: null merge http://hg.python.org/cpython/rev/d706a6f4724c New changeset 6af33673e955 by Ned Deily in branch 'default': Issue #15560: Fix building _sqlite3 extension on OS X with an SDK. http://hg.python.org/cpython/rev/6af33673e955 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 00:54:31 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Aug 2012 22:54:31 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1317341390.65.0.255779328054.issue13072@psf.upfronthosting.co.za> Message-ID: <3Wqy3n12j8zPc0@mail.python.org> Roundup Robot added the comment: New changeset 95da47ddebe0 by Victor Stinner in branch 'default': Close #13072: Restore code before the PEP 393 for the array module http://hg.python.org/cpython/rev/95da47ddebe0 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 01:05:31 2012 From: report at bugs.python.org (STINNER Victor) Date: Sun, 05 Aug 2012 23:05:31 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1317341390.65.0.255779328054.issue13072@psf.upfronthosting.co.za> Message-ID: <1344207931.04.0.860966956645.issue13072@psf.upfronthosting.co.za> STINNER Victor added the comment: Oops, the initial issue is not solved. Attached fixes the array == memoryview issue by using a valid format for the buffer. ---------- resolution: fixed -> status: closed -> open Added file: http://bugs.python.org/file26704/array_unicode_format.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 01:07:25 2012 From: report at bugs.python.org (STINNER Victor) Date: Sun, 05 Aug 2012 23:07:25 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1317341390.65.0.255779328054.issue13072@psf.upfronthosting.co.za> Message-ID: <1344208045.68.0.689539402599.issue13072@psf.upfronthosting.co.za> STINNER Victor added the comment: Hum, this issue is a regression from Python 3.2. I would like to see it fixed in Python 3.3. Example: Python 3.2.3+ (3.2:243ad1a6f638+, Aug 4 2012, 01:36:41) [GCC 4.6.3 20120306 (Red Hat 4.6.3-2)] on linux2 >>> import array >>> a=array.array('u', 'xyz') >>> b=memoryview(a) >>> a == b True >>> b == a True ---------- priority: normal -> release blocker versions: -Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 01:50:18 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 05 Aug 2012 23:50:18 +0000 Subject: [issue15471] importlib's __import__() argument style nit In-Reply-To: <1343408977.86.0.620892563203.issue15471@psf.upfronthosting.co.za> Message-ID: <1344210618.04.0.133809026711.issue15471@psf.upfronthosting.co.za> Brett Cannon added the comment: Attached is a patch that drops all mutable default arguments to __import__() and updates the docs. I went with Barry's approach but made it compatible with PEP 8 (bad, FLUFL; no unneeded parens!). I also ignored the locals argument since __import__ doesn't even use it. Assigning to Georg as a release blocker to make a call as to whether I can apply this to 3.3 of if I need to wait until 3.4 since this is not a critical fix but a good thing to do. Just assign back to me once the decision has been made. ---------- assignee: brett.cannon -> georg.brandl nosy: +georg.brandl priority: low -> release blocker stage: patch review -> commit review Added file: http://bugs.python.org/file26705/immutable_defaults_for_import.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 01:51:26 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 05 Aug 2012 23:51:26 +0000 Subject: [issue15560] _sqlite3.so is built with wrong include file on OS X when using an SDK In-Reply-To: <1344157418.55.0.45856897604.issue15560@psf.upfronthosting.co.za> Message-ID: <1344210686.22.0.0142758438845.issue15560@psf.upfronthosting.co.za> Ned Deily added the comment: Committed for release in 2.7.4, 3.2.4, and 3.3.0. ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 02:01:43 2012 From: report at bugs.python.org (Bradley Froehle) Date: Mon, 06 Aug 2012 00:01:43 +0000 Subject: [issue7897] Support parametrized tests in unittest In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za> Message-ID: <1344211303.29.0.826498641438.issue7897@psf.upfronthosting.co.za> Changes by Bradley Froehle : ---------- nosy: +bfroehle _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 02:04:18 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 06 Aug 2012 00:04:18 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1344211458.49.0.621183796921.issue15502@psf.upfronthosting.co.za> Brett Cannon added the comment: Eric's latest patch LGTM except for the missing patch for test.test_importlib.test_abc to fix the inheritance checks. Nick, Eric Smith, or Barry: can you double-check the patch is good? About the only thing that might be questionable is having MetaPathFinder and PathEntryFinder not inherit from Finder itself, but that does make sense and we do have multiple inheritance for a reason in Python. ---------- stage: needs patch -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 02:35:32 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 06 Aug 2012 00:35:32 +0000 Subject: [issue15482] __import__() change between 3.2 and 3.3 In-Reply-To: <1343530510.61.0.113197969687.issue15482@psf.upfronthosting.co.za> Message-ID: <1344213332.92.0.912784107373.issue15482@psf.upfronthosting.co.za> Brett Cannon added the comment: I just realized my reply was unclear; I meant changing Doc/library/functions.rst, not the code. And 3.3 already has a versionchanged note about no longer accepting negative indexes, but I will update it to mention the new default as well explicitly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 02:49:48 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 06 Aug 2012 00:49:48 +0000 Subject: [issue15471] importlib's __import__() argument style nit In-Reply-To: <1343408977.86.0.620892563203.issue15471@psf.upfronthosting.co.za> Message-ID: <1344214188.34.0.904778097188.issue15471@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 02:50:14 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Aug 2012 00:50:14 +0000 Subject: [issue15482] __import__() change between 3.2 and 3.3 In-Reply-To: <1343530510.61.0.113197969687.issue15482@psf.upfronthosting.co.za> Message-ID: <3Wr0dF2ZqQzPlk@mail.python.org> Roundup Robot added the comment: New changeset 3fe01f7520e2 by Brett Cannon in branch '3.2': Issue #15482: Properly document the default 'level' parameter for http://hg.python.org/cpython/rev/3fe01f7520e2 New changeset 05bec2e78a5c by Brett Cannon in branch 'default': Issue #15482: Merge 78449:3fe01f7520e2 with a minor clarification. http://hg.python.org/cpython/rev/05bec2e78a5c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 02:50:38 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 06 Aug 2012 00:50:38 +0000 Subject: [issue15482] __import__() change between 3.2 and 3.3 In-Reply-To: <1343530510.61.0.113197969687.issue15482@psf.upfronthosting.co.za> Message-ID: <1344214238.62.0.496100332709.issue15482@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 03:28:07 2012 From: report at bugs.python.org (abael) Date: Mon, 06 Aug 2012 01:28:07 +0000 Subject: [issue15522] impove 27 percent performance on stringpbject.c( by prefetch and loop optimization) In-Reply-To: <1344165639.93.0.0431332153585.issue15522@psf.upfronthosting.co.za> Message-ID: abael added the comment: do i need to fully maintain Python ? 2012/8/5 Serhiy Storchaka > > Changes by Serhiy Storchaka : > > > ---------- > status: open -> pending > > _______________________________________ > Python tracker > > _______________________________________ > ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 03:40:36 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 06 Aug 2012 01:40:36 +0000 Subject: [issue15522] impove 27 percent performance on stringpbject.c( by prefetch and loop optimization) In-Reply-To: <1343813632.92.0.115452555082.issue15522@psf.upfronthosting.co.za> Message-ID: <1344217236.74.0.640364361246.issue15522@psf.upfronthosting.co.za> R. David Murray added the comment: We are happy that you wish to contribute; however, our policy is that performance enhancements only go in to the newest version of Python, which means any submitted patch must be against the 'default' branch of the Python mercurial repository. If you wish to propose a patch against default, we will be happy to review it. If you do not wish to do so, we will close the issue, and your patch will remain available here on the tracker to anyone who wishes to apply it by hand to their own Python 2.7 installation. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 03:43:54 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 06 Aug 2012 01:43:54 +0000 Subject: [issue15492] textwrap.wrap expand_tabs does not behave as expected In-Reply-To: <1343596317.09.0.0346303694102.issue15492@psf.upfronthosting.co.za> Message-ID: <1344217434.87.0.464626495176.issue15492@psf.upfronthosting.co.za> R. David Murray added the comment: Sure. If you convince me we can reopen the issue :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 03:59:02 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 06 Aug 2012 01:59:02 +0000 Subject: [issue15554] correct and clarify str.splitlines() documentation In-Reply-To: <1344047978.01.0.683229635888.issue15554@psf.upfronthosting.co.za> Message-ID: <1344218342.41.0.393067633887.issue15554@psf.upfronthosting.co.za> R. David Murray added the comment: Ah, now I see what you are talking about. Yes, your revision in the comment is clearer; but, unless I read it wrong, in the patch it now sounds like you are saying that ''.splitlines() does not return the same result as ''.split() when in fact it does. I would also prefer that the "differences" discussion come in the separate paragraph after the specification of the behavior of the function, rather than the way you have it split up in the patch. I would include the mention of the lack-of-extra-line as part of the differences discussion: as I said I think that behavior follows logically from the fact that the function is splitting lines and so doesn't belong in the basic function description. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 04:09:50 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 06 Aug 2012 02:09:50 +0000 Subject: [issue15550] Trailing white spaces In-Reply-To: <1344008415.84.0.0454996292543.issue15550@psf.upfronthosting.co.za> Message-ID: <1344218990.71.0.170880297595.issue15550@psf.upfronthosting.co.za> Terry J. Reedy added the comment: How is it more of a nuisance for C files than for .py files? Editor 'trim trailing' tools certainly don't care. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 04:13:38 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 06 Aug 2012 02:13:38 +0000 Subject: [issue15554] correct and clarify str.splitlines() documentation In-Reply-To: <1344047978.01.0.683229635888.issue15554@psf.upfronthosting.co.za> Message-ID: <1344219218.4.0.48289931303.issue15554@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 04:44:47 2012 From: report at bugs.python.org (Stephen Webber) Date: Mon, 06 Aug 2012 02:44:47 +0000 Subject: [issue14182] collections.Counter equality test thrown-off by zero counts In-Reply-To: <1330769404.28.0.817906963132.issue14182@psf.upfronthosting.co.za> Message-ID: <1344221087.45.0.533158816878.issue14182@psf.upfronthosting.co.za> Stephen Webber added the comment: This is intentional handling of non-existant variables, and is not resticted to '==' operations. Returning the value of a Counter parameter that has not yet been set returns 0 by default. See the documentation here: http://docs.python.org/library/collections.html "Counter objects have a dictionary interface except that they return a zero count for missing items instead of raising a KeyError:" Since this is intended behavior, I recommend this bug become closed. ---------- nosy: +ForeverBacchus _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 05:44:05 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 06 Aug 2012 03:44:05 +0000 Subject: [issue15543] central documentation for 'universal newlines' In-Reply-To: <1343953234.25.0.0555174882779.issue15543@psf.upfronthosting.co.za> Message-ID: <1344224645.94.0.549020629419.issue15543@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Attaching a patch for review. ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file26706/issue-15543-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 05:55:27 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 06 Aug 2012 03:55:27 +0000 Subject: [issue15550] Trailing white spaces In-Reply-To: <1344008415.84.0.0454996292543.issue15550@psf.upfronthosting.co.za> Message-ID: <1344225327.01.0.83312273098.issue15550@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Out of curiosity, is there a mechanism to bypass the hook on a per-file basis, if necessary? FWIW, the WebKit open source project had a similar hook (for SVN) to prevent the inclusion of tabs in source files, and a custom SVN property was used to bypass the check on a per-file basis. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 06:59:53 2012 From: report at bugs.python.org (Meador Inge) Date: Mon, 06 Aug 2012 04:59:53 +0000 Subject: [issue15471] importlib's __import__() argument style nit In-Reply-To: <1343408977.86.0.620892563203.issue15471@psf.upfronthosting.co.za> Message-ID: <1344229193.5.0.777147090534.issue15471@psf.upfronthosting.co.za> Meador Inge added the comment: LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 07:01:43 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 06 Aug 2012 05:01:43 +0000 Subject: [issue15554] correct and clarify str.splitlines() documentation In-Reply-To: <1344047978.01.0.683229635888.issue15554@psf.upfronthosting.co.za> Message-ID: <1344229303.88.0.945913987929.issue15554@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > in the patch it now sounds like you are saying that ''.splitlines() does not return the same result as ''.split() when in fact it does. The two differences occur only when split() is passed a separator. split() uses a different algorithm when no separator is specified. For example, for the empty string case: >>> ''.splitlines() [] >>> ''.split() [] >>> ''.split('\n') [''] That is why I used the phrase "Unlike split() when passed a separator" in the patch: + Unlike :meth:`~str.split` when passed a separator, this method returns + an empty list for the empty string, and a terminal line break does not I will change the language in the patch to parallel split()'s documentation more closely, to emphasize and make this distinction clearer: "when passed a separator" -> "when a delimiter string *sep* is given". > I would also prefer that the "differences" discussion come in the separate paragraph after the specification of the behavior of the function, Good point. I agree with you. That occurred to me while drafting the patch, but I was hesitant to change the existing structure too much. In the updated patch I am attaching, I have also made that change. Thanks a lot for reviewing! ---------- Added file: http://bugs.python.org/file26707/issue-15554-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 07:02:17 2012 From: report at bugs.python.org (Meador Inge) Date: Mon, 06 Aug 2012 05:02:17 +0000 Subject: [issue15352] importlib.h should be regenerated when the marshaling code changes In-Reply-To: <1342294865.71.0.8673703337.issue15352@psf.upfronthosting.co.za> Message-ID: <1344229337.25.0.0406801159471.issue15352@psf.upfronthosting.co.za> Meador Inge added the comment: Yup, it is still an issue. The recent activity was mostly related to Windows builds (issue15431). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 07:35:47 2012 From: report at bugs.python.org (Georg Brandl) Date: Mon, 06 Aug 2012 05:35:47 +0000 Subject: [issue15471] importlib's __import__() argument style nit In-Reply-To: <1343408977.86.0.620892563203.issue15471@psf.upfronthosting.co.za> Message-ID: <1344231347.28.0.585987986565.issue15471@psf.upfronthosting.co.za> Georg Brandl added the comment: Looks good and safe to me. +1. ---------- assignee: georg.brandl -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 07:47:11 2012 From: report at bugs.python.org (Georg Brandl) Date: Mon, 06 Aug 2012 05:47:11 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1317341390.65.0.255779328054.issue13072@psf.upfronthosting.co.za> Message-ID: <1344232031.57.0.179923454842.issue13072@psf.upfronthosting.co.za> Georg Brandl added the comment: Victor: the revert commit brought back "Python's Unicode character type" into the docs. This needs to be fixed to say "legacy" somewhere, as the characters in a normal Unicode string are not of that type anymore. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 09:33:43 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Aug 2012 07:33:43 +0000 Subject: [issue8912] `make patchcheck` should check the whitespace of .c/.h files In-Reply-To: <1275794679.2.0.211731721822.issue8912@psf.upfronthosting.co.za> Message-ID: <1344238423.65.0.338787585458.issue8912@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 09:41:17 2012 From: report at bugs.python.org (Walid Shaari) Date: Mon, 06 Aug 2012 07:41:17 +0000 Subject: [issue15563] wrong conversion reported by Message-ID: <1344238877.43.0.388724812742.issue15563@psf.upfronthosting.co.za> New submission from Walid Shaari: In the code below the time stamp 1341183050 should be 01 July 2012. however datetime is converting it back to 7 July 2012, the reverse too is wrong, is that just the way i am using the code? [g_geadm at plcig2 ~]$ ipython Python 2.6.5 (r265:79063, Jul 14 2010, 11:36:05) Type "copyright", "credits" or "license" for more information. In [2]: import datetime In [3]: import time In [4]: datetime.datetime.fromtimestamp(1341183050) Out[4]: datetime.datetime(2012, 7, 2, 1, 50, 50) time.mktime(dt.timetuple()) In [5]: dt=datetime.datetime(2012, 7, 2, 1, 50, 50) In [6]: time.mktime(dt.timetuple()) Out[6]: 1341183050.0 In [7]: dt=datetime.datetime(2012, 7, 1, 22, 50, 50) In [8]: time.mktime(dt.timetuple()) Out[8]: 1341172250.0 In [9]: datetime.datetime.fromtimestamp(1341172250.0) Out[9]: datetime.datetime(2012, 7, 1, 22, 50, 50) ---------- components: Library (Lib) messages: 167541 nosy: wshaari priority: normal severity: normal status: open title: wrong conversion reported by versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 09:42:59 2012 From: report at bugs.python.org (Walid Shaari) Date: Mon, 06 Aug 2012 07:42:59 +0000 Subject: [issue15563] wrong conversion reported by In-Reply-To: <1344238877.43.0.388724812742.issue15563@psf.upfronthosting.co.za> Message-ID: <1344238979.51.0.602362610599.issue15563@psf.upfronthosting.co.za> Walid Shaari added the comment: the issue i believe is in datetime module ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 09:59:44 2012 From: report at bugs.python.org (Pierre Le Marre) Date: Mon, 06 Aug 2012 07:59:44 +0000 Subject: [issue15545] sqlite3.Connection.iterdump() does not work with row_factory = sqlite3.Row In-Reply-To: <1343981372.87.0.323193257201.issue15545@psf.upfronthosting.co.za> Message-ID: <1344239984.39.0.500652341024.issue15545@psf.upfronthosting.co.za> Pierre Le Marre added the comment: By the way, this issue does not appear with Python 3.2.2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 10:07:33 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 06 Aug 2012 08:07:33 +0000 Subject: [issue15563] wrong conversion reported by In-Reply-To: <1344238877.43.0.388724812742.issue15563@psf.upfronthosting.co.za> Message-ID: <1344240453.72.0.542407457043.issue15563@psf.upfronthosting.co.za> Martin v. L?wis added the comment: It's a timezone issue. Try datetime.datetime.utcfromtimestamp(1341183050) ---------- nosy: +loewis resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 10:38:26 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Mon, 06 Aug 2012 08:38:26 +0000 Subject: [issue15509] webbrowser.open sometimes passes zero-length argument to the browser. In-Reply-To: <1343687718.2.0.882765777761.issue15509@psf.upfronthosting.co.za> Message-ID: <1344242306.41.0.903333384564.issue15509@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 10:41:54 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Mon, 06 Aug 2012 08:41:54 +0000 Subject: [issue15523] Block on close TCP socket in SocketServer.py In-Reply-To: <1343815668.28.0.0910478510187.issue15523@psf.upfronthosting.co.za> Message-ID: <1344242514.25.0.288469769914.issue15523@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 10:42:11 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Mon, 06 Aug 2012 08:42:11 +0000 Subject: [issue15520] Document datetime.timestamp() in 3.3 What's New In-Reply-To: <1343807157.88.0.373148573533.issue15520@psf.upfronthosting.co.za> Message-ID: <1344242531.32.0.464843042067.issue15520@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 10:42:46 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Mon, 06 Aug 2012 08:42:46 +0000 Subject: [issue15506] configure should use PKG_PROG_PKG_CONFIG In-Reply-To: <1343670741.23.0.818269374942.issue15506@psf.upfronthosting.co.za> Message-ID: <1344242566.63.0.247397869856.issue15506@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 10:43:11 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Mon, 06 Aug 2012 08:43:11 +0000 Subject: [issue15504] pickle/cPickle saves invalid/incomplete data In-Reply-To: <1343663028.38.0.42350418133.issue15504@psf.upfronthosting.co.za> Message-ID: <1344242591.71.0.254460124631.issue15504@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 10:43:24 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Mon, 06 Aug 2012 08:43:24 +0000 Subject: [issue15501] Document exception classes in subprocess module In-Reply-To: <1343655102.86.0.835171642678.issue15501@psf.upfronthosting.co.za> Message-ID: <1344242604.19.0.564657187135.issue15501@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 10:47:28 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 06 Aug 2012 08:47:28 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1344208045.68.0.689539402599.issue13072@psf.upfronthosting.co.za> Message-ID: <20120806084728.GA3769@sleipnir.bytereef.org> Stefan Krah added the comment: STINNER Victor wrote: > Hum, this issue is a regression from Python 3.2. > > Python 3.2.3+ (3.2:243ad1a6f638+, Aug 4 2012, 01:36:41) > [GCC 4.6.3 20120306 (Red Hat 4.6.3-2)] on linux2 > >>> import array > >>> a=array.array('u', 'xyz') > >>> b=memoryview(a) > >>> a == b > True > >>> b == a > True [3.3 returns False] That's actually deliberate. The new memoryview does not consider arrays equal if the format codes do not match, to avoid situations like (32-bit Python): Python 3.2a0 (py3k:76143M, Nov 7 2009, 17:05:38) [GCC 4.2.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import array >>> a = array.array('f', [0]) >>> b = array.array('i', [0]) >>> x = memoryview(a) >>> y = memoryview(b) >>> >>> a == b True >>> x == y True >>> I think that (for buffers at least) an array of float should not compare equal to an array of int, especially since the 3.2 memoryview uses memcmp() in richcompare(). See also the comment in the documentation for memoryview.format: http://docs.python.org/dev/library/stdtypes.html#memoryview-type memoryview is not aware of the 'u' format code, since it's not part of the struct syntax and the PEP-3118 proposition 'u' -> UCS2, 'w' -> UCS4 wasn't considered useful. Now in your example I see that array's getbufferproc actually already uses 'w' for UCS4. It would still be an option to make memoryview aware of 'u' and 'w' (as suggested by the PEP). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 11:07:11 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 06 Aug 2012 09:07:11 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1317341390.65.0.255779328054.issue13072@psf.upfronthosting.co.za> Message-ID: <1344244031.55.0.63818854427.issue13072@psf.upfronthosting.co.za> Stefan Krah added the comment: Also, it was suggested that 'u' should be deprecated: http://mail.python.org/pipermail/python-dev/2012-March/117392.html Personally, I don't have an opinion on that; I don't use the 'u' format code. Nick, could you have a look at msg167545 and see if any action should be taken? ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 11:26:01 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 06 Aug 2012 09:26:01 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1317341390.65.0.255779328054.issue13072@psf.upfronthosting.co.za> Message-ID: <1344245161.67.0.0825645880307.issue13072@psf.upfronthosting.co.za> Stefan Krah added the comment: Of course, if two formats *are* the same, it is possible to use memcmp(). I'll work on a patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 11:31:46 2012 From: report at bugs.python.org (patrick vrijlandt) Date: Mon, 06 Aug 2012 09:31:46 +0000 Subject: [issue15564] cgi.FieldStorage should not call read_multi on files Message-ID: <1344245506.28.0.499641288303.issue15564@psf.upfronthosting.co.za> New submission from patrick vrijlandt: .mht is an archive format created by Microsoft IE 8 when saving a webpage. It is essentially a mime multipart message. My problem occurred when I uploaded such a file to a cgi-based server. The posted data would be fed to cgi.FieldStorage. (I can't post the file unfortunately) As it turns out, cgi.FieldStorage tries to recursively parse the postdata, thereby splitting up the uploaded file; this fails. However, this (automatic) recursive behaviour seems unwanted for an uploaded file. My proposal is thus to adapt cgi.py (line number for Python 3.2), so that in FieldStorage.__init__, line 542, read_multi would not be invoked in this case. Currently it says: elif ctype[:10] == 'multipart/': self.read_multi(environ, keep_blank_values, strict_parsing) Change this to: elif ctype[:10] == 'multipart/' and not self.filename: self.read_multi(environ, keep_blank_values, strict_parsing) (I apologise for not submitting a test case. When trying to create it, it is either very complicated, or not easily recognizable as valid. Moreover, my server used a 3rd party software (bottlypy.org: bottle.py)) ---------- components: Library (Lib) messages: 167548 nosy: patrick.vrijlandt priority: normal severity: normal status: open title: cgi.FieldStorage should not call read_multi on files type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 11:52:11 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 06 Aug 2012 09:52:11 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1317341390.65.0.255779328054.issue13072@psf.upfronthosting.co.za> Message-ID: <1344246731.67.0.317730495469.issue13072@psf.upfronthosting.co.za> Nick Coghlan added the comment: Perhaps if memoryview doesn't understand the format code, it can fall back on memcmp() if strcmp() indicates the format codes are the same? Otherwise we're at risk of breaking backwards compatibility with more than just array('u'). Also, if it isn't already, the change to take format codes into a account in memoryview comparisons should be mentioned in the What's New porting section. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 11:53:58 2012 From: report at bugs.python.org (Paul) Date: Mon, 06 Aug 2012 09:53:58 +0000 Subject: [issue15565] pdb displays runt Exception strings Message-ID: <1344246838.35.0.931540837367.issue15565@psf.upfronthosting.co.za> New submission from Paul: In Python 2.6, pdb doesn't show exception strings properly: #somecode.py import pdb pdb.set_trace() raise Exception('This is a message that contains a lot of characters and is very long indeed.') #terminal > somecode.py -> raise Exception('This is a message that contains a lot of characters and is very long indeed.') (Pdb) n Exception: Exceptio...ndeed.',) The pdb code assumes that sys.exc_info()[1] is a string. In fact it's an Exception instance. The solution I found was to use str() #pdb.py line 186 print >>self.stdout, exc_type_name + ':', _saferepr(str(exc_value)) This may have been fixed already but I couldn't find any reference to it. ---------- components: None messages: 167550 nosy: powlo priority: normal severity: normal status: open title: pdb displays runt Exception strings type: behavior versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 12:19:45 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Aug 2012 10:19:45 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1344244031.55.0.63818854427.issue13072@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > memoryview is not aware of the 'u' format code, since it's not part of > the struct syntax and the PEP-3118 proposition 'u' -> UCS2, 'w' -> UCS4 > wasn't considered useful. Did you see attached patch array_unicode_format.patch? It uses struct format "H" or "I" depending on the size of wchar_t. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 12:22:18 2012 From: report at bugs.python.org (Attila Nagy) Date: Mon, 06 Aug 2012 10:22:18 +0000 Subject: [issue15500] Python should support naming threads In-Reply-To: <1343650770.87.0.181202709436.issue15500@psf.upfronthosting.co.za> Message-ID: <1344248538.86.0.193059564225.issue15500@psf.upfronthosting.co.za> Attila Nagy added the comment: "I don't think this should be done by default as it will break people's expectations and, perhaps worse, compatibility." I won't mind another thread naming API, if somebody does this. :) But personally I expected python to name my threads (and if the OS supports it, on that level), I was actually surprised to see that it doesn't, mostly because I remembered a patch for FreeBSD, which did this years ago, so I thought it has been merged into mainline since then. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 12:24:21 2012 From: report at bugs.python.org (Sebastian Ramacher) Date: Mon, 06 Aug 2012 10:24:21 +0000 Subject: [issue15566] tarfile.TarInfo.frombuf documentation is out of date Message-ID: <1344248661.48.0.873103438616.issue15566@psf.upfronthosting.co.za> New submission from Sebastian Ramacher: tarfile.TarInfo.frombuf has gained two more parameters: encoding and errors. The documentation of frombuf claims that the only parameter is buf, which is not true anymore. ---------- assignee: docs at python components: Documentation messages: 167553 nosy: docs at python, sebastinas priority: normal severity: normal status: open title: tarfile.TarInfo.frombuf documentation is out of date versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 13:05:23 2012 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 06 Aug 2012 11:05:23 +0000 Subject: [issue15567] threading.py contains undefined name in self-test code Message-ID: <1344251123.58.0.751879223209.issue15567@psf.upfronthosting.co.za> New submission from Stefan Behnel: Line 912 of threading.py, Py2.7, reads: self.queue = deque() "deque" hasn't been imported. ---------- components: Library (Lib) messages: 167554 nosy: scoder priority: normal severity: normal status: open title: threading.py contains undefined name in self-test code type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 13:11:12 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Aug 2012 11:11:12 +0000 Subject: [issue10182] match_start truncates large values In-Reply-To: <1287859071.54.0.617398147143.issue10182@psf.upfronthosting.co.za> Message-ID: <1344251472.91.0.454266375559.issue10182@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +storchaka versions: +Python 3.3 -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 13:13:27 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Aug 2012 11:13:27 +0000 Subject: [issue10182] match_start truncates large values In-Reply-To: <1287859071.54.0.617398147143.issue10182@psf.upfronthosting.co.za> Message-ID: <1344251607.94.0.893374911708.issue10182@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Library (Lib) stage: -> needs patch type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 13:17:23 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Aug 2012 11:17:23 +0000 Subject: [issue10182] match_start truncates large values In-Reply-To: <1287859071.54.0.617398147143.issue10182@psf.upfronthosting.co.za> Message-ID: <1344251843.4.0.445559480076.issue10182@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 14:24:40 2012 From: report at bugs.python.org (=?utf-8?q?Thi=C3=A9baud_Weksteen?=) Date: Mon, 06 Aug 2012 12:24:40 +0000 Subject: [issue15464] ssl: add set_msg_callback function In-Reply-To: <1343352856.85.0.212414509347.issue15464@psf.upfronthosting.co.za> Message-ID: <1344255880.95.0.666043676639.issue15464@psf.upfronthosting.co.za> Thi?baud Weksteen added the comment: When I wrote this patch, I was focusing on a particular usage and the buffer was the only parameter that interested me. But you're right, the other parameters should be included. Which brings the following questions: * write_p looks like a boolean, would it be appropriate to make it like that? Or keep it integer? * version can be SSL2_VERSION , SSL3_VERSION or TLS1_VERSION. However, these constants are not used yet in _ssl. Should they be mapped to the current ones (with the tricky exception of PROTOCOL_SSLv23)? * content_type could just be passed as a regular integer. Thanks ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 14:35:36 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 06 Aug 2012 12:35:36 +0000 Subject: [issue15528] Better support for finalization with weakrefs In-Reply-To: <1343837927.06.0.561023898829.issue15528@psf.upfronthosting.co.za> Message-ID: <1344256535.77.0.0154902976208.issue15528@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > In _make_callback, I still think the default error reporting mechanism > should be kept. It can be improved separately. New patch. This time I have got rid of _make_callback, and just given __call__ an ignored optional argument. ---------- Added file: http://bugs.python.org/file26708/finalize.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 15:05:19 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 06 Aug 2012 13:05:19 +0000 Subject: [issue15554] correct and clarify str.splitlines() documentation In-Reply-To: <1344047978.01.0.683229635888.issue15554@psf.upfronthosting.co.za> Message-ID: <1344258319.53.0.770959906115.issue15554@psf.upfronthosting.co.za> R. David Murray added the comment: Ah, I read too quickly before. But that expression "when a delimiter string *sep* is given" is hard to wrap ones head around in this context. I think the problem really is that 'split' has such radically different behavior when given an argument as opposed to when it isn't. I consider that a design flaw in strip, and always have. So, I suppose we can't do any better here because of that. Please move the keeplines discussion back up into the initial paragraph, and then I think we'll be good to go. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 15:06:02 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 06 Aug 2012 13:06:02 +0000 Subject: [issue15554] correct and clarify str.splitlines() documentation In-Reply-To: <1344047978.01.0.683229635888.issue15554@psf.upfronthosting.co.za> Message-ID: <1344258362.19.0.903680315321.issue15554@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- Removed message: http://bugs.python.org/msg167557 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 15:06:21 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 06 Aug 2012 13:06:21 +0000 Subject: [issue15554] correct and clarify str.splitlines() documentation In-Reply-To: <1344047978.01.0.683229635888.issue15554@psf.upfronthosting.co.za> Message-ID: <1344258381.74.0.871682871391.issue15554@psf.upfronthosting.co.za> R. David Murray added the comment: Ah, I read too quickly before. But that expression "when a delimiter string *sep* is given" is hard to wrap ones head around in this context. I think the problem really is that 'split' has such radically different behavior when given an argument as opposed to when it isn't. I consider that a design flaw in split, and always have. So, I suppose we can't do any better here because of that. Please move the keeplines discussion back up into the initial paragraph, and then I think we'll be good to go. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 15:16:00 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 06 Aug 2012 13:16:00 +0000 Subject: [issue15500] Python should support naming threads In-Reply-To: <1343650770.87.0.181202709436.issue15500@psf.upfronthosting.co.za> Message-ID: <1344258960.07.0.234903029223.issue15500@psf.upfronthosting.co.za> R. David Murray added the comment: It is indeed the compatibility that is the worse issue. The problem is what people have gotten used to and may have coded their applications to expect/deal with. what people have gotten used to. I agree with you that most people would *not* find it surprising to see the name reflect in the OS, but I don't think the convenience of that is worth introducing a potential backward incompatibility. On the other hand, I think this might be an appropriate place to use a global control, so that getting thread names out to the OS would require adding just a single line of code to any given application. I know of an application that does this. It chose to implement it as a global change, and that makes sense to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 15:16:34 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 06 Aug 2012 13:16:34 +0000 Subject: [issue15500] Python should support naming threads In-Reply-To: <1343650770.87.0.181202709436.issue15500@psf.upfronthosting.co.za> Message-ID: <1344258994.17.0.0852802807312.issue15500@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- Removed message: http://bugs.python.org/msg167559 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 15:17:17 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 06 Aug 2012 13:17:17 +0000 Subject: [issue15500] Python should support naming threads In-Reply-To: <1343650770.87.0.181202709436.issue15500@psf.upfronthosting.co.za> Message-ID: <1344259037.73.0.380972057463.issue15500@psf.upfronthosting.co.za> R. David Murray added the comment: It is indeed the compatibility that is the worse issue. The problem is what people have gotten used to and may have coded their applications to expect/deal with. I agree with you that most people would *not* find it surprising to see the name reflected in the OS, but I don't think the convenience of that is worth introducing a potential backward incompatibility. On the other hand, I think this might be an appropriate place to use a global control, so that getting thread names out to the OS would require adding just a single line of code to any given application. I know of an application that does this. It chose to implement it as a global change, and that makes sense to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 15:19:34 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 06 Aug 2012 13:19:34 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1317341390.65.0.255779328054.issue13072@psf.upfronthosting.co.za> Message-ID: <1344259174.76.0.236546631221.issue13072@psf.upfronthosting.co.za> Stefan Krah added the comment: > Did you see attached patch array_unicode_format.patch? It uses struct > format "H" or "I" depending on the size of wchar_t. I totally overlooked that. Given that memoryview can be fixed to compare buffers with unknown formats, I don't have a strong opinion on whether array's getbufferproc should alter the format codes of 'u' and 'w' or not. The only advantage for memoryview would be that tolist() etc. would work. However, tolist() previously only worked for bytes, so in this case raising an exception for 'u' and 'w' is not a regression but an improvement. :) If we're deprecating 'u' and 'w' anyway, the getbufferproc should probably continue to return 'u' and 'w' until the removal of these format codes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 15:21:08 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 06 Aug 2012 13:21:08 +0000 Subject: [issue15564] cgi.FieldStorage should not call read_multi on files In-Reply-To: <1344245506.28.0.499641288303.issue15564@psf.upfronthosting.co.za> Message-ID: <1344259268.3.0.823300157364.issue15564@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 15:25:37 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 06 Aug 2012 13:25:37 +0000 Subject: [issue15565] pdb displays runt Exception strings In-Reply-To: <1344246838.35.0.931540837367.issue15565@psf.upfronthosting.co.za> Message-ID: <1344259537.32.0.0929044926474.issue15565@psf.upfronthosting.co.za> R. David Murray added the comment: As far as I can see it has been. In both 2.7 and 3.3 I get: rdmurray at hey:~/python/p33>./python somecode.py > /home/rdmurray/python/p33/somecode.py(3)() -> raise Exception('This is a message that contains a lot of characters and is very long indeed.') (Pdb) n Exception: This is a message that contains a lot of characters and is very long indeed. > /home/rdmurray/python/p33/somecode.py(3)() -> raise Exception('This is a message that contains a lot of characters and is very long indeed.') (Pdb) ---------- nosy: +r.david.murray resolution: -> out of date stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 15:42:43 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Aug 2012 13:42:43 +0000 Subject: [issue15037] curses.unget_wch and test_curses fail when linked with ncurses 5.7 and earlier In-Reply-To: <1339171712.6.0.747270716657.issue15037@psf.upfronthosting.co.za> Message-ID: <3WrKmd5MSbzPkc@mail.python.org> Roundup Robot added the comment: New changeset 8282e4846e43 by Ned Deily in branch 'default': Issue #15037: Build OS X installers with local copy of ncurses 5.9 libraries http://hg.python.org/cpython/rev/8282e4846e43 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 15:50:58 2012 From: report at bugs.python.org (Ned Deily) Date: Mon, 06 Aug 2012 13:50:58 +0000 Subject: [issue15037] curses.unget_wch and test_curses fail when linked with ncurses 5.7 and earlier In-Reply-To: <1339171712.6.0.747270716657.issue15037@psf.upfronthosting.co.za> Message-ID: <1344261058.51.0.608955718271.issue15037@psf.upfronthosting.co.za> Ned Deily added the comment: I've updated the OS X installers to build and link with a local copy of ncurses 5.9 rather than older Apple-supplied ones, thus avoiding the library bug. test_curses now passes for them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 15:53:19 2012 From: report at bugs.python.org (Ned Deily) Date: Mon, 06 Aug 2012 13:53:19 +0000 Subject: [issue14225] _cursesmodule compile error in OS X 32-bit-only installer build In-Reply-To: <1331161185.98.0.75427514561.issue14225@psf.upfronthosting.co.za> Message-ID: <1344261199.02.0.764383134024.issue14225@psf.upfronthosting.co.za> Ned Deily added the comment: P.P.S. I've updated the OS X installers as of 3.3.0b2 to build and link with a local copy of ncurses 5.9 rather than older Apple-supplied ones. test_curses now passes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 16:02:19 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 06 Aug 2012 14:02:19 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1317341390.65.0.255779328054.issue13072@psf.upfronthosting.co.za> Message-ID: <1344261739.03.0.975355618742.issue13072@psf.upfronthosting.co.za> Nick Coghlan added the comment: I think Victor's patch is a good solution to killing the 'u' and 'w' exports in 3.4, but we need to restore some tolerance for unknown format codes to memoryview in 3.3 regardless. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 16:42:33 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 06 Aug 2012 14:42:33 +0000 Subject: [issue15163] pydoc displays __loader__ as module data In-Reply-To: <1340546990.34.0.0743968242792.issue15163@psf.upfronthosting.co.za> Message-ID: <1344264153.11.0.648771618575.issue15163@psf.upfronthosting.co.za> ?ric Araujo added the comment: Now I have hardware issues, so no. ---------- assignee: eric.araujo -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 18:50:34 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 06 Aug 2012 16:50:34 +0000 Subject: [issue15553] Segfault in test_6_daemon_threads() of test_threading, on Mac OS X Lion In-Reply-To: <1344041649.82.0.110527224272.issue15553@psf.upfronthosting.co.za> Message-ID: <1344271834.85.0.819067864778.issue15553@psf.upfronthosting.co.za> Ronald Oussoren added the comment: The test passes fine on OSX 10.8 (even when running the threading test in a loop). This might be because a platform bug is fixed in OSX 10.8, or because the crash happens due to a race condition of some sort (either in Python itself or the system). This could be related to #3863 (this test is skipped on a number of platforms because of that issue) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 20:10:36 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 06 Aug 2012 18:10:36 +0000 Subject: [issue15554] correct and clarify str.splitlines() documentation In-Reply-To: <1344047978.01.0.683229635888.issue15554@psf.upfronthosting.co.za> Message-ID: <1344276636.93.0.787991588227.issue15554@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > I think the problem really is that 'split' has such radically different behavior when given an argument as opposed to when it isn't. Yep, the split() documentation is much more involved because of that. > Please move the keeplines discussion back up into the initial paragraph, and then I think we'll be good to go. Sounds good. Would you also like me to move the example before the paragraph about differences, or should I leave the example at the end? Mention of the example may flow better after the keepends discussion, because the example is more about keepends rather than about the differences with split(). But it can go either way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 20:40:33 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 06 Aug 2012 18:40:33 +0000 Subject: [issue15554] correct and clarify str.splitlines() documentation In-Reply-To: <1344047978.01.0.683229635888.issue15554@psf.upfronthosting.co.za> Message-ID: <1344278433.94.0.734891612023.issue15554@psf.upfronthosting.co.za> R. David Murray added the comment: Good point. Difference paragraph after the example would be best, I think. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 21:48:03 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 06 Aug 2012 19:48:03 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1317341390.65.0.255779328054.issue13072@psf.upfronthosting.co.za> Message-ID: <1344282483.19.0.895402367661.issue13072@psf.upfronthosting.co.za> Stefan Krah added the comment: I have a patch already for the unknown format codes in memoryview. Currently fighting (as usual) with the case explosions in the tests. I think I can have a full patch by next weekend. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 21:50:41 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 06 Aug 2012 19:50:41 +0000 Subject: [issue15554] correct and clarify str.splitlines() documentation In-Reply-To: <1344047978.01.0.683229635888.issue15554@psf.upfronthosting.co.za> Message-ID: <1344282641.78.0.874974784736.issue15554@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Here you go. Thanks again. ---------- Added file: http://bugs.python.org/file26709/issue-15554-4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 21:53:25 2012 From: report at bugs.python.org (Karen KarenL) Date: Mon, 06 Aug 2012 19:53:25 +0000 Subject: [issue9890] Visual C++ Runtime Library Error is there a fix? In-Reply-To: <1284774877.07.0.1280459876.issue9890@psf.upfronthosting.co.za> Message-ID: <1344282805.61.0.944731420795.issue9890@psf.upfronthosting.co.za> Karen KarenL added the comment: I just run into this problem. I am running python 3.2, but I do have python 26 and python 27 install on the same computer. ---------- nosy: +Karen.KarenL status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 22:09:50 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Aug 2012 20:09:50 +0000 Subject: [issue15554] correct and clarify str.splitlines() documentation In-Reply-To: <1344047978.01.0.683229635888.issue15554@psf.upfronthosting.co.za> Message-ID: <3WrVMH0psNzPmb@mail.python.org> Roundup Robot added the comment: New changeset 768b188262e7 by R David Murray in branch '3.2': #15554: clarify splitlines/split differences. http://hg.python.org/cpython/rev/768b188262e7 New changeset 0d6eea2330d0 by R David Murray in branch 'default': Merge #15554: clarify splitlines/split differences. http://hg.python.org/cpython/rev/0d6eea2330d0 New changeset e057a7d18fa2 by R David Murray in branch '2.7': #15554: clarify splitlines/split differences. http://hg.python.org/cpython/rev/e057a7d18fa2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 22:10:31 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 06 Aug 2012 20:10:31 +0000 Subject: [issue15554] correct and clarify str.splitlines() documentation In-Reply-To: <1344047978.01.0.683229635888.issue15554@psf.upfronthosting.co.za> Message-ID: <1344283831.49.0.637333560834.issue15554@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks for sticking with it. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 22:19:26 2012 From: report at bugs.python.org (Roger Serwy) Date: Mon, 06 Aug 2012 20:19:26 +0000 Subject: [issue9890] Visual C++ Runtime Library Error is there a fix? In-Reply-To: <1344282805.61.0.944731420795.issue9890@psf.upfronthosting.co.za> Message-ID: <502026CA.6080600@gmail.com> Roger Serwy added the comment: What are the precise steps you are taking to cause this error? What version of Windows are you using? Is it 32-bit? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 22:19:52 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 06 Aug 2012 20:19:52 +0000 Subject: [issue15163] pydoc displays __loader__ as module data In-Reply-To: <1340546990.34.0.0743968242792.issue15163@psf.upfronthosting.co.za> Message-ID: <1344284392.89.0.960999391068.issue15163@psf.upfronthosting.co.za> Brett Cannon added the comment: Georg, is it okay if I commit this on Eric's behalf for 3.3? ---------- assignee: -> georg.brandl nosy: +georg.brandl priority: low -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 22:34:54 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Aug 2012 20:34:54 +0000 Subject: [issue15471] importlib's __import__() argument style nit In-Reply-To: <1343408977.86.0.620892563203.issue15471@psf.upfronthosting.co.za> Message-ID: <3WrVwF2c2QzPpR@mail.python.org> Roundup Robot added the comment: New changeset 4240282a9f4a by Brett Cannon in branch 'default': Issue #15471: Don't use mutable object as default values for the http://hg.python.org/cpython/rev/4240282a9f4a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 22:35:12 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 06 Aug 2012 20:35:12 +0000 Subject: [issue15471] importlib's __import__() argument style nit In-Reply-To: <1343408977.86.0.620892563203.issue15471@psf.upfronthosting.co.za> Message-ID: <1344285312.13.0.905920723001.issue15471@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 22:44:05 2012 From: report at bugs.python.org (Peter Otten) Date: Mon, 06 Aug 2012 20:44:05 +0000 Subject: [issue15545] sqlite3.Connection.iterdump() does not work with row_factory = sqlite3.Row In-Reply-To: <1343981372.87.0.323193257201.issue15545@psf.upfronthosting.co.za> Message-ID: <1344285845.54.0.416168806976.issue15545@psf.upfronthosting.co.za> Peter Otten added the comment: Here's a minimal fix that modifies the sql in sqlite3.dump._iterdump() to sort the tables by name. It is then no longer necessary to sort the resultset in Python for the unit tests to pass. ---------- keywords: +patch nosy: +peter.otten Added file: http://bugs.python.org/file26710/iterdump.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 22:51:52 2012 From: report at bugs.python.org (Georg Brandl) Date: Mon, 06 Aug 2012 20:51:52 +0000 Subject: [issue15163] pydoc displays __loader__ as module data In-Reply-To: <1340546990.34.0.0743968242792.issue15163@psf.upfronthosting.co.za> Message-ID: <1344286312.82.0.581033883232.issue15163@psf.upfronthosting.co.za> Georg Brandl added the comment: Great to review such patches, where I have to take out a notepad and write the names down to check a 1-item addition. But it seems it does what's on the label, so go ahead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 23:09:25 2012 From: report at bugs.python.org (Karen KarenL) Date: Mon, 06 Aug 2012 21:09:25 +0000 Subject: [issue9890] Visual C++ Runtime Library Error is there a fix? In-Reply-To: <1284774877.07.0.1280459876.issue9890@psf.upfronthosting.co.za> Message-ID: <1344287365.84.0.13526836644.issue9890@psf.upfronthosting.co.za> Karen KarenL added the comment: Additional info on error in python 3.2 I am using 32 bit Win 7 enterprise SP1. I download and installed python-3.2.msi from python.org I than start python pythonw from window menu just like any other program. Running python command line also failed, and this is the error message: Fatal Python error: Py_Initialize: unable to load the file system codec LookupError: no codec search functions registered: can't find encoding This application has requested the runtime to terminate it in an unusual way. Please contact the application's support team for more information. I have uninstalled python 26, 27, 32. Then reinstalled 32. Problem is still presents. I also have cygwin on my system. Python 26 and 27 worked without any issue. Python 26 that comes with cywin worked as well. I just updated my cygwin to get python 3.2 binaries from cygwin's dist. It is working. Let me know if there is anything I can do to help. Karen ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 23:12:45 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 06 Aug 2012 21:12:45 +0000 Subject: [issue15163] pydoc displays __loader__ as module data In-Reply-To: <1340546990.34.0.0743968242792.issue15163@psf.upfronthosting.co.za> Message-ID: <1344287565.96.0.146457210732.issue15163@psf.upfronthosting.co.za> Brett Cannon added the comment: I will alphabetize as part of the patch (I had the same issue myself of verifying the change). ---------- assignee: georg.brandl -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 23:15:29 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 06 Aug 2012 21:15:29 +0000 Subject: [issue15163] pydoc displays __loader__ as module data In-Reply-To: <1340546990.34.0.0743968242792.issue15163@psf.upfronthosting.co.za> Message-ID: <1344287729.14.0.688173364173.issue15163@psf.upfronthosting.co.za> ?ric Araujo added the comment: Sorry for the annoyance. I changed the order (and did not choose to alphabetize) because I thought it was easier to read with names grouped by topic, as I said in an earlier message, but please do as you think best. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 23:17:58 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 06 Aug 2012 21:17:58 +0000 Subject: [issue15561] update subprocess docs to reference io.TextIOWrapper In-Reply-To: <1344196317.87.0.366111796882.issue15561@psf.upfronthosting.co.za> Message-ID: <1344287878.21.0.144084481817.issue15561@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Victor, would you be able to take a look at this minor documentation patch? It incorporates the change that you suggested we make on python-dev. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 23:19:28 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Aug 2012 21:19:28 +0000 Subject: [issue15163] pydoc displays __loader__ as module data In-Reply-To: <1340546990.34.0.0743968242792.issue15163@psf.upfronthosting.co.za> Message-ID: <3WrWvg0CkKzPjt@mail.python.org> Roundup Robot added the comment: New changeset 6a27b9f37b05 by Brett Cannon in branch 'default': Issue #15163: Pydoc shouldn't show __loader__ as a part of a module's http://hg.python.org/cpython/rev/6a27b9f37b05 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 23:20:32 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 06 Aug 2012 21:20:32 +0000 Subject: [issue15163] pydoc displays __loader__ as module data In-Reply-To: <1340546990.34.0.0743968242792.issue15163@psf.upfronthosting.co.za> Message-ID: <1344288032.19.0.144932063563.issue15163@psf.upfronthosting.co.za> Brett Cannon added the comment: Don't worry about it, Eric. while the idea of grouping by concept is laudable, when the list is that long it's best to just alphabetize to make diffs easier to read. ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 6 23:35:34 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 06 Aug 2012 21:35:34 +0000 Subject: [issue15471] importlib's __import__() argument style nit In-Reply-To: <1344210618.04.0.133809026711.issue15471@psf.upfronthosting.co.za> Message-ID: <20120806173550.60b12d04@resist> Barry A. Warsaw added the comment: On Aug 05, 2012, at 11:50 PM, Brett Cannon wrote: >I went with Barry's approach but made it compatible with PEP 8 (bad, FLUFL; >no unneeded parens!). I actually think I picked that up from the big guy himself, but I could be misremembering. ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 00:31:30 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 06 Aug 2012 22:31:30 +0000 Subject: [issue15437] Merge Doc/ACKS.txt names into Misc/ACKS In-Reply-To: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za> Message-ID: <1344292290.26.0.493645352765.issue15437@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Is this issue awaiting feedback from anyone else before it can proceed further? (Just this issue and not issue 15439 to make any adjustments to the docs.) I am attaching an updated diff after generating the script output again against the tip (modified to prefix matching last names with '>>> '). ---------- Added file: http://bugs.python.org/file26711/issue-15437-script-output-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 00:36:42 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 06 Aug 2012 22:36:42 +0000 Subject: [issue15437] Merge Doc/ACKS.txt names into Misc/ACKS In-Reply-To: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za> Message-ID: <1344292602.58.0.10043700663.issue15437@psf.upfronthosting.co.za> Chris Jerdonek added the comment: For completeness, I am attaching the modified version of the script that was used to generate the latest output. ---------- Added file: http://bugs.python.org/file26712/merge-acks-2.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 01:11:18 2012 From: report at bugs.python.org (=?utf-8?q?Ludwig_H=C3=A4hne?=) Date: Mon, 06 Aug 2012 23:11:18 +0000 Subject: [issue15424] __sizeof__ of array should include size of items In-Reply-To: <1342974161.65.0.374402048104.issue15424@psf.upfronthosting.co.za> Message-ID: <1344294678.09.0.194012196535.issue15424@psf.upfronthosting.co.za> Ludwig H?hne added the comment: Serhiy, the tests now explicitly check the base size of the array. I'm not sure if I got the base size compution right (only checked on 32bit Linux). Could you check that the struct definition in the test makes sense and matches the C arrayobject definition? Thanks, Ludwig ---------- Added file: http://bugs.python.org/file26713/array_sizeof_v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 02:16:24 2012 From: report at bugs.python.org (Dino Viehland) Date: Tue, 07 Aug 2012 00:16:24 +0000 Subject: [issue15568] yield from missed StopIteration raised from iterator instead of getting value Message-ID: <1344298577.11.0.925171364298.issue15568@psf.upfronthosting.co.za> New submission from Dino Viehland: When implementing an iterable object by hand, and raising StopIteration with a value, the value is not provided as the result of the yield from expression. This differs from the behavior in the "Formal Semantics" section. Here's an example of how it differs from working with a normal generator: class C: def __iter__(self): return self def __next__(self): raise StopIteration(100) def g(): if False: yield 100 return 100 def f(val): x = yield from val print('x', x) list(f(C())) list(f(g())) This makes it impossible to wrap a generator in a non-generator and get the same behavior. The issue seems to be that the yield from implementation calls PyIter_Next which clears the StopIteration exception rather than say directly doing something like "(*iter->ob_type->tp_iternext)(iter);". ---------- components: Interpreter Core messages: 167591 nosy: dino.viehland priority: normal severity: normal status: open title: yield from missed StopIteration raised from iterator instead of getting value type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 02:17:30 2012 From: report at bugs.python.org (Alex Gaynor) Date: Tue, 07 Aug 2012 00:17:30 +0000 Subject: [issue15568] yield from missed StopIteration raised from iterator instead of getting value In-Reply-To: <1344298577.11.0.925171364298.issue15568@psf.upfronthosting.co.za> Message-ID: <1344298650.56.0.77776570915.issue15568@psf.upfronthosting.co.za> Changes by Alex Gaynor : ---------- nosy: +alex _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 02:20:23 2012 From: report at bugs.python.org (Meador Inge) Date: Tue, 07 Aug 2012 00:20:23 +0000 Subject: [issue15568] yield from missed StopIteration raised from iterator instead of getting value In-Reply-To: <1344298577.11.0.925171364298.issue15568@psf.upfronthosting.co.za> Message-ID: <1344298822.99.0.755859384894.issue15568@psf.upfronthosting.co.za> Changes by Meador Inge : ---------- nosy: +meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 02:43:57 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 07 Aug 2012 00:43:57 +0000 Subject: [issue15543] central documentation for 'universal newlines' In-Reply-To: <1343953234.25.0.0555174882779.issue15543@psf.upfronthosting.co.za> Message-ID: <1344300237.14.0.77066359312.issue15543@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Updating patch to current tip. ---------- Added file: http://bugs.python.org/file26714/issue-15543-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 02:53:26 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Aug 2012 00:53:26 +0000 Subject: [issue15568] yield from missed StopIteration raised from iterator instead of getting value In-Reply-To: <1344298577.11.0.925171364298.issue15568@psf.upfronthosting.co.za> Message-ID: <3WrcfX4fSgzPrt@mail.python.org> Roundup Robot added the comment: New changeset ee55f8e4fb50 by Benjamin Peterson in branch 'default': fix yield from return value on custom iterators (closes #15568) http://hg.python.org/cpython/rev/ee55f8e4fb50 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 03:09:18 2012 From: report at bugs.python.org (INADA Naoki) Date: Tue, 07 Aug 2012 01:09:18 +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: <1344301758.4.0.19015621822.issue15216@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- nosy: +naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 03:24:07 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 07 Aug 2012 01:24:07 +0000 Subject: [issue15569] Dev Guide format-only roles Message-ID: <1344302647.18.0.307450045197.issue15569@psf.upfronthosting.co.za> New submission from Chris Jerdonek: After the section describing roles that create cross-references to C-language constructs, the Dev Guide says this, "The following roles don?t do anything special except formatting the text in a different style." http://hg.python.org/devguide/file/f518f23d06d5/documenting.rst#l984 However, some of the roles following in that section do do special things other than formatting. For example-- envvar An environment variable. Index entries are generated. keyword The name of a Python keyword. Using this role will generate a link to the documentation of the keyword.... The description should be changed, or better yet, the roles that do something special should be moved to a different section. ---------- components: Devguide keywords: easy messages: 167594 nosy: cjerdonek, ezio.melotti priority: normal severity: normal status: open title: Dev Guide format-only roles _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 03:44:15 2012 From: report at bugs.python.org (Meador Inge) Date: Tue, 07 Aug 2012 01:44:15 +0000 Subject: [issue14182] collections.Counter equality test thrown-off by zero counts In-Reply-To: <1330769404.28.0.817906963132.issue14182@psf.upfronthosting.co.za> Message-ID: <1344303855.12.0.3872883138.issue14182@psf.upfronthosting.co.za> Meador Inge added the comment: Raymond, Stephen's analysis seems correct. Are we missing something or can this issue be closed? ---------- nosy: +meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 03:49:31 2012 From: report at bugs.python.org (Meador Inge) Date: Tue, 07 Aug 2012 01:49:31 +0000 Subject: [issue15424] __sizeof__ of array should include size of items In-Reply-To: <1342974161.65.0.374402048104.issue15424@psf.upfronthosting.co.za> Message-ID: <1344304171.59.0.79010308066.issue15424@psf.upfronthosting.co.za> Meador Inge added the comment: I left some commits in Rietveld. Otherwise, looks OK. ---------- assignee: -> meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 03:58:16 2012 From: report at bugs.python.org (Meador Inge) Date: Tue, 07 Aug 2012 01:58:16 +0000 Subject: [issue15566] tarfile.TarInfo.frombuf documentation is out of date In-Reply-To: <1344248661.48.0.873103438616.issue15566@psf.upfronthosting.co.za> Message-ID: <1344304696.78.0.781365017974.issue15566@psf.upfronthosting.co.za> Changes by Meador Inge : ---------- stage: -> needs patch type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 04:01:37 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Aug 2012 02:01:37 +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: <1344304897.02.0.734555445654.issue15216@psf.upfronthosting.co.za> STINNER Victor added the comment: Here is a Python implementation of TextIOWrapper.set_encoding(). The main limitation is that it is not possible to set the encoding on a non-seekable stream after the first read (if the read buffer is not empty, ie. if there are pending decoded characters). + # flush read buffer, may require to seek backward in the underlying + # file object + if self._decoded_chars: + if not self.seekable(): + raise UnsupportedOperation( + "It is not possible to set the encoding " + "of a non seekable file after the first read") + assert self._snapshot is not None + dec_flags, next_input = self._snapshot + offset = self._decoded_chars_used - len(next_input) + if offset: + self.buffer.seek(offset, SEEK_CUR) -- I don't have an use case for setting the encoding of sys.stdout/stderr after startup, but I would like to be able to control the *error handler* after the startup! My implementation permits to change both (encoding, errors, encoding and errors). For example, Lib/test/regrtest.py uses the following function to force the backslashreplace error handler on sys.stdout. It changes the error handler to avoid UnicodeEncodeError when displaying the result of tests. def replace_stdout(): """Set stdout encoder error handler to backslashreplace (as stderr error handler) to avoid UnicodeEncodeError when printing a traceback""" import atexit stdout = sys.stdout sys.stdout = open(stdout.fileno(), 'w', encoding=stdout.encoding, errors="backslashreplace", closefd=False, newline='\n') def restore_stdout(): sys.stdout.close() sys.stdout = stdout atexit.register(restore_stdout) The doctest module uses another trick to change the error handler: save_stdout = sys.stdout if out is None: encoding = save_stdout.encoding if encoding is None or encoding.lower() == 'utf-8': out = save_stdout.write else: # Use backslashreplace error handling on write def out(s): s = str(s.encode(encoding, 'backslashreplace'), encoding) save_stdout.write(s) sys.stdout = self._fakeout ---------- keywords: +patch nosy: +haypo Added file: http://bugs.python.org/file26715/set_encoding.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 04:04:22 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Aug 2012 02:04:22 +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: <1344305062.85.0.396649248037.issue15216@psf.upfronthosting.co.za> STINNER Victor added the comment: > That will be fragile. A bit of prematurate input or output > (for whatever reason) and your program breaks. I agree that it is not the most pure solution, but sometimes practicality beats purity (rule #9) ;-) We can add an ugly big red warning in the doc ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 04:09:03 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Aug 2012 02:09:03 +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: <1344305343.64.0.400571753503.issue15216@psf.upfronthosting.co.za> STINNER Victor added the comment: > My implementation permits to change both (encoding, errors, encoding and errors). We may also add a set_errors() method: def set_errors(self, errors): self.set_encoding(self.encoding, errors) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 05:27:26 2012 From: report at bugs.python.org (Roger Serwy) Date: Tue, 07 Aug 2012 03:27:26 +0000 Subject: [issue9890] Visual C++ Runtime Library Error is there a fix? In-Reply-To: <1344287365.84.0.13526836644.issue9890@psf.upfronthosting.co.za> Message-ID: <50208B19.9080809@gmail.com> Roger Serwy added the comment: Karen, thank you for your reply and your cooperation. This issue may take some time to resolve. It looks like the error you are receiving has been addressed in issue11288. Can you check it out? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 06:46:42 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Tue, 07 Aug 2012 04:46:42 +0000 Subject: [issue15122] Add an option to always rewrite single-file mailboxes in-place. In-Reply-To: <1340275550.98.0.309231550082.issue15122@psf.upfronthosting.co.za> Message-ID: <1344314802.16.0.793661215411.issue15122@psf.upfronthosting.co.za> Petri Lehtinen added the comment: Thinking about this again, I guess the original design rationale was not to prepare for crashes, but for the ease of implementation. It's not generally possible to rewrite the mailbox fully in-place, because the messages are not loaded into memory. If the order of messages changes, for example, a message can be overwritten in the mailbox file, and its contents need to be read afterwards. Mutt copes with this by writing the changes to a temporary file, and then copying them over to the original file. This is what we should also be doing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 07:19:24 2012 From: report at bugs.python.org (Dmitry Dvoinikov) Date: Tue, 07 Aug 2012 05:19:24 +0000 Subject: [issue15570] email.header.decode_header parses differently Message-ID: <1344316764.02.0.79283890102.issue15570@psf.upfronthosting.co.za> New submission from Dmitry Dvoinikov: The following script --- import email.header print(email.header.decode_header("foo =?windows-1251?Q?bar?=")) --- produces [(b'foo', None), (b'bar', 'windows-1251')] in Python 3.2 but [(b'foo ', None), (b'bar', 'windows-1251')] in Python 3.3.0b1 ---------- components: Library (Lib) messages: 167602 nosy: ddvoinikov priority: normal severity: normal status: open title: email.header.decode_header parses differently type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 07:27:37 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 07 Aug 2012 05:27:37 +0000 Subject: [issue15571] Python version of TextIOWrapper ignores "write_through" arg Message-ID: <1344317257.52.0.527557434634.issue15571@psf.upfronthosting.co.za> New submission from Nick Coghlan: In discussing #15216, I noticed that the write_through parameter is completely unused in the Python implementation of TextIOWrapper. That also means we have a hole in the test coverage: there is no test that is run on both the C and Python versions to ensure that the data is being written directly through to the underlying buffer (e.g. by passing in a mock buffer object). ---------- components: Library (Lib) messages: 167603 nosy: ncoghlan priority: release blocker severity: normal stage: test needed status: open title: Python version of TextIOWrapper ignores "write_through" arg type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 07:34:02 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 07 Aug 2012 05:34:02 +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: <1344317642.32.0.214345258398.issue15216@psf.upfronthosting.co.za> Nick Coghlan added the comment: The reason I marked this as a release blocker for 3.4 is because it's a key piece of functionality for writing command line apps which accept an encoding argument. I'll use "high" instead. An interesting proposal was posted to the python-dev thread [1]: using self.detach() and self.__init__() to reinitialise the wrapper *in-place*. With that approach, the pure Python version of set_encoding() would look something like this: _sentinel = object() def set_encoding(self, encoding=_sentinel, errors=_sentinel): if encoding is _sentinel: encoding = self.encoding if errors is _sentinel: errors = self.errors self.__init__(self.detach(), encoding, errors, self._line_buffering, self._readnl, self._write_through) (The pure Python version currently has no self._write_through attribute - see #15571) Note that this approach addresses my main concern with the use of detach() for this: because the wrapper is reinitialised in place, old references (such as the sys.__std*__ attributes) will also see the change. Yes, such a function would need a nice clear warning to say "Calling this may cause data loss or corruption if used without due care and attention", but it should *work*. (Without automatic garbage collection, the C implementation would need an explicit internal "reinitialise" function rather than being able to just use the existing init function directly, but that shouldn't be a major problem). [1] http://mail.python.org/pipermail/python-ideas/2012-August/015898.html ---------- priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 09:15:26 2012 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 07 Aug 2012 07:15:26 +0000 Subject: [issue14182] collections.Counter equality test thrown-off by zero counts In-Reply-To: <1330769404.28.0.817906963132.issue14182@psf.upfronthosting.co.za> Message-ID: <1344323726.48.0.998130641105.issue14182@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Raymond, Stephen's analysis seems correct. Are we missing something or > can this issue be closed? Well, depending on how you think about Counters, the current behaviour of equality definitely leads to some surprises. For example: >>> Counter(a = 3) + Counter(b = 0) == Counter(a = 3, b = 0) False OTOH, if we're consistent about regarding a count of 0 as 'equivalent' to a missing element, then __nonzero__ / __bool__ probably needs changing, too. >>> c = Counter(a = 0) >>> bool(c) True >>> bool(c + c) False ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 09:30:04 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 07 Aug 2012 07:30:04 +0000 Subject: [issue15571] Python version of TextIOWrapper ignores "write_through" arg In-Reply-To: <1344317257.52.0.527557434634.issue15571@psf.upfronthosting.co.za> Message-ID: <1344324604.0.0.525136882575.issue15571@psf.upfronthosting.co.za> Chris Jerdonek added the comment: The fact that the Python implementation doesn't look at write_through doesn't necessarily mean that it's not respected. It could always write through. Indeed, it looks like this is the case and was discussed at one point: http://bugs.python.org/issue12591#msg141006 Also, it appears that there is a test in both cases (the test class is subclassed twice), though I could be wrong: http://hg.python.org/cpython/file/0eeffeadaa1e/Lib/test/test_io.py#l2453 In any case, this could probably at least use a code comment. ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 09:44:05 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 07 Aug 2012 07:44:05 +0000 Subject: [issue15571] Python version of TextIOWrapper ignores "write_through" arg In-Reply-To: <1344317257.52.0.527557434634.issue15571@psf.upfronthosting.co.za> Message-ID: <1344325445.9.0.318148956649.issue15571@psf.upfronthosting.co.za> Nick Coghlan added the comment: Ah, thanks. Yes, that could definitely use a comment :) ---------- priority: release blocker -> normal stage: test needed -> needs patch type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 10:10:44 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 07 Aug 2012 08:10:44 +0000 Subject: [issue15571] Python version of TextIOWrapper ignores "write_through" arg In-Reply-To: <1344317257.52.0.527557434634.issue15571@psf.upfronthosting.co.za> Message-ID: <1344327043.98.0.472939378.issue15571@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Attaching patch. ---------- keywords: +patch Added file: http://bugs.python.org/file26716/issue-15571-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 10:12:16 2012 From: report at bugs.python.org (Francois VISCONTE) Date: Tue, 07 Aug 2012 08:12:16 +0000 Subject: [issue13992] Segfault in PyTrash_destroy_chain In-Reply-To: <1328964953.21.0.536994091719.issue13992@psf.upfronthosting.co.za> Message-ID: <1344327136.3.0.250559135195.issue13992@psf.upfronthosting.co.za> Francois VISCONTE added the comment: Hi, Following Manu's information I complete with what you asked. I repeated the bug described by Manu, with the same software in exactly the same conditions. The corrupted object is one of our SQLAlchemy mapped object. Chances are that the bug came from SQLAlchemy. Find joined the "thread all apply bt" output. I will investigate today on this bug and will try to find a quicker way to reproduce it in order to use an hardware watchpoint on object refcount. ---------- nosy: +fvisconte Added file: http://bugs.python.org/file26717/thread_all_apply_bt.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 11:47:06 2012 From: report at bugs.python.org (=?utf-8?q?Ludwig_H=C3=A4hne?=) Date: Tue, 07 Aug 2012 09:47:06 +0000 Subject: [issue15424] __sizeof__ of array should include size of items In-Reply-To: <1342974161.65.0.374402048104.issue15424@psf.upfronthosting.co.za> Message-ID: <1344332826.83.0.931565722961.issue15424@psf.upfronthosting.co.za> Ludwig H?hne added the comment: Meador, thanks for reviewing. The updated patch is now attached to the bug. ---------- Added file: http://bugs.python.org/file26718/array_sizeof_v5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 12:05:33 2012 From: report at bugs.python.org (Matthias Klose) Date: Tue, 07 Aug 2012 10:05:33 +0000 Subject: [issue11715] Building Python on multiarch Debian and Ubuntu In-Reply-To: <1301435300.88.0.0418449859461.issue11715@psf.upfronthosting.co.za> Message-ID: <1344333933.69.0.227084574986.issue11715@psf.upfronthosting.co.za> Matthias Klose added the comment: about searching /lib/: adding this directory won't help. all .a and .so files are installed in /usr/lib or /usr/lib/. about the missing dpkg-architecture: see the attached ma.diff patch. the Debian/Ubuntu system compilers add an option -print-multiarch, which can be used to get the multiarch name without having the dpkg-dev package installed. ---------- nosy: +doko resolution: fixed -> status: closed -> open Added file: http://bugs.python.org/file26719/ma.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 12:10:35 2012 From: report at bugs.python.org (Matthias Klose) Date: Tue, 07 Aug 2012 10:10:35 +0000 Subject: [issue14330] don't use host python, use host search paths for host compiler In-Reply-To: <1331856850.28.0.590122825265.issue14330@psf.upfronthosting.co.za> Message-ID: <1344334235.12.0.66794018044.issue14330@psf.upfronthosting.co.za> Matthias Klose added the comment: these are all extensions, which use headers and libraries installed in multiarch paths, which I think are not found in this case. If the dpkg-dev package isn't installed, please install it and recheck. So this issue should be closed, maybe with the ma.diff patch applies as in issue #15426. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 12:12:33 2012 From: report at bugs.python.org (Matthias Klose) Date: Tue, 07 Aug 2012 10:12:33 +0000 Subject: [issue14330] don't use host python, use host search paths for host compiler In-Reply-To: <1331856850.28.0.590122825265.issue14330@psf.upfronthosting.co.za> Message-ID: <1344334353.31.0.795002174332.issue14330@psf.upfronthosting.co.za> Matthias Klose added the comment: and please make sure that other build dependencies are installed as well: sudo apt-get build-dep python3.2 (on 12.04/precise) sudo apt-get build-dep python3.3 (on 12.10/quantal) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 12:12:55 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Aug 2012 10:12:55 +0000 Subject: [issue15560] _sqlite3.so is built with wrong include file on OS X when using an SDK In-Reply-To: <1344157418.55.0.45856897604.issue15560@psf.upfronthosting.co.za> Message-ID: <3Wrs433c0HzPs8@mail.python.org> Roundup Robot added the comment: New changeset 59223da36dec by Ned Deily in branch 'default': Issue #15560: Ensure consistent sqlite3 behavior and feature availability http://hg.python.org/cpython/rev/59223da36dec ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 12:16:20 2012 From: report at bugs.python.org (Matthias Klose) Date: Tue, 07 Aug 2012 10:16:20 +0000 Subject: [issue14330] don't use host python, use host search paths for host compiler In-Reply-To: <1331856850.28.0.590122825265.issue14330@psf.upfronthosting.co.za> Message-ID: <1344334580.66.0.106408074262.issue14330@psf.upfronthosting.co.za> Matthias Klose added the comment: afaics, msg166444 doesn't have to do anything with the cross build issue, but a missing build dependency (here: dpkg-dev). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 12:21:23 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Aug 2012 10:21:23 +0000 Subject: [issue15424] __sizeof__ of array should include size of items In-Reply-To: <1342974161.65.0.374402048104.issue15424@psf.upfronthosting.co.za> Message-ID: <1344334883.66.0.447578459667.issue15424@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Patch looks good to me, however tests for 3.2 and 2.7 should be modified (change "n" struct format specifier to "P", remove last "i" and use test_support instead test.support (or import test_support as support) in 2.7). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 12:58:46 2012 From: report at bugs.python.org (Cherniavsky Beni) Date: Tue, 07 Aug 2012 10:58:46 +0000 Subject: [issue15572] Python2 documentation of the file() built-in function Message-ID: <1344337126.35.0.910638419892.issue15572@psf.upfronthosting.co.za> New submission from Cherniavsky Beni: [followup for issue 12642 which only fixed it for open()] http://docs.python.org/library/functions.html#file says the arg names are: file(filename[, mode[, bufsize]]) but in practice they are: file(name[, mode[, buffering]]) ---------- assignee: docs at python components: Documentation messages: 167617 nosy: cben, docs at python priority: normal severity: normal status: open title: Python2 documentation of the file() built-in function versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 12:59:56 2012 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 07 Aug 2012 10:59:56 +0000 Subject: [issue14870] Descriptions of os.utime() and os.utimensat() use wrong notation In-Reply-To: <1337601006.45.0.685713178373.issue14870@psf.upfronthosting.co.za> Message-ID: <1344337196.59.0.607699975795.issue14870@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: -> needs patch type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 13:23:17 2012 From: report at bugs.python.org (Eli Bendersky) Date: Tue, 07 Aug 2012 11:23:17 +0000 Subject: [issue15572] Python2 documentation of the file() built-in function In-Reply-To: <1344337126.35.0.910638419892.issue15572@psf.upfronthosting.co.za> Message-ID: <1344338597.48.0.556133429684.issue15572@psf.upfronthosting.co.za> Changes by Eli Bendersky : ---------- nosy: +eli.bendersky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 13:55:31 2012 From: report at bugs.python.org (Stefan Krah) Date: Tue, 07 Aug 2012 11:55:31 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons Message-ID: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> New submission from Stefan Krah: Continuing the discussion from #13072. I hit a snag here: Determining in full generality whether two format strings describe identical items is pretty complicated, see also #3132. I'm attaching a best effort fmtcmp() function that should do the following: - recognize byte order specifiers at the start of the string. - recognize if an explicitly specified byte order happens to match the native byte order. It won't catch: - byte order specifiers anywhere in the string. - C types that happen to be identical ('I', 'L' on a 32-bit platform). I'm also not sure if that is desirable in the first place. - ??? So fmtcmp() will return false negatives (not equal), but should be correct for *most* format strings that are actually in use. Mark, Meador: You did a lot of work on the struct module and of course on issue #3132. Does this look like a reasonable compromise? Did I miss obvious cases (see attachment)? ---------- assignee: skrah components: Interpreter Core files: format.c messages: 167618 nosy: Arfrever, georg.brandl, haypo, mark.dickinson, meador.inge, ncoghlan, pitrou, python-dev, skrah priority: release blocker severity: normal stage: needs patch status: open title: Support unknown formats in memoryview comparisons type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file26720/format.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 14:36:09 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 07 Aug 2012 12:36:09 +0000 Subject: [issue15570] email.header.decode_header parses differently In-Reply-To: <1344316764.02.0.79283890102.issue15570@psf.upfronthosting.co.za> Message-ID: <1344342969.83.0.642144530393.issue15570@psf.upfronthosting.co.za> R. David Murray added the comment: This is an intentional change (see issue 1079). It is entirely possible that this bug fix should be reverted, however, because of backward compatibility concerns. I'm open to that argument, but I'd prefer to keep the fixed behavior, since the unfixed behavior causes us to violate the RFCs in several cases, as you can see from that and the related issues. Note also the availability in 3.3 of the provisional email policies that will do an automatic full decode-to-unicode of such headers. ---------- components: +email -Library (Lib) nosy: +barry, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 15:02:43 2012 From: report at bugs.python.org (Ruben Van Boxem) Date: Tue, 07 Aug 2012 13:02:43 +0000 Subject: [issue12641] Remove -mno-cygwin from distutils In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za> Message-ID: <1344344563.77.0.311745667354.issue12641@psf.upfronthosting.co.za> Ruben Van Boxem added the comment: Checking for a compiler's file name is stupid. Native Windows gcc is just "gcc.exe", Cygwin native GCC is also "gcc". Some have a lot of toolchains in PATH at the same time. That's not the right way to handle this kind of thing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 15:06:24 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 07 Aug 2012 13:06:24 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1344344784.31.0.810229543481.issue15573@psf.upfronthosting.co.za> Nick Coghlan added the comment: I confess I was thinking of an even simpler "format strings must be identical" fallback, but agree your way is better, since it reproduces the 3.2 behaviour in many more cases where ignoring the format string actually did the right thing. The struct docs for the byte order specifier specifically say "the first character of the format string can be used to indicate the byte order, size and alignment of the packed data", so treating format strings that include byte order markers elsewhere in the string as differing from each other if those markers are in different locations sounds fine to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 15:33:34 2012 From: report at bugs.python.org (Daniel Ellis) Date: Tue, 07 Aug 2012 13:33:34 +0000 Subject: [issue15572] Python2 documentation of the file() built-in function In-Reply-To: <1344337126.35.0.910638419892.issue15572@psf.upfronthosting.co.za> Message-ID: <1344346414.73.0.438835481969.issue15572@psf.upfronthosting.co.za> Daniel Ellis added the comment: I've updated the documentation. This is my first patch, so please let me know if I've done something wrong. ---------- keywords: +patch nosy: +Daniel.Ellis Added file: http://bugs.python.org/file26721/file_update.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 16:16:33 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Tue, 07 Aug 2012 14:16:33 +0000 Subject: [issue15500] Python should support naming threads In-Reply-To: <1343650770.87.0.181202709436.issue15500@psf.upfronthosting.co.za> Message-ID: <1344348993.06.0.598983483385.issue15500@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 17:40:04 2012 From: report at bugs.python.org (Matthew Lauber) Date: Tue, 07 Aug 2012 15:40:04 +0000 Subject: [issue8800] add threading.RWLock In-Reply-To: <1274694942.46.0.488506239249.issue8800@psf.upfronthosting.co.za> Message-ID: <1344354004.34.0.286858001311.issue8800@psf.upfronthosting.co.za> Changes by Matthew Lauber : ---------- nosy: +mklauber _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 18:17:28 2012 From: report at bugs.python.org (Dave Malcolm) Date: Tue, 07 Aug 2012 16:17:28 +0000 Subject: [issue9635] Add Py_BREAKPOINT and sys._breakpoint hooks In-Reply-To: <1288718739.38.0.817340636805.issue9635@psf.upfronthosting.co.za> Message-ID: <1344356212.24650.14.camel@surprise> Dave Malcolm added the comment: On Tue, 2010-11-02 at 17:25 +0000, Antoine Pitrou wrote: > Antoine Pitrou added the comment: > > I would rename Py_BREAKPOINT to _Py_BREAKPOINT since we don't really want to support this. Also, why do you allow any arguments to sys._breakpoint()? Agreed about _Py_BREAKPOINT. The reason for allowing arguments to sys._breakpoint() is so that the developer can pass in arbitrary objects (or collections of objects), which can then be easily inspected from the debugger. Does that seem sane? Maybe the docs should read: ------ This may be of use when tracking down bugs: the breakpoint can be guarded by Python-level conditionals, and supply Python-generated data:: if foo and bar and not baz: sys._breakpoint(some_func(foo, bar, baz)) In the above example, if the given python conditional holds (and no exception is raised calling "some_func"), execution will halt under the debugger within Python/sysmodule.c:sys_breakpoint, and the result of some_func() will be inspectable in the debugger as ((PyTupleObject*)args)[0] static PyObject * sys_breakpoint(PyObject *self, PyObject *args) { _Py_BREAKPOINT(); Py_RETURN_NONE; } It can also be useful to call when debugging the CPython interpreter: if you add a call to this function immediately before the code of interest, you can step out of sys_breakpoint and then step through subsequent execution. ------ I thought about it making it METH_O instead (to make it easier to look at a single object), but then you'd be forced to pass an object in when using it, I think (though None should work). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 18:48:18 2012 From: report at bugs.python.org (Leon Maurer) Date: Tue, 07 Aug 2012 16:48:18 +0000 Subject: [issue15574] IDLE crash in OS X even with 2.7.3 and ActiveTcl 8.5.12 Message-ID: <1344358098.04.0.570334143116.issue15574@psf.upfronthosting.co.za> New submission from Leon Maurer: I'm getting crashes with IDLE like those that have been reported before (e.g. by trying to copy using Command-C), but I followed (or at least tried to follow) the directions at http://www.python.org/getit/mac/tcltk/ and have installed Python 2.7.3 64-bit/32-bit and ActiveTcl 8.5.12. I've attached the crash log. I believe the following lines shows that I am using Tk 8.5.12 and not Apple's buggy version: 0x671000 - 0x76fff7 +Tk 8.5.12 (8.5.12) /Library/Frameworks/Tk.framework/Versions/8.5/Tk Thanks. ---------- components: IDLE files: IDLE crash.rtf messages: 167624 nosy: Leon.Maurer priority: normal severity: normal status: open title: IDLE crash in OS X even with 2.7.3 and ActiveTcl 8.5.12 type: crash versions: Python 2.7 Added file: http://bugs.python.org/file26722/IDLE crash.rtf _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 19:12:21 2012 From: report at bugs.python.org (Georg Brandl) Date: Tue, 07 Aug 2012 17:12:21 +0000 Subject: [issue14330] don't use host python, use host search paths for host compiler In-Reply-To: <1331856850.28.0.590122825265.issue14330@psf.upfronthosting.co.za> Message-ID: <1344359541.53.0.706076661712.issue14330@psf.upfronthosting.co.za> Georg Brandl added the comment: Ezio? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 19:12:52 2012 From: report at bugs.python.org (Stefan Krah) Date: Tue, 07 Aug 2012 17:12:52 +0000 Subject: [issue14330] don't use host python, use host search paths for host compiler In-Reply-To: <1331856850.28.0.590122825265.issue14330@psf.upfronthosting.co.za> Message-ID: <1344359572.16.0.852049384198.issue14330@psf.upfronthosting.co.za> Stefan Krah added the comment: Installing dpkg-dev indeed resolved the issue for me on Debian Wheezy, but msg166444 said that the problem appeared in 7955d769fdf5. So was dpkg-dev already an official dependency before 7955d769fdf5 or not? ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 19:24:14 2012 From: report at bugs.python.org (Stefan Krah) Date: Tue, 07 Aug 2012 17:24:14 +0000 Subject: [issue14330] don't use host python, use host search paths for host compiler In-Reply-To: <1331856850.28.0.590122825265.issue14330@psf.upfronthosting.co.za> Message-ID: <1344360254.4.0.127373472819.issue14330@psf.upfronthosting.co.za> Stefan Krah added the comment: With ma.diff from #11715 dpkg-dev is indeed not required (checked on Wheezy). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 20:11:02 2012 From: report at bugs.python.org (Roy Smith) Date: Tue, 07 Aug 2012 18:11:02 +0000 Subject: [issue15575] Tutorial is unclear on multiple imports of a module. Message-ID: <1344363062.87.0.467457264308.issue15575@psf.upfronthosting.co.za> New submission from Roy Smith: Opening this bug at Ben Finney's request. See https://groups.google.com/forum/?fromgroups#!topic/comp.lang.python/wmDUrpW2ZCU for the full thread discussing the problem. Here's a significant excerpt: ------------------------------------------------- The tutorial is misleading on this. It it says plainly: A module can contain executable statements as well as function definitions. [?] They are executed only the *first* time the module is imported somewhere. but it doesn't make clear that a module can exist in the ?sys.modules? list multiple times under different names. ------------------------------------------------- Also note: -------------------------------------------------- The footnote to that is wrong too: > [1] In fact function definitions are also ?statements? that are ?executed?; the execution of a module-level function enters the function name in the module?s global symbol table. I think what it's supposed to say is "... the execution of a module-level def statement ..." --------------------------------------------------- ---------- assignee: docs at python components: Documentation messages: 167628 nosy: docs at python, roysmith priority: normal severity: normal status: open title: Tutorial is unclear on multiple imports of a module. type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 20:29:48 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 07 Aug 2012 18:29:48 +0000 Subject: [issue15575] Tutorial is unclear on multiple imports of a module. In-Reply-To: <1344363062.87.0.467457264308.issue15575@psf.upfronthosting.co.za> Message-ID: <1344364188.69.0.0788156429759.issue15575@psf.upfronthosting.co.za> R. David Murray added the comment: Well, I don't think a full discussion of the subtlety about a module appearing under multiple names belongs in the tutorial, but I think the sentence could be amended to say "Statements in a module are executed only the *first* time the module name is encountered in an import statement". The other is indeed a bug (IMO the sentence is missing the word 'definition', as in 'execution of a function definition'). ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 20:35:50 2012 From: report at bugs.python.org (Stefan Behnel) Date: Tue, 07 Aug 2012 18:35:50 +0000 Subject: [issue15576] importlib: ExtensionFileLoader not used to load packages from __init__.so files Message-ID: <1344364550.12.0.263881849199.issue15576@psf.upfronthosting.co.za> New submission from Stefan Behnel: The new importlib shows a regression w.r.t. previous CPython versions. It no longer recognises an "__init__.so" file as a package. All previous CPython versions have always tested first for an extension file before testing for a .py/.pyc file. The new importlib explicitly excludes the ExtensionFileLoader from loading packages. See importlib/_bootstrap.py, line 1579 onwards: 1579 def _get_supported_file_loaders(): 1580 """Returns a list of file-based module loaders. 1581 1582 Each item is a tuple (loader, suffixes, allow_packages). 1583 """ 1584 extensions = ExtensionFileLoader, _imp.extension_suffixes(), False # <== bug here 1585 source = SourceFileLoader, SOURCE_SUFFIXES, True 1586 bytecode = SourcelessFileLoader, BYTECODE_SUFFIXES, True 1587 return [extensions, source, bytecode] (BTW, I'm not sure what to file this bug against - "Interpreter Core" or "Library"?) ---------- components: Library (Lib) messages: 167630 nosy: scoder priority: normal severity: normal status: open title: importlib: ExtensionFileLoader not used to load packages from __init__.so files type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 20:36:08 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Tue, 07 Aug 2012 18:36:08 +0000 Subject: [issue15501] Document exception classes in subprocess module In-Reply-To: <1343655102.86.0.835171642678.issue15501@psf.upfronthosting.co.za> Message-ID: <1344364568.0.0.44873496244.issue15501@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 20:42:23 2012 From: report at bugs.python.org (Eric Snow) Date: Tue, 07 Aug 2012 18:42:23 +0000 Subject: [issue15576] importlib: ExtensionFileLoader not used to load packages from __init__.so files In-Reply-To: <1344364550.12.0.263881849199.issue15576@psf.upfronthosting.co.za> Message-ID: <1344364943.42.0.861407730397.issue15576@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 20:42:33 2012 From: report at bugs.python.org (Eric Snow) Date: Tue, 07 Aug 2012 18:42:33 +0000 Subject: [issue15576] importlib: ExtensionFileLoader not used to load packages from __init__.so files In-Reply-To: <1344364550.12.0.263881849199.issue15576@psf.upfronthosting.co.za> Message-ID: <1344364953.39.0.917968331409.issue15576@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 20:57:57 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Aug 2012 18:57:57 +0000 Subject: [issue15572] Python2 documentation of the file() built-in function In-Reply-To: <1344337126.35.0.910638419892.issue15572@psf.upfronthosting.co.za> Message-ID: <3Ws4jv0Kj5zQ04@mail.python.org> Roundup Robot added the comment: New changeset db1b4aab53eb by Benjamin Peterson in branch '2.7': make documented file() kw names and actual ones agree (closes #15572) http://hg.python.org/cpython/rev/db1b4aab53eb ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 20:58:11 2012 From: report at bugs.python.org (Roger Serwy) Date: Tue, 07 Aug 2012 18:58:11 +0000 Subject: [issue15574] IDLE crash in OS X even with 2.7.3 and ActiveTcl 8.5.12 In-Reply-To: <1344358098.04.0.570334143116.issue15574@psf.upfronthosting.co.za> Message-ID: <1344365891.81.0.398321948251.issue15574@psf.upfronthosting.co.za> Changes by Roger Serwy : ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 21:02:30 2012 From: report at bugs.python.org (Stefan Behnel) Date: Tue, 07 Aug 2012 19:02:30 +0000 Subject: [issue15576] importlib: ExtensionFileLoader not used to load packages from __init__.so files In-Reply-To: <1344364550.12.0.263881849199.issue15576@psf.upfronthosting.co.za> Message-ID: <1344366150.61.0.400788257641.issue15576@psf.upfronthosting.co.za> Stefan Behnel added the comment: Additional info: working around this bug from user code is fairly involved because some FileLoader instances are already created early at initialisation time and the overall configuration of the FileLoaders is kept in the closure of a path hook. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 21:09:32 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 07 Aug 2012 19:09:32 +0000 Subject: [issue15576] importlib: ExtensionFileLoader not used to load packages from __init__.so files In-Reply-To: <1344364550.12.0.263881849199.issue15576@psf.upfronthosting.co.za> Message-ID: <1344366572.03.0.108442509181.issue15576@psf.upfronthosting.co.za> R. David Murray added the comment: I wouldn't worry about working around it from user code...finding and fixing regressions is what the beta period is for, after all. As for which component, that's a good question with importlib ;) Both, I suppose. Not that components are used for much other than auto-nosy, and there's no auto-nosy for either interpreter core or library. ---------- components: +Interpreter Core nosy: +r.david.murray priority: normal -> release blocker stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 21:17:31 2012 From: report at bugs.python.org (Brett Cannon) Date: Tue, 07 Aug 2012 19:17:31 +0000 Subject: [issue15576] importlib: ExtensionFileLoader not used to load packages from __init__.so files In-Reply-To: <1344364550.12.0.263881849199.issue15576@psf.upfronthosting.co.za> Message-ID: <1344367051.22.0.905953484416.issue15576@psf.upfronthosting.co.za> Brett Cannon added the comment: So this was on purpose. At some point over the past five years I was working on importlib I think I was told I shouldn't support it (or something) as I explicitly remember making the decision to not support __init__.so on purpose. Plus the package specification never suggested anything but __init__.py to be used to begin with, so it isn't a bug as much as a design oversight (as is a large portion of import semantics unfortunately). But I take it Cython has been relying on this for years so that kind of kills treating this as part of import semantics cleanup. Now to reverse this several things need to happen. First the whole third item in the tuples passed to PathFinder is unneeded (it existed purely to block extension module __init__ files) and thus should be removed where necessary. Second, the tests for extensions (test.test_importlib.extension.test_finder) need to be updated, but that gets messy as there is no __init__.so in the stdlib to test against to verify everything works. Tests could cheat and muck with PathFinder's file cache, but that is definitely not a blackbox test anymore. Don't know how best to deal with this short of an xx/__init__.so module being added to the stdlib. And just for future reference, Stefan, since this is a direct import issue and not something to do with importlib's API I consider it an Interpreter Core bug. And I'm glad we cache directory stat results now as changing this will have minuscule overhead compared to adding another stat call per package search without the cache. ---------- components: -Library (Lib) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 21:27:22 2012 From: report at bugs.python.org (Ned Deily) Date: Tue, 07 Aug 2012 19:27:22 +0000 Subject: [issue15574] IDLE crash in OS X even with 2.7.3 and ActiveTcl 8.5.12 In-Reply-To: <1344358098.04.0.570334143116.issue15574@psf.upfronthosting.co.za> Message-ID: <1344367642.55.0.534689990754.issue15574@psf.upfronthosting.co.za> Ned Deily added the comment: Ouch! That appears to be a major regression in the newly released ActiveTcl 8.5.12. I can easily reproduce a crash just using wish8.5 so the problem is strictly in Tcl/Tk itself, not Python. If you have an older version of ActiveTcl 8.5 available, you can revert to that. Unfortunately, ActiveState's policy is to only make the most recent Community Edition release openly available on their website. I've raised this issue on the Mac Tcl mailing list: http://dir.gmane.org/gmane.comp.lang.tcl.mac ---------- assignee: -> ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 21:37:35 2012 From: report at bugs.python.org (Leon Maurer) Date: Tue, 07 Aug 2012 19:37:35 +0000 Subject: [issue15574] IDLE crash in OS X even with 2.7.3 and ActiveTcl 8.5.12 In-Reply-To: <1344358098.04.0.570334143116.issue15574@psf.upfronthosting.co.za> Message-ID: <1344368255.91.0.836317429524.issue15574@psf.upfronthosting.co.za> Leon Maurer added the comment: Thanks for the quick response. I don't have access to an older version of ActiveTcl, but in truth, I'm mostly relieved that it's not just me. (I spent a long time trying to figure out why some Tkinter code I had written would work on Linux and Windows but not OS X...) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 21:39:14 2012 From: report at bugs.python.org (Stefan Behnel) Date: Tue, 07 Aug 2012 19:39:14 +0000 Subject: [issue15576] importlib: ExtensionFileLoader not used to load packages from __init__.so files In-Reply-To: <1344364550.12.0.263881849199.issue15576@psf.upfronthosting.co.za> Message-ID: <1344368354.01.0.0428046822167.issue15576@psf.upfronthosting.co.za> Stefan Behnel added the comment: Hi, thanks for bringing in the 'historical details'. It's not so much that "Cython has been relying on it" - it's entirely up to users what they compile and what not. It's more that I don't see anything being wrong with it as a feature and that it worked before. The reason why I found it was that I'm trying to make Python benchmark suite run better in Cython, and that requires compiling all code, some of which is often hidden in the package file. I understand that this is probably a rare real-world requirement because things can usually be made to work by moving code into a separate extension module and reimporting it from there into an __init__.py module. I guess that's why people told you to drop the feature. There's also issue13429, which still restricts the init time compatibility of binary extensions with normal Python modules. Arguably, to make __init__.so work correctly, the "__path__" attribute would have to be set at module creation time as well, otherwise, relative imports won't work during initialisation. I guess I should update my patch in that ticket to reflect that. ---------- components: +Library (Lib) -Interpreter Core _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 21:40:10 2012 From: report at bugs.python.org (Christian Heimes) Date: Tue, 07 Aug 2012 19:40:10 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1344368410.24.0.7293714301.issue15573@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 22:30:17 2012 From: report at bugs.python.org (Brett Cannon) Date: Tue, 07 Aug 2012 20:30:17 +0000 Subject: [issue15576] importlib: ExtensionFileLoader not used to load packages from __init__.so files In-Reply-To: <1344364550.12.0.263881849199.issue15576@psf.upfronthosting.co.za> Message-ID: <1344371417.54.0.0839764474197.issue15576@psf.upfronthosting.co.za> Brett Cannon added the comment: That's another thing that would need to be changed; ExtensionFileLoader would need to work for is_package() and would need to set __path__ as needed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 22:38:30 2012 From: report at bugs.python.org (nordaux) Date: Tue, 07 Aug 2012 20:38:30 +0000 Subject: [issue15577] Real Argc Argv in embeded interpreter Message-ID: <1344371910.44.0.262957922939.issue15577@psf.upfronthosting.co.za> New submission from nordaux: I have found out certain peculiarity of interpreter in case it is embedded. There is no way to reference to the real parameters argv, argc of main process from embedded python's C extensions. When python is not embedded, it is task of function Py_Main, which sets the value of variables orig_argv, orig_argc. These variables keep references to the original values of argv, argc and give opportunity to manage them from the python C extensions if necessary. I understand that the function Py_GetArgcArgv is rarely used, and this is true, but still believe that ability to manipulate these variables should be exist in any form of python from its C extension modules. I tried different modules of C-extensions with such functional in embedded environment, but they all causes Segmentation Fault. The problem is not only in their implementation quality without any additional inspections, but also the function Py_GetArgcArgv doesn't additionally reported that its returned, and just ruturn null pointer in self argv parameter when used in embedded environment. The following quote all the code that refers to this functionality in Python 2.7-3.3 at the moment: /* For Py_GetArgcArgv(); set by main() */ static char **orig_argv; static int orig_argc; .......................................................................................... /* Main program */ int Py_Main(int argc, char **argv) { .......................................................................................... orig_argc = argc; /* For Py_GetArgcArgv() */ orig_argv = argv; .......................................................................................... } void Py_GetArgcArgv(int *argc, char ***argv) { *argc = orig_argc; *argv = orig_argv; } Thats why I would like to suggest something similar to such function and use it in Py_Main and probably make it available from Python C API. And also extend Py_GetArgcArgv with more detailed null pointer handling if variables orig_argv, orig_argc had not been initialized. void Py_InitArgcArgv(int *argc, char ***argv) { if(! *argv) return -1; orig_argc = *argc; /* For Py_GetArgcArgv() */ orig_argv = *argv; return 0; } Would like to see other suggestions. Thanks. ---------- components: Extension Modules, Interpreter Core messages: 167639 nosy: nordaux priority: normal severity: normal status: open title: Real Argc Argv in embeded interpreter type: crash versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 22:42:54 2012 From: report at bugs.python.org (nordaux) Date: Tue, 07 Aug 2012 20:42:54 +0000 Subject: [issue15577] Real Argc Argv in embedded interpreter In-Reply-To: <1344371910.44.0.262957922939.issue15577@psf.upfronthosting.co.za> Message-ID: <1344372174.87.0.509602664735.issue15577@psf.upfronthosting.co.za> Changes by nordaux : ---------- title: Real Argc Argv in embeded interpreter -> Real Argc Argv in embedded interpreter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 22:50:30 2012 From: report at bugs.python.org (Thomas Wouters) Date: Tue, 07 Aug 2012 20:50:30 +0000 Subject: [issue15578] Crash when modifying sys.modules during import Message-ID: <1344372630.36.0.657008264392.issue15578@psf.upfronthosting.co.za> New submission from Thomas Wouters: In a submodule of a package, replacing the parent package in sys.modules during import of the package (meaning the only reference to it is in sys.modules) and then importing itself (or something from itself) crashes the interpreter: centurion:~/python/crasher > cat sa/__init__.py import v1 centurion:~/python/crasher > cat sa/v1/__init__.py import sys sys.modules['sa'] = sys.modules[__name__] import sa centurion:~/python/crasher > python -c 'import sa' Segmentation fault (core dumped) It seems the crash is not entirely deterministic, as we've had the original code this was reduced from run in Python 2.4 and 2.6 for years, and only discovered the crash when switching to 2.7. However, running the reduced testcase crashes for me in all of Python 2.7, 2.6, 2.4 and 2.2, in debug builds and opt builds. Given the nature of the bug I expect debug builds to crash reliably. I haven't found the actual source of the problem, but what seems to happen is that the import mechanism has a borrowed reference to the 'sa' module around, assuming it'll stay alive while the submodules are imported because it's also stored in sys.modules. This assumption is incorrect. However, changing the import in sa/__init__.py into an absolute or explicit relative import seems to fix the problem, which means this probably won't affect Python 3. ---------- components: Interpreter Core messages: 167640 nosy: twouters priority: normal severity: normal status: open title: Crash when modifying sys.modules during import type: crash versions: Python 2.6, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 23:19:57 2012 From: report at bugs.python.org (Karen KarenL) Date: Tue, 07 Aug 2012 21:19:57 +0000 Subject: [issue9890] Visual C++ Runtime Library Error is there a fix? In-Reply-To: <50208B19.9080809@gmail.com> Message-ID: Karen KarenL added the comment: Yes. It is the same bug. And changing pythonhome path from c:\python26 to c:\python32 fixes the problem. My initial google search found bug 9890, but not 11288. Let me know if there is anything I can do. Karen On Mon, Aug 6, 2012 at 8:27 PM, Roger Serwy wrote: > > Roger Serwy added the comment: > > Karen, thank you for your reply and your cooperation. This issue may > take some time to resolve. > > It looks like the error you are receiving has been addressed in > issue11288. Can you check it out? > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 23:21:40 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 07 Aug 2012 21:21:40 +0000 Subject: [issue15578] Crash when modifying sys.modules during import In-Reply-To: <1344372630.36.0.657008264392.issue15578@psf.upfronthosting.co.za> Message-ID: <1344374500.35.0.349126696233.issue15578@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 23:24:31 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 07 Aug 2012 21:24:31 +0000 Subject: [issue15578] Crash when modifying sys.modules during import In-Reply-To: <1344372630.36.0.657008264392.issue15578@psf.upfronthosting.co.za> Message-ID: <1344374671.56.0.38683890128.issue15578@psf.upfronthosting.co.za> R. David Murray added the comment: If I remember correctly there were non-trivial improvements made to the way modules are finalized in 2.7 compared to earlier versions. That could be what exposed the bug. The pre-2.7 code might have been leaving another reference alive because of your more complex real world example, whereas the simplified example doesn't. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 7 23:30:35 2012 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 07 Aug 2012 21:30:35 +0000 Subject: [issue14330] don't use host python, use host search paths for host compiler In-Reply-To: <1331856850.28.0.590122825265.issue14330@psf.upfronthosting.co.za> Message-ID: <1344375035.94.0.851773238558.issue14330@psf.upfronthosting.co.za> Ezio Melotti added the comment: On another Ubuntu 12.04 machine with dpkg-dev installed I didn't have any issue. Once I removed dpkg-dev I was able to reproduce the issue again. Applying ma.diff from #11715 solves the issue, with and without dpkg-dev installed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 00:05:56 2012 From: report at bugs.python.org (Ned Deily) Date: Tue, 07 Aug 2012 22:05:56 +0000 Subject: [issue15574] IDLE crash in OS X even with 2.7.3 and ActiveTcl 8.5.12 In-Reply-To: <1344358098.04.0.570334143116.issue15574@psf.upfronthosting.co.za> Message-ID: <1344377156.62.0.163130846769.issue15574@psf.upfronthosting.co.za> Ned Deily added the comment: The Mac Tcl community has jumped on the problem and there is now a tentative patch for Tk: http://permalink.gmane.org/gmane.comp.lang.tcl.core/14173 I've opened a formal issue on the Tcl/Tk bug tracker here: https://sourceforge.net/tracker/?func=detail&aid=3555211&group_id=12997&a tid=112997 I'll leave this issue in pending status until the fix has been released and verified in a version of ActiveTcl. Thanks for the report! ---------- resolution: -> out of date status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 00:10:46 2012 From: report at bugs.python.org (axw) Date: Tue, 07 Aug 2012 22:10:46 +0000 Subject: [issue15579] some unicode keys not found using in dictionary.keys() Message-ID: <1344377446.47.0.0219808809776.issue15579@psf.upfronthosting.co.za> New submission from axw: This simple snippet demonstrates the misbehaviour. Confirmed on two amd64 machines, python 2.7.3. ################### import copy uzlist = [u'abc', u'def', u'ghj', u'klm', u'zxc'] utzdict = {u'abc':1, u'def':2, u'ghj':3, u'klm':4, u'zxc':5} utemplist = copy.copy(uzlist) for m in utemplist: if m in utzdict.keys(): utemplist.remove(m) # utemplist should be empty now - it is not! >>> utemplist [u'def', u'klm'] utemplist = copy.copy(uzlist) for i in range(len(uzlist)): try: if utzdict[ uzlist[i] ]: utemplist.remove( uzlist[i] ) except KeyError: pass # utemplist should be empty now. This time it is: >>> utemplist [] ---------- components: Interpreter Core, Unicode messages: 167645 nosy: axw, ezio.melotti priority: normal severity: normal status: open title: some unicode keys not found using in dictionary.keys() type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 00:13:30 2012 From: report at bugs.python.org (Ned Deily) Date: Tue, 07 Aug 2012 22:13:30 +0000 Subject: [issue15574] IDLE crashes using clipboard copy command on OS X with ActiveTcl 8.5.12 In-Reply-To: <1344358098.04.0.570334143116.issue15574@psf.upfronthosting.co.za> Message-ID: <1344377610.63.0.347742150589.issue15574@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- status: pending -> open title: IDLE crash in OS X even with 2.7.3 and ActiveTcl 8.5.12 -> IDLE crashes using clipboard copy command on OS X with ActiveTcl 8.5.12 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 00:14:01 2012 From: report at bugs.python.org (Ned Deily) Date: Tue, 07 Aug 2012 22:14:01 +0000 Subject: [issue15574] IDLE crashes using clipboard copy command on OS X with ActiveTcl 8.5.12 In-Reply-To: <1344358098.04.0.570334143116.issue15574@psf.upfronthosting.co.za> Message-ID: <1344377641.52.0.590515891053.issue15574@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- status: open -> pending versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 00:15:58 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 07 Aug 2012 22:15:58 +0000 Subject: [issue15579] some unicode keys not found using in dictionary.keys() In-Reply-To: <1344377446.47.0.0219808809776.issue15579@psf.upfronthosting.co.za> Message-ID: <1344377758.84.0.88970436234.issue15579@psf.upfronthosting.co.za> R. David Murray added the comment: In the first example you are shrinking the list you are iterating over, so not all of the items in the list are going to be tested. Try doing for m in uzlist instead. ---------- nosy: +r.david.murray resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 00:24:21 2012 From: report at bugs.python.org (axw) Date: Tue, 07 Aug 2012 22:24:21 +0000 Subject: [issue15579] some unicode keys not found using in dictionary.keys() In-Reply-To: <1344377446.47.0.0219808809776.issue15579@psf.upfronthosting.co.za> Message-ID: <1344378261.67.0.836604147529.issue15579@psf.upfronthosting.co.za> axw added the comment: Thanks, I did not realize that. The behaviour is obviously correct. ---------- resolution: invalid -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 00:29:55 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 07 Aug 2012 22:29:55 +0000 Subject: [issue15579] some unicode keys not found using in dictionary.keys() In-Reply-To: <1344377446.47.0.0219808809776.issue15579@psf.upfronthosting.co.za> Message-ID: <1344378595.83.0.562020599629.issue15579@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- resolution: -> invalid _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 03:49:38 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 08 Aug 2012 01:49:38 +0000 Subject: [issue15580] fix True/False/None reST markup Message-ID: <1344390578.71.0.326693298402.issue15580@psf.upfronthosting.co.za> New submission from Chris Jerdonek: The Dev Guide says not to markup True, False, and None in the documentation in a way that generates a link (e.g. ":const:`True`") because "they?re fundamental to the language and should be known to any programmer": http://docs.python.org/devguide/documenting.html#documenting Rather, it says to use "``True``" (and similarly for False and None): This issue is to update the documentation to conform to this guidance. While working on the documentation, I noticed many occurrences of ":const:`True`", for example. See here for some examples, where you can see the hyperlinks: http://docs.python.org/dev/library/tarfile.html#tarfile.TarFile.add ---------- assignee: docs at python components: Documentation messages: 167648 nosy: cjerdonek, docs at python priority: normal severity: normal status: open title: fix True/False/None reST markup _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 03:49:51 2012 From: report at bugs.python.org (Meador Inge) Date: Wed, 08 Aug 2012 01:49:51 +0000 Subject: [issue15424] __sizeof__ of array should include size of items In-Reply-To: <1342974161.65.0.374402048104.issue15424@psf.upfronthosting.co.za> Message-ID: <1344390591.6.0.515042989101.issue15424@psf.upfronthosting.co.za> Meador Inge added the comment: Georg, yet another __sizeof__ fix. OK for 3.3? ---------- nosy: +georg.brandl stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 03:53:22 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 08 Aug 2012 01:53:22 +0000 Subject: [issue15580] fix True/False/None reST markup In-Reply-To: <1344390578.71.0.326693298402.issue15580@psf.upfronthosting.co.za> Message-ID: <1344390802.48.0.296522668118.issue15580@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Here is a command to find the file names of all occurrences: find Doc -type f -name *.rst | xargs grep -ERl ":const:\`(True|False|None)\`" The occurrences are in the following directories: Doc/c-api/ Doc/library/ Doc/reference/ Doc/whatsnew/ And here are commands to do the replacement on a branch. # Replace the occurrences inside tables, to preserve table alignment. find Doc/c-api/ Doc/library/ Doc/reference/ -type f -name *.rst | \ xargs sed -i '' \ -e 's/\(\|.*\):const:`True`/\1``True`` /g' \ -e 's/\(\|.*\):const:`False`/\1``False`` /g' \ -e 's/\(\|.*\):const:`None`/\1``None`` /g' # Replace the rest of the occurrences. find Doc/c-api/ Doc/library/ Doc/reference/ -type f -name *.rst | \ xargs sed -i '' \ -e 's/:const:`True`/``True``/g' \ -e 's/:const:`False`/``False``/g' \ -e 's/:const:`None`/``None``/g' I left out Doc/whatsnew/ because the What's New is historical and because it includes entries describing the introduction of True/False, which may be considered special. Incidentally, the constants documentation of True/False/None link to the descriptions using ":data:`True`", etc, so they are not affected by this change: http://docs.python.org/dev/library/constants.html#built-in-constants To commit, the commands above could be run on a branch and committed, then merged forward to newer branches, and then the scripts re-run on the next newer branch to catch new introductions of True/False/None, and so on. For illustration purposes only, I'm attaching the patch that results from running the script on the default branch. ---------- keywords: +patch Added file: http://bugs.python.org/file26723/script-result-default-branch.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 03:54:07 2012 From: report at bugs.python.org (Greg Ward) Date: Wed, 08 Aug 2012 01:54:07 +0000 Subject: [issue15510] textwrap.wrap('') returns empty list In-Reply-To: <1343697979.41.0.629576632811.issue15510@psf.upfronthosting.co.za> Message-ID: <1344390847.57.0.952135492574.issue15510@psf.upfronthosting.co.za> Greg Ward added the comment: Random comments from original author of textwrap.py, in case anyone cares at this point... * This is a pretty obscure edge case, and I admit that it never occurred to me when writing the code. (If it had, I would have tested it!) * One can debate endlessly about whether this is a bug or not -- witness the recent discussion on this bug. Meh. Not interesting. IMHO it's better described as undefined behaviour. If you want it defined, write tests to enforce the status quo and improve the docs. * If there is a consensus to change the current behaviour, IMHO it should NOT be done on 2.7. Even if the new behaviour is better by some definition, it's still a behaviour change that could bite someone. Those changes should happen when you make a major upgrade (3.2 to 3.3, say), not when you make a bug fix upgrade (2.7.3 to 2.7.4). IOW: keep it on trunk. Or default, whatever we're calling it these days. ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 04:22:48 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 08 Aug 2012 02:22:48 +0000 Subject: [issue15510] textwrap.wrap('') returns empty list In-Reply-To: <1343697979.41.0.629576632811.issue15510@psf.upfronthosting.co.za> Message-ID: <1344392568.77.0.994801768422.issue15510@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Thanks for weighing in, Greg! At least for me, this edge case was important because it determines how the canonical advice or recipe for handling multiple paragraphs behaves when the input string has line breaks in between paragraphs. That advice, of course, is to call splitlines(), pass the individual paragraphs to wrap(), and then join on newlines. Here is an example on a paragraph with line breaks between paragraphs: >>> def wrap_paras(text, width=70, **kwargs): ... lines = [line for para in text.splitlines() ... for line in wrap(para, width, **kwargs)] ... return "\n".join(lines) ... >>> text = """\ ... abcd abcd ... ... abcd abcd""" >>> print(wrap_paras(text)) abcd abcd abcd abcd The edge case we're discussing determines whether line breaks between paragraphs are preserved in the result. (With current behavior, they are not.) > If you want it defined, write tests to enforce the status quo and improve the docs. Given the discussion so far (and in particular, opposition to changing behavior), this is the route I'm hoping we can go. Interesting or not, I think it's good that we at least had this discussion before setting the behavior in stone. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 04:35:56 2012 From: report at bugs.python.org (hut) Date: Wed, 08 Aug 2012 02:35:56 +0000 Subject: [issue15581] curses: segfault in addstr() Message-ID: <1344393356.61.0.716752115095.issue15581@psf.upfronthosting.co.za> New submission from hut: Under certain circumstances, the curses function addstr() will cause a segfault in python3.2.3 and python2.7.3. Necessary, but not sufficient conditions are: 1. the window has been resized while curses was running 2. addstr() attempts to write a string that doesn't fit into the window, resulting in the cursors y-position being outside of the boundaries (which would normally only raise a _curses.error) Instead of the "Segmentation Fault" message, I also sometimes get one of these two messages when python crashes: *** glibc detected *** python2.7: corrupted double-linked list: 0x0949cc98 *** python2.7: malloc.c:3964: _int_free: Assertion `nextchunk->fd_nextsize->bk_nextsize == nextchunk' failed. To my shame, I didn't try to debug python myself, and I can't offer a minimal program to reproduce this bug, but I did find a way to reproduce it in the python program "ranger": Link to the bug in rangers bug tracker with steps to reproduce: https://github.com/hut/ranger/issues/45 Download link to the affected version of ranger: https://github.com/hut/ranger/tarball/5ee1e874cc5f9136af3a9a835b76076a85693bd0 ---------- components: Extension Modules messages: 167653 nosy: hut priority: normal severity: normal status: open title: curses: segfault in addstr() versions: Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 04:52:14 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 08 Aug 2012 02:52:14 +0000 Subject: [issue15582] Enhance inspect.getdoc to follow inheritance chains Message-ID: <1344394334.01.0.280520797106.issue15582@psf.upfronthosting.co.za> New submission from Nick Coghlan: Currently, if you override a method from a base class, the docstring is not inherited, even if it remains accurate. This issue proposes an enhancement to inspect.getdoc() that allows the docstring to be retrieved from the inheritance hierarchy in the case where it is not overridden in the subclass by providing an explicit docstring. Specifically, in the case where obj.__doc__ is None, and either the first parameter is a bound method, or a class object is passed in as the second parameter, inspect.getdoc will search the MRO based on obj.__name__ until it finds an attribute with a non-None __doc__ value. (In Python 2, this could have been automatic for both bound and unbound methods. Unfortunately, there are no unbound methods in Python 3, so the second parameter is needed to handle the unbound method case) ---------- components: Library (Lib) messages: 167654 nosy: eric.snow, ncoghlan priority: normal severity: normal stage: needs patch status: open title: Enhance inspect.getdoc to follow inheritance chains type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 04:52:23 2012 From: report at bugs.python.org (Meador Inge) Date: Wed, 08 Aug 2012 02:52:23 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1344394343.43.0.0344458725515.issue15573@psf.upfronthosting.co.za> Meador Inge added the comment: I agree that the general case is complicated. It will get even more complicated if the full of PEP 3118 gets implemented since it turns into a tree comparison. In general, I think you will probably have to compute some canonical form and then compare the canonical forms. Here are a few more cases that don't work out in the attached algorithm: 1. Repeat characters - '2c' == 'cc' 2. Whitespace - 'h h' == 'hh' Also, currently the byte order specifiers are always at the beginning of the string. We discussed in issue3132 scoping them per the nested structures, but decided to drop that unless somebody barks about it since it is fairly complicated without a clear benefit. So, I wouldn't worry about them being scattered through the string. This seems like sort of a slippery slope. I need to think about it more, but my first impression is that coming up with some way to compare format strings is going to be nasty. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 05:10:52 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 08 Aug 2012 03:10:52 +0000 Subject: [issue15580] fix True/False/None reST markup In-Reply-To: <1344390578.71.0.326693298402.issue15580@psf.upfronthosting.co.za> Message-ID: <1344395452.67.0.784034107203.issue15580@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- stage: -> patch review versions: +Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 06:16:24 2012 From: report at bugs.python.org (Meador Inge) Date: Wed, 08 Aug 2012 04:16:24 +0000 Subject: [issue14182] collections.Counter equality test thrown-off by zero counts In-Reply-To: <1330769404.28.0.817906963132.issue14182@psf.upfronthosting.co.za> Message-ID: <1344399384.1.0.00788528210284.issue14182@psf.upfronthosting.co.za> Meador Inge added the comment: Ah, good examples Mark. So, why is it ever useful keep a key with a value of zero? In other words, why: >>> Counter(a=0) Counter({'a': 0}) instead of: >>> Counter(a=0) Counter() ? The latter seems more consistent to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 06:27:01 2012 From: report at bugs.python.org (Sarbjit singh) Date: Wed, 08 Aug 2012 04:27:01 +0000 Subject: [issue15583] Provide examples in Python doc for usage of various modules Message-ID: <1344400021.49.0.93410153522.issue15583@psf.upfronthosting.co.za> New submission from Sarbjit singh: For beginners who are learning Python, it would be very helpful if Python doc could provide examples on usage of various methods/attributes of different modules. For eg: If you look at ElementTree XMl module or take any other standard module, examples which are provided are very limited making it hard for new users to learn those modules and have to search internet for its usage. Providing examples on usage of module attributes/methods will help users to quickly understand it. ---------- assignee: docs at python components: Documentation messages: 167657 nosy: Sarbjit.singh, docs at python priority: normal severity: normal status: open title: Provide examples in Python doc for usage of various modules type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 06:30:41 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 08 Aug 2012 04:30:41 +0000 Subject: [issue15561] update subprocess docs to reference io.TextIOWrapper In-Reply-To: <1344196317.87.0.366111796882.issue15561@psf.upfronthosting.co.za> Message-ID: <1344400241.13.0.792041476284.issue15561@psf.upfronthosting.co.za> Chris Jerdonek added the comment: io module experts: Can one of you review this minor change to the subprocess documentation to make it reference the newly added io.TextIOWrapper documentation changes? For background purposes, digging back, it looks like the original change to subprocess was made here: 9ce8fa0a0899 ---------- nosy: +benjamin.peterson, hynek, pitrou, stutzbach versions: +Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 06:34:28 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 08 Aug 2012 04:34:28 +0000 Subject: [issue15583] Provide examples in Python doc for usage of various modules In-Reply-To: <1344400021.49.0.93410153522.issue15583@psf.upfronthosting.co.za> Message-ID: <1344400468.25.0.926899176785.issue15583@psf.upfronthosting.co.za> Ezio Melotti added the comment: > If you look at ElementTree XMl module or take any other > standard module, examples which are provided are very limited We already try to provide examples where/when appropriate, and several modules have examples showing the basic usage. Often, documenting all the methods will only make the documentation less readable, so only the most important/common functions/methods have examples. Some modules also have separate howtos that contain extensive examples. If you think some specific module (like ElementTree) needs more examples, feel free to open specific reports. ---------- nosy: +eli.bendersky, ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 07:03:25 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 08 Aug 2012 05:03:25 +0000 Subject: [issue15580] fix True/False/None reST markup In-Reply-To: <1344390578.71.0.326693298402.issue15580@psf.upfronthosting.co.za> Message-ID: <1344402205.84.0.582190784501.issue15580@psf.upfronthosting.co.za> R. David Murray added the comment: I think changing these is unnecessary churn. Change them when you change surrounding text, just like we refrain from refactoring for PEP 8 compliance, etc, unless we are changing the code for other reasons. There is nothing *wrong* with these being links, it just isn't necessary. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 07:07:47 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 08 Aug 2012 05:07:47 +0000 Subject: [issue15583] Provide examples in Python doc for usage of various modules In-Reply-To: <1344400021.49.0.93410153522.issue15583@psf.upfronthosting.co.za> Message-ID: <1344402467.4.0.589380432227.issue15583@psf.upfronthosting.co.za> R. David Murray added the comment: I'm closing this with no specific resolution because the real resolution is "this issue is too general" :) As Ezio said, specific suggestions are welcome, but should be in separate issues limited to the module/example proposed. ---------- nosy: +r.david.murray stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 07:17:07 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Wed, 08 Aug 2012 05:17:07 +0000 Subject: [issue15584] os.popen deprecation warning not in Python 3 docs Message-ID: <1344403027.9.0.851552943116.issue15584@psf.upfronthosting.co.za> New submission from Ramchandra Apte: The os.popen deprecation warning is not in the Python 3 docs! ---------- assignee: docs at python components: Documentation messages: 167662 nosy: docs at python, ramchandra.apte priority: normal severity: normal status: open title: os.popen deprecation warning not in Python 3 docs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 07:18:24 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Wed, 08 Aug 2012 05:18:24 +0000 Subject: [issue15585] usage of os.popen in standard library Message-ID: <1344403104.8.0.699404283397.issue15585@psf.upfronthosting.co.za> New submission from Ramchandra Apte: The following standard library modules use os.popen which is deprecated. These calls should be replaced with calls to subprocess.Popen . Ironically, even the subprocess module uses os.popen! webbrowser.py: osapipe = os.popen("osascript", "w") webbrowser.py: osapipe = os.popen("osascript", "w") pydoc.py: pipe = os.popen(cmd, 'w') uuid.py: with os.popen(cmd) as pipe: uuid.py: pipe = os.popen(os.path.join(dir, 'ipconfig') + ' /all') platform.py:# to cover up situations where platforms don't have os.popen platform.py: This is mostly needed in case os.popen() is not available, or platform.py: # over os.popen over _popen platform.py: popen = os.popen platform.py: f = os.popen('uname %s 2> %s' % (option, DEV_NULL)) platform.py: f = os.popen('file -b "%s" 2> %s' % (target, DEV_NULL)) idlelib/IOBinding.py: pipe = os.popen(command, "r") os.py:# Supply os.popen() subprocess.py: Execute the string 'cmd' in a shell with os.popen() and return a 2-tuple subprocess.py: Execute the string 'cmd' in a shell with os.popen() and return a 2-tuple subprocess.py: pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r') multiprocessing/__init__.py: with os.popen(comm) as p: pipes.py:for the built-in function open() or for os.popen(). pipes.py: return os.popen(cmd, 'r') pipes.py: return os.popen(cmd, 'w') ctypes/util.py: f = os.popen(cmd) ctypes/util.py: with contextlib.closing(os.popen(cmd)) as f: ctypes/util.py: f = os.popen(cmd) ctypes/util.py: with contextlib.closing(os.popen(cmd)) as f: ctypes/util.py: with contextlib.closing(os.popen('/sbin/ldconfig -r 2>/dev/null')) as f: ctypes/util.py: with contextlib.closing(os.popen('LC_ALL=C LANG=C /sbin/ldconfig -p 2>/dev/null')) as f: distutils/command/bdist_rpm.py: out = os.popen(q_cmd) distutils/emxccompiler.py: out = os.popen(gcc_exe + ' -dumpversion','r') ---------- components: Library (Lib) messages: 167663 nosy: ramchandra.apte priority: normal severity: normal status: open title: usage of os.popen in standard library versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 07:19:21 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Wed, 08 Aug 2012 05:19:21 +0000 Subject: [issue15585] usage of os.popen in standard library In-Reply-To: <1344403104.8.0.699404283397.issue15585@psf.upfronthosting.co.za> Message-ID: <1344403161.71.0.754894654427.issue15585@psf.upfronthosting.co.za> Ramchandra Apte added the comment: Sorry, os.py:# Supply os.popen() should not be in the list. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 07:20:47 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Wed, 08 Aug 2012 05:20:47 +0000 Subject: [issue15577] Real argc and argv in embedded interpreter In-Reply-To: <1344371910.44.0.262957922939.issue15577@psf.upfronthosting.co.za> Message-ID: <1344403247.22.0.0365888731984.issue15577@psf.upfronthosting.co.za> Changes by Ramchandra Apte : ---------- title: Real Argc Argv in embedded interpreter -> Real argc and argv in embedded interpreter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 08:04:33 2012 From: report at bugs.python.org (Georg Brandl) Date: Wed, 08 Aug 2012 06:04:33 +0000 Subject: [issue15580] fix True/False/None reST markup In-Reply-To: <1344390578.71.0.326693298402.issue15580@psf.upfronthosting.co.za> Message-ID: <1344405872.82.0.828393243471.issue15580@psf.upfronthosting.co.za> Georg Brandl added the comment: Agreed with David. ---------- nosy: +georg.brandl resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 08:09:21 2012 From: report at bugs.python.org (Georg Brandl) Date: Wed, 08 Aug 2012 06:09:21 +0000 Subject: [issue15424] __sizeof__ of array should include size of items In-Reply-To: <1342974161.65.0.374402048104.issue15424@psf.upfronthosting.co.za> Message-ID: <1344406159.84.0.322235300886.issue15424@psf.upfronthosting.co.za> Georg Brandl added the comment: LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 08:14:49 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 08 Aug 2012 06:14:49 +0000 Subject: [issue15580] fix True/False/None reST markup In-Reply-To: <1344390578.71.0.326693298402.issue15580@psf.upfronthosting.co.za> Message-ID: <1344406489.39.0.927319759555.issue15580@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Yes, I can see the trade off. However, is there a sense in which the situation for documentation could be different from the situation for code? With code, style and refactoring changes cause churn without directly benefiting the end user (because code is just a means and not the end). We can hold off on refactoring without impacting the end user. With documentation though, these are visible, albeit small changes that will directly improve the user's experience. We would be holding off on improving the pages for the sake of internal churn. (If it was refactoring reST in a way that didn't change the HTML output, it would be a different story.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 08:18:20 2012 From: report at bugs.python.org (Stephen Webber) Date: Wed, 08 Aug 2012 06:18:20 +0000 Subject: [issue14182] collections.Counter equality test thrown-off by zero counts In-Reply-To: <1330769404.28.0.817906963132.issue14182@psf.upfronthosting.co.za> Message-ID: <1344406700.55.0.721558952141.issue14182@psf.upfronthosting.co.za> Stephen Webber added the comment: Hmm, that is odd behavior indeed. I think having keys that point to zero values is important for iterating over a set. For example: >>> x = Counter(a=10, b=0) >>> for k in set(x): ... x[k] += 1 ... >>> x Counter({'a': 11, 'b': 1}) is probably preferable to >>> x = Counter(a=10, b=0) >>> for k in set(x): ... x[k] += 1 ... >>> x Counter({'a': 11}) Perhaps to ensure intuitive behavior we could ensure that >>> Counter(a = 3) + Counter(b = 0) == Counter(a = 3, b = 0) True by aggregating all keys into the new Counter object, even those with zero values? I would be happy to make such a patch, as it would be good experience for me to learn. Would this be an acceptable solution, and is there other odd behavior at work here? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 08:22:46 2012 From: report at bugs.python.org (Georg Brandl) Date: Wed, 08 Aug 2012 06:22:46 +0000 Subject: [issue15580] fix True/False/None reST markup In-Reply-To: <1344390578.71.0.326693298402.issue15580@psf.upfronthosting.co.za> Message-ID: <1344406966.9.0.0743007101614.issue15580@psf.upfronthosting.co.za> Georg Brandl added the comment: We have to draw the line somewhere. Otherwise there will be dozens of issues like this, introducing potential breakage and costing developer time that can better be spent elsewhere. The rule in the devguide is mostly there so that developers don't bother writing more than they have to (since None/True/False occur so often typing the link every time will feel painful after a few times). If the link is already written, it does absolutely no harm, as David said. Therefore, there is no actual improvement as you claim. This is nothing against you and your efforts, Chris -- you've already helped improve the docs quite a lot. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 08:34:39 2012 From: report at bugs.python.org (Sarbjit singh) Date: Wed, 08 Aug 2012 06:34:39 +0000 Subject: [issue15586] Provide some examples for usage of ElementTree methods/attributes Message-ID: <1344407679.24.0.102359835139.issue15586@psf.upfronthosting.co.za> New submission from Sarbjit singh: Please provide some basic usage examples for ElementTree module documentation. While parsing an xml, most common scenarios will be reading elements from xml, modifying elements, removal of elements. Though there are few examples given for modification of xml element. But if you look from beginners learning point of view, its very hard to just get any idea from the example that is currently provided. There is lot of text there, but what would be more helpful is some small examples for each function so that user can quickly understand its usage there only. I myself is learning Python, but in order to start using this module, i had to search lot of articles on internet on usage of this module. If we could have provided some basic use cases in Python doc itself, user would not have to rely on external sources for learning its usage. Some Basic Scenarios: 1) Parsing an xml and finding some elements of xml 2) deletion of an element from an xml and writing back 3) Modification of an xml element 4) Usage of XPath queries (some basic usage) ---------- assignee: docs at python components: Documentation messages: 167670 nosy: Sarbjit.singh, docs at python, eli.bendersky priority: normal severity: normal status: open title: Provide some examples for usage of ElementTree methods/attributes type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 08:38:36 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 08 Aug 2012 06:38:36 +0000 Subject: [issue15586] Provide some examples for usage of ElementTree methods/attributes In-Reply-To: <1344407679.24.0.102359835139.issue15586@psf.upfronthosting.co.za> Message-ID: <1344407916.09.0.636453948827.issue15586@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 Aug 8 09:20:17 2012 From: report at bugs.python.org (Tyler Crompton) Date: Wed, 08 Aug 2012 07:20:17 +0000 Subject: [issue15587] IDLE is pixelated on the Macbook Pro with Retina Display Message-ID: <1344410417.58.0.332657489061.issue15587@psf.upfronthosting.co.za> New submission from Tyler Crompton: I think this is more of a Tkinter issue than IDLE but since IDLE uses Tkinter, it inherits this "bug". Many programs that were not developed for the Macbook Pro with Retina Display still look great. Whereas others, look pixelated in some areas (i.e. the current stable release of Google Chrome IIRC (I installed the beta to get around that)), and some are just flat out pixelated everywhere. IDLE falls into the latter category. I know IDLE really has its issues and that few people use it, but it's a cosmetic change that I don't see being too difficult. Then again, I know hardly anything about how it is implemented. ---------- components: IDLE, Tkinter files: Screen Shot 2012-08-08 at 2.07.19 AM.png messages: 167671 nosy: Tyler.Crompton priority: normal severity: normal status: open title: IDLE is pixelated on the Macbook Pro with Retina Display type: enhancement versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file26724/Screen Shot 2012-08-08 at 2.07.19 AM.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 09:30:59 2012 From: report at bugs.python.org (patrick vrijlandt) Date: Wed, 08 Aug 2012 07:30:59 +0000 Subject: [issue15588] quopri: encodestring and decodestring handle bytes, not strings Message-ID: <1344411059.45.0.404148694214.issue15588@psf.upfronthosting.co.za> New submission from patrick vrijlandt: quopri.py's functions encodestring and decodestring are documented to handle strings; and this is clearly suggested by their name. However, these functions accept and return bytes, not strings. This should be reflected in the documentation. Even better: deprecate these functions and introduce new ones with behaviour as suggested by their names: encode_string, encode_bytes etc. ---------- assignee: docs at python components: Documentation, Library (Lib) messages: 167672 nosy: docs at python, patrick.vrijlandt priority: normal severity: normal status: open title: quopri: encodestring and decodestring handle bytes, not strings type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 09:40:10 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 08 Aug 2012 07:40:10 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1317341390.65.0.255779328054.issue13072@psf.upfronthosting.co.za> Message-ID: <1344411610.86.0.765508593289.issue13072@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Someone broke the Windows buildbots. ---------- assignee: -> haypo stage: committed/rejected -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 09:40:27 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 08 Aug 2012 07:40:27 +0000 Subject: [issue14182] collections.Counter equality test thrown-off by zero counts In-Reply-To: <1330769404.28.0.817906963132.issue14182@psf.upfronthosting.co.za> Message-ID: <1344411627.1.0.477069269576.issue14182@psf.upfronthosting.co.za> Raymond Hettinger added the comment: At its most basic, a Counter is simply a dictionary with a __missing__ method that supplies a default of zero. It is intentional that everything else behaves as much like a regular dictionary as possible. You're allowed to store *anything* in the dict values even if those values don't represent numbers. A consequence is that equality is taken to mean the same a regular dict equality. The unary-plus is provided as a way to eliminate zeros from a Counter prior to doing a Counter equality test. Other designs were possible (such as my Bag class mentioned in the docs). This one was selected for its versatility, but it does present challenges with respect to zeros, negatives, fractions, etc. I recognize your concern but find it to be at odds with the basic design of the class. You might be happier with a Multiset class that restricts itself to positive integer counts. ---------- priority: normal -> low resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 09:59:04 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 08 Aug 2012 07:59:04 +0000 Subject: [issue15475] Correct __sizeof__ support for itertools In-Reply-To: <1343418242.58.0.256146467281.issue15475@psf.upfronthosting.co.za> Message-ID: <1344412744.17.0.0309379194576.issue15475@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 10:06:26 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 08 Aug 2012 08:06:26 +0000 Subject: [issue15544] math.isnan fails with some Decimal NaNs In-Reply-To: <1343962443.78.0.878505736017.issue15544@psf.upfronthosting.co.za> Message-ID: <1344413186.44.0.841623465948.issue15544@psf.upfronthosting.co.za> Raymond Hettinger added the comment: -0.5 on making the math module functions aware of decimals. The math module was originally conceived as thin wrapper around the C math library. Subsequently, it has had feature creep (I'm guilty of putting the integer factorial method in this module). I don't think further creep and loss of focus is warranted. Making some functions decimal aware and others not is probably not a good idea. Also, if someone is using decimals, they are better of using the methods supplied in that module (those have at least passed the huge battery of tests for compliance with the spec). ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 10:13:18 2012 From: report at bugs.python.org (nordaux) Date: Wed, 08 Aug 2012 08:13:18 +0000 Subject: [issue15578] Crash when modifying sys.modules during import In-Reply-To: <1344372630.36.0.657008264392.issue15578@psf.upfronthosting.co.za> Message-ID: <1344413598.02.0.351158933779.issue15578@psf.upfronthosting.co.za> Changes by nordaux : ---------- nosy: +nordaux _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 10:14:00 2012 From: report at bugs.python.org (Ned Deily) Date: Wed, 08 Aug 2012 08:14:00 +0000 Subject: [issue15587] IDLE is pixelated on the Macbook Pro with Retina Display In-Reply-To: <1344410417.58.0.332657489061.issue15587@psf.upfronthosting.co.za> Message-ID: <1344413639.99.0.202489077409.issue15587@psf.upfronthosting.co.za> Ned Deily added the comment: Text rendering in Tkinter applications like IDLE is a service of the underlying Tcl/Tk implementation. Essentially, all that IDLE does is to pass text in a requested font face and font size through Tkinter to Tcl/Tk which may then use whatever approach it wants to render the text. IDLE does allow you to select a font face and text size in the IDLE Preferences Font/Tabs tab. You may want to experiment there to find a satisfactory combination of settings for your use. If you can't and there is something specific that needs to change, it will almost certainly have to be done by the Tcl/Tk project. Feel free to reopen this issue if you can identify specific deficiencies in IDLE or Tkinter. ---------- nosy: +ned.deily resolution: -> invalid stage: -> committed/rejected status: open -> closed versions: -Python 2.6, Python 3.1, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 10:58:33 2012 From: report at bugs.python.org (Ned Deily) Date: Wed, 08 Aug 2012 08:58:33 +0000 Subject: [issue15550] Trailing white spaces In-Reply-To: <1344008415.84.0.0454996292543.issue15550@psf.upfronthosting.co.za> Message-ID: <1344416313.47.0.531037692407.issue15550@psf.upfronthosting.co.za> Ned Deily added the comment: Since we've established that python files are already covered by 'make patchcheck' and the hg checkin hook and that there does not appear to be much enthusiasm for extending the hook to C files or to wholesale whitespace cleanup, the remaining issue is whether to extend 'make patchcheck' for C files. And that is the subject of open Issue8912. So I'm going to close this issue as a duplicate of that one and suggest further discussion take place there. As for a per-file bypass, I'm not aware of any nor of any need that has arisen so far for one. ---------- resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> `make patchcheck` should check the whitespace of .c/.h files _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 11:16:51 2012 From: report at bugs.python.org (Stefan Krah) Date: Wed, 08 Aug 2012 09:16:51 +0000 Subject: [issue15589] Bus error on Debian sparc Message-ID: <1344417411.0.0.396332340112.issue15589@psf.upfronthosting.co.za> New submission from Stefan Krah: Running *any* test of the test suite currently produces a bus error on Debian sparc [http://people.debian.org/~aurel32/qemu/sparc/]. After the bus error, the tests seem to proceed normally though. This is definitely new. I've been testing memoryview for bus errors a couple of months ago without problems. Georg, I'm provisionally setting this to release blocker. The qemu-sparc image is quite old though (Debian Etch). It's a pity we don't have a sparc buildbot any more. Example: user at debian-sparc:~/cpython$ ./python -m test -uall -v test_flufl == CPython 3.3.0b1 (default:67d36e8ddcfc+, Aug 7 2012, 23:49:57) [GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] Fatal Python error: Bus error Current thread 0x00004000: File "/home/user/cpython/Lib/subprocess.py", line 1363 in _execute_child File "/home/user/cpython/Lib/subprocess.py", line 818 in __init__ File "/home/user/cpython/Lib/os.py", line 995 in popen File "/home/user/cpython/Lib/platform.py", line 903 in _syscmd_uname File "/home/user/cpython/Lib/platform.py", line 1147 in uname File "/home/user/cpython/Lib/platform.py", line 1452 in platform File "/home/user/cpython/Lib/test/regrtest.py", line 537 in main File "/home/user/cpython/Lib/test/__main__.py", line 13 in File "/home/user/cpython/Lib/runpy.py", line 73 in _run_code File "/home/user/cpython/Lib/runpy.py", line 160 in _run_module_as_main == Linux-2.6.18-6-sparc32-sparc-with-debian-4.0 big-endian == /home/user/cpython/build/test_python_3262 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) [1/1] test_flufl test_barry_as_bdfl (test.test_flufl.FLUFLTests) ... ok test_guido_as_bdfl (test.test_flufl.FLUFLTests) ... ok ---------------------------------------------------------------------- Ran 2 tests in 0.053s OK 1 test OK. ---------- keywords: 3.2regression messages: 167678 nosy: georg.brandl, skrah priority: release blocker severity: normal stage: needs patch status: open title: Bus error on Debian sparc type: crash versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 12:15:46 2012 From: report at bugs.python.org (Stefan Krah) Date: Wed, 08 Aug 2012 10:15:46 +0000 Subject: [issue15589] Bus error on Debian sparc In-Reply-To: <1344417411.0.0.396332340112.issue15589@psf.upfronthosting.co.za> Message-ID: <1344420946.67.0.69807623422.issue15589@psf.upfronthosting.co.za> Stefan Krah added the comment: Setting to critical: debian-sparc 32-bit is apparently deprecated since Lenny and still uses linuxthreads. Tracking down the failure could end up in finding a platform bug like in #12936. ---------- priority: release blocker -> critical _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 12:16:18 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 08 Aug 2012 10:16:18 +0000 Subject: [issue11715] Building Python on multiarch Debian and Ubuntu In-Reply-To: <1301435300.88.0.0418449859461.issue11715@psf.upfronthosting.co.za> Message-ID: <3WsT5X4FlDzQ0W@mail.python.org> Roundup Robot added the comment: New changeset 5966c206654b by doko in branch 'default': - Issue #11715: Fix multiarch detection without having Debian development http://hg.python.org/cpython/rev/5966c206654b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 12:18:24 2012 From: report at bugs.python.org (Matthias Klose) Date: Wed, 08 Aug 2012 10:18:24 +0000 Subject: [issue14330] don't use host python, use host search paths for host compiler In-Reply-To: <1331856850.28.0.590122825265.issue14330@psf.upfronthosting.co.za> Message-ID: <1344421104.25.0.206484343677.issue14330@psf.upfronthosting.co.za> Matthias Klose added the comment: committed the ma.diff from #11715, msg167680. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 12:18:44 2012 From: report at bugs.python.org (Matthias Klose) Date: Wed, 08 Aug 2012 10:18:44 +0000 Subject: [issue11715] Building Python on multiarch Debian and Ubuntu In-Reply-To: <1301435300.88.0.0418449859461.issue11715@psf.upfronthosting.co.za> Message-ID: <1344421124.71.0.532650122064.issue11715@psf.upfronthosting.co.za> Changes by Matthias Klose : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 12:41:33 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 08 Aug 2012 10:41:33 +0000 Subject: [issue15475] Correct __sizeof__ support for itertools In-Reply-To: <1343418242.58.0.256146467281.issue15475@psf.upfronthosting.co.za> Message-ID: <1344422493.47.0.232144075065.issue15475@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The clean-up patch looks much nicer. Thanks. I'm not sure why anyone would really want this functionality for itertools, but I don't see any harm in adding it as long as the other implementations aren't required to follow. Also, it could be viewed as being a new feature, so I'm not sure backports are warranted. Be sure to ask the respective release managers before applying. ---------- assignee: rhettinger -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 12:43:18 2012 From: report at bugs.python.org (Matthias Klose) Date: Wed, 08 Aug 2012 10:43:18 +0000 Subject: [issue15590] --libs is inconsistent for python-config --libs and pkgconfig python --libs Message-ID: <1344422598.39.0.464686614779.issue15590@psf.upfronthosting.co.za> New submission from Matthias Klose: seen with at least 2.7, 3.2 and 3.3: $ python-config --libs -lpthread -ldl -lutil -lm -lpython2.7 $ pkg-config python --static --libs -lpthread -ldl -lutil -lpython2.7 python-config uses the SYSLIBS macro, while pkg-config uses the LIBS macro. depending on what you want to do, both can be wrong or right: - to build an extension, LIBS should be used. - to link an embedded interpreter, SYSLIBS should be used, which might not be complete. Howver in this case MODLIBS is missing. a patch should be easy once we can define the intended behaviour. ---------- components: Build keywords: needs review messages: 167683 nosy: doko priority: normal severity: normal status: open title: --libs is inconsistent for python-config --libs and pkgconfig python --libs type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 12:52:57 2012 From: report at bugs.python.org (Matthias Klose) Date: Wed, 08 Aug 2012 10:52:57 +0000 Subject: [issue15591] when building the extensions, stdout is lost when stdout is redirected Message-ID: <1344423177.77.0.190751096511.issue15591@psf.upfronthosting.co.za> New submission from Matthias Klose: I see this on all Debian and Ubuntu releases, when stdout is redirected. I expect to see the compiler and linker invocations for the sharedmods target, but I only see stderr (compiler and linker warnings). e.g. make 2>&1 | tee log or script -c 'make' log can this be reproduced on Debian/Ubuntu, or is this seen on other Linux distributions as well? ---------- components: Build messages: 167684 nosy: doko priority: normal severity: normal status: open title: when building the extensions, stdout is lost when stdout is redirected type: behavior versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 12:55:52 2012 From: report at bugs.python.org (Matthias Klose) Date: Wed, 08 Aug 2012 10:55:52 +0000 Subject: [issue15426] On a x86_64 Linux workstation, the build-from-source is borked. In-Reply-To: <1342987672.67.0.931013334684.issue15426@psf.upfronthosting.co.za> Message-ID: <1344423352.48.0.0214681785594.issue15426@psf.upfronthosting.co.za> Matthias Klose added the comment: I don't think so. lib is hardcoded for any python release, so this issue shouldn't be specific to 3.3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 13:11:54 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 08 Aug 2012 11:11:54 +0000 Subject: [issue15590] --libs is inconsistent for python-config --libs and pkgconfig python --libs In-Reply-To: <1344422598.39.0.464686614779.issue15590@psf.upfronthosting.co.za> Message-ID: <1344424314.94.0.287519002287.issue15590@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: Behavior of 'pkg-config python' is more useful since without --static option only the set of directly needed libraries is returned. In Python 3.3 or 3.4 --static option could be introduced in python-config and behavior without this option could be changed to match 'pkg-config python'. ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 13:32:00 2012 From: report at bugs.python.org (Stefan Krah) Date: Wed, 08 Aug 2012 11:32:00 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1344425520.44.0.534562747139.issue15573@psf.upfronthosting.co.za> Stefan Krah added the comment: Right, byte order specifiers are always at the beginning of the string. That is at least something. I wonder if we should tighten PEP-3118 to demand a canonical form of format strings, such as (probably incomplete): - Whitespace is disallowed. - Except for 's', no zero count may be given. - A count of 1 (redundant) is disallowed. - Repeats must be specified in terms of count + single char. That still leaves the '=I' != '=L' problem. Why are there two specifiers describing uint32_t? Anyway, as Meador says, this can get tricky and I don't think this can be resolved before beta-2. I'm attaching a patch that should behave well for the restricted canonical form at least. ---------- keywords: +patch Added file: http://bugs.python.org/file26725/issue15573.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 14:08:33 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Aug 2012 12:08:33 +0000 Subject: [issue15589] Bus error on Debian sparc In-Reply-To: <1344417411.0.0.396332340112.issue15589@psf.upfronthosting.co.za> Message-ID: <1344427713.76.0.401745319975.issue15589@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 14:38:40 2012 From: report at bugs.python.org (Daniel Ellis) Date: Wed, 08 Aug 2012 12:38:40 +0000 Subject: [issue15586] Provide some examples for usage of ElementTree methods/attributes In-Reply-To: <1344407679.24.0.102359835139.issue15586@psf.upfronthosting.co.za> Message-ID: <1344429520.88.0.347264324613.issue15586@psf.upfronthosting.co.za> Daniel Ellis added the comment: I have been working with ElementTree for the last few months and would love to help out with this. ---------- nosy: +Daniel.Ellis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 16:09:46 2012 From: report at bugs.python.org (Meador Inge) Date: Wed, 08 Aug 2012 14:09:46 +0000 Subject: [issue15475] Correct __sizeof__ support for itertools In-Reply-To: <1343418242.58.0.256146467281.issue15475@psf.upfronthosting.co.za> Message-ID: <1344434986.28.0.442966403539.issue15475@psf.upfronthosting.co.za> Meador Inge added the comment: On Wed, Aug 8, 2012 at 5:41 AM, Raymond Hettinger wrote: > I'm not sure why anyone would really want this functionality for itertools, > but I don't see any harm in adding it as long as the other implementations > aren't required to follow. The general expection is that __sizeof__ is for CPython. We tag the tests with '@cpython_only'. > Also, it could be viewed as being a new feature, so I'm not sure backports > are warranted. So far, we have been applying the __sizeof__ patches to all branches. > Be sure to ask the respective release managers before applying. I will check with Georg for 3.3. Thanks. ---------- assignee: -> meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 16:44:13 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 08 Aug 2012 14:44:13 +0000 Subject: [issue14182] collections.Counter equality test thrown-off by zero counts In-Reply-To: <1330769404.28.0.817906963132.issue14182@psf.upfronthosting.co.za> Message-ID: <1344437053.27.0.294889215715.issue14182@psf.upfronthosting.co.za> Eric Snow added the comment: I'd missed that unary + (new in 3.3). That's pretty cool. ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 18:07:09 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 08 Aug 2012 16:07:09 +0000 Subject: [issue15586] Provide some examples for usage of ElementTree methods/attributes In-Reply-To: <1344407679.24.0.102359835139.issue15586@psf.upfronthosting.co.za> Message-ID: <1344442029.94.0.342668698307.issue15586@psf.upfronthosting.co.za> Ezio Melotti added the comment: Daniel, I would suggest you to start with a basic example that gives an idea about how to use the module and its main functionalities. If necessary you could add a section at the bottom with more examples. You can also show how a method works with a short snippet (2-3 lines) just after the documentation of the method, but this doesn't mean that every method should have one. If you have lot of examples you might consider doing a separate tutorial/howto. As a reference see the examples in http://docs.python.org/py3k/library/html.parser.html and http://docs.python.org/py3k/library/unittest.html#basic-example. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 18:33:29 2012 From: report at bugs.python.org (Daniel Ellis) Date: Wed, 08 Aug 2012 16:33:29 +0000 Subject: [issue15586] Provide some examples for usage of ElementTree methods/attributes In-Reply-To: <1344442029.94.0.342668698307.issue15586@psf.upfronthosting.co.za> Message-ID: Daniel Ellis added the comment: Thank you Ezio, I will use that as a reference. What is the general workflow for updating documentation across python versions? Should I check to see if the documentation for the module changes across python versions and create patches for each version? Or is it sufficient to create a patch for one version? On Wed, Aug 8, 2012 at 12:07 PM, Ezio Melotti wrote: > > Ezio Melotti added the comment: > > Daniel, I would suggest you to start with a basic example that gives an > idea about how to use the module and its main functionalities. If > necessary you could add a section at the bottom with more examples. > You can also show how a method works with a short snippet (2-3 lines) just > after the documentation of the method, but this doesn't mean that every > method should have one. > If you have lot of examples you might consider doing a separate > tutorial/howto. > > As a reference see the examples in > http://docs.python.org/py3k/library/html.parser.html and > http://docs.python.org/py3k/library/unittest.html#basic-example. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 18:36:47 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 08 Aug 2012 16:36:47 +0000 Subject: [issue15586] Provide some examples for usage of ElementTree methods/attributes In-Reply-To: <1344407679.24.0.102359835139.issue15586@psf.upfronthosting.co.za> Message-ID: <1344443807.39.0.641868719512.issue15586@psf.upfronthosting.co.za> Ezio Melotti added the comment: Usually a patch against "default" (i.e. Python 3) is enough, if there are several differences with Python 2 you might want to provide one for 2.7 too. See also the devguide at http://docs.python.org/devguide/ for more information about the workflow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 18:38:00 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 08 Aug 2012 16:38:00 +0000 Subject: [issue15592] subprocess.communicate() breaks on no input with universal newlines true Message-ID: <1344443880.03.0.234384317121.issue15592@psf.upfronthosting.co.za> New submission from Chris Jerdonek: Popen.communicate() raises an exception if passed no input when stdin=PIPE and universal_newlines=True. With universal_newlines=False, no exception is raised. For example, the following yields-- args = [sys.executable, '-c', 'pass'] popen = Popen(args, universal_newlines=False, stdin=PIPE, stdout=PIPE, stderr=PIPE) print(popen.communicate()) popen = Popen(args, universal_newlines=True, stdin=PIPE, stdout=PIPE, stderr=PIPE) print(popen.communicate()) (b'', b'[41449 refs]\n') Traceback (most recent call last): ... File ".../Lib/subprocess.py", line 1581, in _communicate_with_poll self._input = self._input.encode(self.stdin.encoding) AttributeError: 'NoneType' object has no attribute 'encode' It seems like communicate() should not be trying to encode input if there is none. I can provide a patch with tests if it is agreed this is an issue (along with a fix assuming it is reasonable). ---------- components: Library (Lib) messages: 167694 nosy: cjerdonek priority: normal severity: normal stage: test needed status: open title: subprocess.communicate() breaks on no input with universal newlines true type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 18:38:53 2012 From: report at bugs.python.org (Marius Gedminas) Date: Wed, 08 Aug 2012 16:38:53 +0000 Subject: [issue9327] doctest DocFileCase setUp/tearDown asymmetry In-Reply-To: <1279750116.68.0.946227736764.issue9327@psf.upfronthosting.co.za> Message-ID: <1344443933.48.0.458705682063.issue9327@psf.upfronthosting.co.za> Marius Gedminas added the comment: Duplicate of issue2604? ---------- nosy: +mgedmin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 18:39:49 2012 From: report at bugs.python.org (Marius Gedminas) Date: Wed, 08 Aug 2012 16:39:49 +0000 Subject: [issue2604] doctest.DocTestCase fails when run repeatedly In-Reply-To: <1207798847.15.0.203205049744.issue2604@psf.upfronthosting.co.za> Message-ID: <1344443989.32.0.447524609252.issue2604@psf.upfronthosting.co.za> Marius Gedminas added the comment: For the record, this bug also breaks zope.testrunner's --repeat option, if you have any doctests in your test suite that rely on test.globs not going away. ---------- nosy: +mgedmin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 18:40:32 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 08 Aug 2012 16:40:32 +0000 Subject: [issue15592] subprocess.communicate() breaks on no input with universal newlines true In-Reply-To: <1344443880.03.0.234384317121.issue15592@psf.upfronthosting.co.za> Message-ID: <1344444032.22.0.269976164547.issue15592@psf.upfronthosting.co.za> Chris Jerdonek added the comment: See issue 12623 for another issue related to communicate() and universal newline support. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 19:30:00 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 08 Aug 2012 17:30:00 +0000 Subject: [issue15584] os.popen deprecation warning not in Python 3 docs In-Reply-To: <1344403027.9.0.851552943116.issue15584@psf.upfronthosting.co.za> Message-ID: <1344447000.09.0.839489873284.issue15584@psf.upfronthosting.co.za> R. David Murray added the comment: That's because we ultimately decided not to remove it. ---------- nosy: +r.david.murray resolution: -> duplicate status: open -> closed superseder: -> os.popen documentation is probably wrong _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 19:31:45 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 08 Aug 2012 17:31:45 +0000 Subject: [issue15585] usage of os.popen in standard library In-Reply-To: <1344403104.8.0.699404283397.issue15585@psf.upfronthosting.co.za> Message-ID: <1344447105.04.0.774550756123.issue15585@psf.upfronthosting.co.za> R. David Murray added the comment: There is already an open issue for this, with a (partial?) patch. ---------- nosy: +r.david.murray resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> os.popen documentation is probably wrong _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 19:39:56 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 08 Aug 2012 17:39:56 +0000 Subject: [issue15588] quopri: encodestring and decodestring handle bytes, not strings In-Reply-To: <1344411059.45.0.404148694214.issue15588@psf.upfronthosting.co.za> Message-ID: <1344447596.22.0.185261773837.issue15588@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- components: +email nosy: +barry, r.david.murray versions: +Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 19:51:53 2012 From: report at bugs.python.org (Eli Bendersky) Date: Wed, 08 Aug 2012 17:51:53 +0000 Subject: [issue15586] Provide some examples for usage of ElementTree methods/attributes In-Reply-To: <1344407679.24.0.102359835139.issue15586@psf.upfronthosting.co.za> Message-ID: <1344448313.53.0.973070046747.issue15586@psf.upfronthosting.co.za> Eli Bendersky added the comment: Please note that the documentation of ET has been significantly improved in 3.3, with added examples, etc. You can start by backporting whatever is relevant to earlier versions (2.7/3.2) - do not add new documentation contents to 2.7/3.2 before the changes from 3.3 are backported, because we can't have divergent docs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 20:08:10 2012 From: report at bugs.python.org (Georg Brandl) Date: Wed, 08 Aug 2012 18:08:10 +0000 Subject: [issue15589] Bus error on Debian sparc In-Reply-To: <1344417411.0.0.396332340112.issue15589@psf.upfronthosting.co.za> Message-ID: <1344449290.8.0.418349099702.issue15589@psf.upfronthosting.co.za> Georg Brandl added the comment: >From the position of the bus error, it would seem that calling a subprocess during platform.platform() is the culprit. But if test_subprocess passes without any bus errors, that would be strange. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 20:13:21 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 08 Aug 2012 18:13:21 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1317341390.65.0.255779328054.issue13072@psf.upfronthosting.co.za> Message-ID: <3Wsggz5fqFzQ3D@mail.python.org> Roundup Robot added the comment: New changeset e0f3406c43e4 by Victor Stinner in branch 'default': Issue #13072: Fix test_array for Windows with 16-bit wchar_t http://hg.python.org/cpython/rev/e0f3406c43e4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 20:23:27 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 08 Aug 2012 18:23:27 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1317341390.65.0.255779328054.issue13072@psf.upfronthosting.co.za> Message-ID: <3Wsgvf2sJjzPyg@mail.python.org> Roundup Robot added the comment: New changeset 67a994d5657d by Victor Stinner in branch 'default': Issue #13072: Ooops, now fix test_array for Linux with 32-bit wchar_t... http://hg.python.org/cpython/rev/67a994d5657d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 20:34:51 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 08 Aug 2012 18:34:51 +0000 Subject: [issue15501] Document exception classes in subprocess module In-Reply-To: <1343655102.86.0.835171642678.issue15501@psf.upfronthosting.co.za> Message-ID: <1344450891.45.0.889055653541.issue15501@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Please update your patches: 1. use attribute:: 2. point base class for exception if it is not Exception 3. enumerate all attributes (`cmd` for CalledProcessError) Example: .. exception:: HTTPError Though being an exception (a subclass of :exc:`URLError`), an :exc:`HTTPError` can also function as a non-exceptional file-like return value (the same thing that :func:`urlopen` returns). This is useful when handling exotic HTTP errors, such as requests for authentication. .. attribute:: code An HTTP status code as defined in `RFC 2616 `_. This numeric value corresponds to a value found in the dictionary of codes as found in :attr:`BaseHTTPServer.BaseHTTPRequestHandler.responses`. Also please fill Contributor Agreement: http://www.python.org/psf/contrib/ ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 20:53:39 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 08 Aug 2012 18:53:39 +0000 Subject: [issue15151] Documentation for Signature, Parameter and signature in inspect module In-Reply-To: <1340432030.73.0.594662136445.issue15151@psf.upfronthosting.co.za> Message-ID: <1344452019.24.0.537001376646.issue15151@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Yury, please updete your patch to pass doctest: ./python -m doctest Doc/library/inspect.html ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 21:36:40 2012 From: report at bugs.python.org (Ned Deily) Date: Wed, 08 Aug 2012 19:36:40 +0000 Subject: [issue15589] Bus error on Debian sparc In-Reply-To: <1344417411.0.0.396332340112.issue15589@psf.upfronthosting.co.za> Message-ID: <1344454600.11.0.719153008123.issue15589@psf.upfronthosting.co.za> Ned Deily added the comment: Is it by any chance a --shared build being run from the build directory without having been installed (and without a LD_LIBRARY_PATH and with an older version already installed)? ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 21:47:51 2012 From: report at bugs.python.org (Rob Kinyon) Date: Wed, 08 Aug 2012 19:47:51 +0000 Subject: [issue15593] urlparse.parse_qs documentation wrong re: urlencode Message-ID: <1344455271.07.0.337513141168.issue15593@psf.upfronthosting.co.za> New submission from Rob Kinyon: This may appear to be a duplicate of http://bugs.python.org/issue12390 and http://bugs.python.org/issue833405, but it's not. The documentation of urlparse.parse_qs() should state that in order for urllib.urlencode to properly reverse its output, the doseq parameter must be set to True. Please amend the documentation to make this very clear. Ideally, the documentation of urlencode() would also make it clear that doseq=True is required if the output is from parse_qs(). ---------- assignee: docs at python components: Documentation messages: 167707 nosy: Rob.Kinyon, docs at python priority: normal severity: normal status: open title: urlparse.parse_qs documentation wrong re: urlencode versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 22:05:08 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 08 Aug 2012 20:05:08 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1317341390.65.0.255779328054.issue13072@psf.upfronthosting.co.za> Message-ID: <1344456308.51.0.64214458302.issue13072@psf.upfronthosting.co.za> Antoine Pitrou added the comment: And the test fails on machines without ctypes :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 22:17:46 2012 From: report at bugs.python.org (Ethan Furman) Date: Wed, 08 Aug 2012 20:17:46 +0000 Subject: [issue15510] textwrap.wrap('') returns empty list In-Reply-To: <1344392568.77.0.994801768422.issue15510@psf.upfronthosting.co.za> Message-ID: <5022CCDB.2060007@stoneleaf.us> Ethan Furman added the comment: Chris Jerdonek wrote: > Here is an example on a paragraph with line breaks between paragraphs: s/paragraph/text/ >>>> def wrap_paras(text, width=70, **kwargs): > ... lines = [line for para in text.splitlines() > ... for line in wrap(para, width, **kwargs)] > ... return "\n".join(lines) > ... >>>> text = """\ > ... abcd abcd > ... > ... abcd abcd""" >>>> print(wrap_paras(text)) > abcd abcd > abcd abcd > > The edge case we're discussing determines whether line breaks between paragraphs are preserved in the result. (With current behavior, they are not.) Having now more carefully read the docs (which, admittedly, I should have done before responding the first time) I found this: textwrap.wrap(text, width=70, **kwargs) Wraps the single paragraph in text . . . textwrap.fill(text, width=70, **kwargs) Wraps the single paragraph in text, . . . In other words, it is not designed to work on multiple paragraphs at once. And the documentation is fine. Move along, no bug to see here, move along... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 22:26:17 2012 From: report at bugs.python.org (Daniel Ellis) Date: Wed, 08 Aug 2012 20:26:17 +0000 Subject: [issue15586] Provide some examples for usage of ElementTree methods/attributes In-Reply-To: <1344407679.24.0.102359835139.issue15586@psf.upfronthosting.co.za> Message-ID: <1344457577.91.0.451583840796.issue15586@psf.upfronthosting.co.za> Daniel Ellis added the comment: I've made a couple more additions/changes to the documentation in the default branch, per Eli's recommendation, since there were already a lot of good examples added. I'd like to also backport this to 2.7 but wanted to make sure these changes were good before moving forward. I just saw Eli's message about doing the backporting before making further changes but had already been working on making these changes. I can go ahead and work on the backport if you feel this patch is too much to do first, but I believe every example I added is backwards compatible. ---------- keywords: +patch Added file: http://bugs.python.org/file26726/default_branch_etree_doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 22:27:35 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Aug 2012 20:27:35 +0000 Subject: [issue15594] test_copyfile_named_pipe() fails on Mac OS X Snow Leopard: OSError: [Errno 22] Invalid argument Message-ID: <1344457655.9.0.373688420399.issue15594@psf.upfronthosting.co.za> New submission from STINNER Victor: ====================================================================== ERROR: test_copyfile_named_pipe (test.test_shutil.TestShutil) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/ambv/Buildbot/3.x.langa-snowleopard/build/Lib/test/test_shutil.py", line 735, in test_copyfile_named_pipe os.mkfifo(TESTFN) OSError: [Errno 22] Invalid argument http://buildbot.python.org/all/builders/AMD64%20Snow%20Leopard%203.x/builds/162/steps/test/logs/stdio ---------- assignee: ronaldoussoren components: Macintosh messages: 167711 nosy: haypo, ronaldoussoren priority: normal severity: normal status: open title: test_copyfile_named_pipe() fails on Mac OS X Snow Leopard: OSError: [Errno 22] Invalid argument versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 22:34:55 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 08 Aug 2012 20:34:55 +0000 Subject: [issue15510] textwrap.wrap('') returns empty list In-Reply-To: <1343697979.41.0.629576632811.issue15510@psf.upfronthosting.co.za> Message-ID: <1344458095.13.0.911347910181.issue15510@psf.upfronthosting.co.za> R. David Murray added the comment: Also you will note that the return of the empty list for an empty line is exactly what you want for wrapping multiple line-break-delimited paragraphs. Consider: >>> doc = "a para\nanother para\n\na third, but with an extra blank line between\n" >>> for line in doc.splitlines(): ... print('\n'.join(textwrap.wrap(line, width=5))) ... if line: ... print() a para anoth er para a thi rd, but with an extra blank line betwe en In other words, we need to add a blank line after our formatted paragraph, unless it is empty, in which case we don't want to add one or we'll have an extra. This assumes that single-line-paragraphs do not have blank lines between them...if they do, then the algorithm is even simpler, as you don't need the if. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 23:08:30 2012 From: report at bugs.python.org (Floris Bruynooghe) Date: Wed, 08 Aug 2012 21:08:30 +0000 Subject: [issue15589] Bus error on Debian sparc In-Reply-To: <1344417411.0.0.396332340112.issue15589@psf.upfronthosting.co.za> Message-ID: <1344460110.3.0.286519161035.issue15589@psf.upfronthosting.co.za> Floris Bruynooghe added the comment: Running on Solaris 10 (T1000, OpenCSW toolchain, gcc 4.6.3) I also get a bus error, with added coredump: $ ./python Lib/test/regrtest.py == CPython 3.3.0b1 (default:67a994d5657d, Aug 8 2012, 21:43:48) [GCC 4.6.3] == Solaris-2.10-sun4v-sparc-32bit big-endian == /export/home/flub/python/cpython/build/test_python_7320 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) [ 1/369] test_grammar [ 2/369] test_opcodes [ 3/369] test_dict [ 4/369] test_builtin [ 5/369] test_exceptions test test_exceptions failed -- Traceback (most recent call last): File "/export/home/flub/python/cpython/Lib/test/test_exceptions.py", line 432, in testChainingDescriptors self.assertTrue(e.__suppress_context__) AssertionError: False is not true [ 6/369/1] test_types [ 7/369/1] test_unittest [ 8/369/1] test_doctest [ 9/369/1] test_doctest2 [ 10/369/1] test_support [ 11/369/1] test___all__ [ 12/369/1] test___future__ [ 13/369/1] test__locale [ 14/369/1] test__osx_support [ 15/369/1] test_abc [ 16/369/1] test_abstract_numbers [ 17/369/1] test_aifc [ 18/369/1] test_argparse [ 19/369/1] test_array [ 20/369/1] test_ast [ 21/369/1] test_asynchat [ 22/369/1] test_asyncore [ 23/369/1] test_atexit [ 24/369/1] test_audioop [ 25/369/1] test_augassign [ 26/369/1] test_base64 [ 27/369/1] test_bigaddrspace [ 28/369/1] test_bigmem [ 29/369/1] test_binascii [ 30/369/1] test_binhex [ 31/369/1] test_binop [ 32/369/1] test_bisect [ 33/369/1] test_bool [ 34/369/1] test_buffer [ 35/369/1] test_bufio [ 36/369/1] test_bytes [ 37/369/1] test_bz2 [ 38/369/1] test_calendar [ 39/369/1] test_call [ 40/369/1] test_capi Fatal Python error: Bus error Current thread 0x00000001: File "/export/home/flub/python/cpython/Lib/test/test_capi.py", line 264 in test_skipitem File "/export/home/flub/python/cpython/Lib/unittest/case.py", line 385 in _executeTestPart File "/export/home/flub/python/cpython/Lib/unittest/case.py", line 440 in run File "/export/home/flub/python/cpython/Lib/unittest/case.py", line 492 in __call__ File "/export/home/flub/python/cpython/Lib/unittest/suite.py", line 105 in run File "/export/home/flub/python/cpython/Lib/unittest/suite.py", line 67 in __call__ File "/export/home/flub/python/cpython/Lib/unittest/suite.py", line 105 in run File "/export/home/flub/python/cpython/Lib/unittest/suite.py", line 67 in __call__ File "/export/home/flub/python/cpython/Lib/test/support.py", line 1312 in run File "/export/home/flub/python/cpython/Lib/test/support.py", line 1413 in _run_suite File "/export/home/flub/python/cpython/Lib/test/support.py", line 1447 in run_unittest File "/export/home/flub/python/cpython/Lib/test/test_capi.py", line 290 in test_main File "Lib/test/regrtest.py", line 1219 in runtest_inner File "Lib/test/regrtest.py", line 941 in runtest File "Lib/test/regrtest.py", line 714 in main File "Lib/test/regrtest.py", line 1810 in Bus Error (core dumped) Not sure if this should be tracked in the same issue or not? ---------- nosy: +flub _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 23:21:04 2012 From: report at bugs.python.org (Stefan Krah) Date: Wed, 08 Aug 2012 21:21:04 +0000 Subject: [issue15589] Bus error on Debian sparc In-Reply-To: <1344417411.0.0.396332340112.issue15589@psf.upfronthosting.co.za> Message-ID: <1344460864.92.0.587091411932.issue15589@psf.upfronthosting.co.za> Stefan Krah added the comment: I think I've identified one legit Python bug. This is from a *different* traceback, i.e. the traceback in my first message is still unresolved. A bus error occurs in test_capi, test_skipitem with format 'D': Python/getargs.c:782 Py_complex *p = va_arg(*p_va, Py_complex *); Py_complex cval; cval = PyComplex_AsCComplex(arg); if (PyErr_Occurred()) RETURN_ERR_OCCURRED; else *p = cval; <- bus error break; The pointer p has value 0xefbfb1fc, with 0xefbfb1fc % 8 == 4. It originates from a somewhat creatively allocated memory region in _testcapi:parse_tuple_and_keywords. :) ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 23:23:00 2012 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Aug 2012 21:23:00 +0000 Subject: [issue15589] Bus error on Debian sparc In-Reply-To: <1344417411.0.0.396332340112.issue15589@psf.upfronthosting.co.za> Message-ID: <1344460980.87.0.21501247711.issue15589@psf.upfronthosting.co.za> Larry Hastings added the comment: This platform is 8-byte aligned? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 23:25:06 2012 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Aug 2012 21:25:06 +0000 Subject: [issue15589] Bus error on Debian sparc In-Reply-To: <1344417411.0.0.396332340112.issue15589@psf.upfronthosting.co.za> Message-ID: <1344461106.34.0.507174892847.issue15589@psf.upfronthosting.co.za> Larry Hastings added the comment: nm, I get it, doubles are 8-bytes and should be 8-byte aligned. Let me stare at it some more. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 23:28:29 2012 From: report at bugs.python.org (Stefan Krah) Date: Wed, 08 Aug 2012 21:28:29 +0000 Subject: [issue15589] Bus error on Debian sparc In-Reply-To: <1344417411.0.0.396332340112.issue15589@psf.upfronthosting.co.za> Message-ID: <1344461309.61.0.462444725591.issue15589@psf.upfronthosting.co.za> Stefan Krah added the comment: Floris, the traceback in my first message only occurs in the optimized regular build with -O3. Did you try that, too? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 23:30:06 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 08 Aug 2012 21:30:06 +0000 Subject: [issue8800] add threading.RWLock In-Reply-To: <1274694942.46.0.488506239249.issue8800@psf.upfronthosting.co.za> Message-ID: <1344461406.97.0.52824809606.issue8800@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 23:32:06 2012 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Aug 2012 21:32:06 +0000 Subject: [issue15589] Bus error on Debian sparc In-Reply-To: <1344417411.0.0.396332340112.issue15589@psf.upfronthosting.co.za> Message-ID: <1344461526.68.0.942969348072.issue15589@psf.upfronthosting.co.za> Larry Hastings added the comment: Attached is a patch attempting to force double alignment. Stefan: please apply and try it. Does this help? ---------- keywords: +patch Added file: http://bugs.python.org/file26727/larry.force.alignment.in.capi.test.1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 23:36:15 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 08 Aug 2012 21:36:15 +0000 Subject: [issue15595] subprocess.Popen(universal_newlines=True) does not work for certain locales Message-ID: <1344461775.23.0.274836365722.issue15595@psf.upfronthosting.co.za> New submission from Chris Jerdonek: subprocess.Popen() with universal_newlines=True does not convert line breaks correctly when the preferred encoding is UTF-16. For example, the following code-- code = r"import sys; sys.stdout.buffer.write('a\r\nb'.encode('utf-16'))" args = [sys.executable, '-c', code] popen = Popen(args, universal_newlines=True, stdin=PIPE, stdout=PIPE) print(popen.communicate(input='')) yields-- ('a\n\nb', None) instead of-- ('a\nb', None) The reason is that the code attempts to convert newlines before decoding to unicode instead of after: http://hg.python.org/cpython/file/85266c6f9ae4/Lib/subprocess.py#l830 I am attaching a failing test case. I will upload a patch shortly. Also see the related documentation issue 15561. ---------- components: Library (Lib) files: failing-test-case-1.patch keywords: easy, patch messages: 167719 nosy: cjerdonek priority: normal severity: normal stage: needs patch status: open title: subprocess.Popen(universal_newlines=True) does not work for certain locales type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file26728/failing-test-case-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 23:38:07 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Aug 2012 21:38:07 +0000 Subject: [issue15595] subprocess.Popen(universal_newlines=True) does not work for certain locales In-Reply-To: <1344461775.23.0.274836365722.issue15595@psf.upfronthosting.co.za> Message-ID: <1344461887.02.0.0133721761699.issue15595@psf.upfronthosting.co.za> STINNER Victor added the comment: > when the preferred encoding is UTF-16 What is your operating system? How do you set the locale encoding to UTF-16? Do you mean UTF-16, UTF-16-LE or UTF-16-BE? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 23:43:43 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 08 Aug 2012 21:43:43 +0000 Subject: [issue15595] subprocess.Popen(universal_newlines=True) does not work for certain locales In-Reply-To: <1344461775.23.0.274836365722.issue15595@psf.upfronthosting.co.za> Message-ID: <1344462223.49.0.458008498717.issue15595@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Attaching patch for review. ---------- stage: needs patch -> patch review Added file: http://bugs.python.org/file26729/issue-15595-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 23:48:23 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 08 Aug 2012 21:48:23 +0000 Subject: [issue15595] subprocess.Popen(universal_newlines=True) does not work for certain locales In-Reply-To: <1344461775.23.0.274836365722.issue15595@psf.upfronthosting.co.za> Message-ID: <1344462503.02.0.0720405060907.issue15595@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Victor, I have not personally experienced this issue. I just noticed that the order of operations is wrong or not portable in the _translate_newlines() method when I was looking at the code for another reason. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 23:49:25 2012 From: report at bugs.python.org (Floris Bruynooghe) Date: Wed, 08 Aug 2012 21:49:25 +0000 Subject: [issue15589] Bus error on Debian sparc In-Reply-To: <1344417411.0.0.396332340112.issue15589@psf.upfronthosting.co.za> Message-ID: <1344462565.71.0.853741925893.issue15589@psf.upfronthosting.co.za> Floris Bruynooghe added the comment: I compiled with a simple "./configure" which I think is what you mean (it defaults to -O3). But when executing your test it doesn't give a bus error. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 23:49:28 2012 From: report at bugs.python.org (Stefan Krah) Date: Wed, 08 Aug 2012 21:49:28 +0000 Subject: [issue15589] Bus error on Debian sparc In-Reply-To: <1344461526.68.0.942969348072.issue15589@psf.upfronthosting.co.za> Message-ID: <20120808214927.GA3062@sleipnir.bytereef.org> Stefan Krah added the comment: Larry Hastings wrote: > Attached is a patch attempting to force double alignment. Stefan: please apply and try it. Does this help? Yes, this works nicely. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 8 23:52:37 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 08 Aug 2012 21:52:37 +0000 Subject: [issue15589] Bus error on Debian sparc In-Reply-To: <1344417411.0.0.396332340112.issue15589@psf.upfronthosting.co.za> Message-ID: <3WsmY02DxfzQ0D@mail.python.org> Roundup Robot added the comment: New changeset efb30bdcfa1e by Larry Hastings in branch 'default': Issue #15589: Ensure double-alignment for brute-force capi argument parser test http://hg.python.org/cpython/rev/efb30bdcfa1e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 00:05:56 2012 From: report at bugs.python.org (Ned Deily) Date: Wed, 08 Aug 2012 22:05:56 +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: <1344463556.76.0.548035860474.issue15594@psf.upfronthosting.co.za> Ned Deily added the comment: There is something odd about the setup for that buildbot. Notice the other failures. The mkfifo() call on OS X isn't even documented as returning EINVAL (22). I've never seen this kind of failure on other OS X systems. ?ukasz, any ideas? ---------- assignee: ronaldoussoren -> nosy: +lukasz.langa, ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 00:07:05 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 08 Aug 2012 22:07:05 +0000 Subject: [issue15595] subprocess.Popen(universal_newlines=True) does not work for certain locales In-Reply-To: <1344461775.23.0.274836365722.issue15595@psf.upfronthosting.co.za> Message-ID: <1344463625.09.0.0725846597279.issue15595@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > How do you set the locale encoding to UTF-16? Do you mean UTF-16, UTF-16-LE or UTF-16-BE? I confirmed that the issue occurs for all of these. For testing purposes, you can do-- locale.getpreferredencoding = lambda do_setlocale: 'utf-16' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 00:29:46 2012 From: report at bugs.python.org (Floris Bruynooghe) Date: Wed, 08 Aug 2012 22:29:46 +0000 Subject: [issue15589] Bus error on Debian sparc In-Reply-To: <1344417411.0.0.396332340112.issue15589@psf.upfronthosting.co.za> Message-ID: <1344464986.35.0.048123778513.issue15589@psf.upfronthosting.co.za> Floris Bruynooghe added the comment: I think I can confirm this fixes the BusError. The test suite got past test_capi on my machine as well. Unfortunately I killed the ssh session by accident before the testsuite completed so I had to restart it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 00:33:38 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 08 Aug 2012 22:33:38 +0000 Subject: [issue15569] Doc doc: incorrect description of some roles as format-only In-Reply-To: <1344302647.18.0.307450045197.issue15569@psf.upfronthosting.co.za> Message-ID: <1344465218.56.0.450961078334.issue15569@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- assignee: -> docs at python nosy: +docs at python, eric.araujo stage: -> needs patch title: Dev Guide format-only roles -> Doc doc: incorrect description of some roles as format-only _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 00:34:54 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 08 Aug 2012 22:34:54 +0000 Subject: [issue15582] Enhance inspect.getdoc to follow inheritance chains In-Reply-To: <1344394334.01.0.280520797106.issue15582@psf.upfronthosting.co.za> Message-ID: <1344465294.38.0.410064134363.issue15582@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 00:36:04 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 08 Aug 2012 22:36:04 +0000 Subject: [issue15426] On a x86_64 Linux workstation, the build-from-source is borked. In-Reply-To: <1342987672.67.0.931013334684.issue15426@psf.upfronthosting.co.za> Message-ID: <1344465364.34.0.574481717917.issue15426@psf.upfronthosting.co.za> ?ric Araujo added the comment: The patch seems incorrect, as not all OSes or installations use lib64. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 00:38:42 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Aug 2012 22:38:42 +0000 Subject: [issue15596] pickle: Faster serialization of Unicode strings Message-ID: <1344465522.38.0.375715302831.issue15596@psf.upfronthosting.co.za> New submission from STINNER Victor: Serialization of Unicode strings in the pickle module is suboptimal, especially for long strings. Attached patch optimize the serialization thanks to new properties of Unicode strings (PEP 393): * text (protocol 0): avoid any temporary buffer if the string is an ASCII or latin1 string without "\\" or "\n" character; otherwise use a small buffer of 64 KB (instead of two buffer) * binary (protocol 1, 2): avoid any temporary buffer if string is an ASCII string or if the string is already available encoded as UTF-8 The current code for protocol 0 uses raw_unicode_escape() which is really suboptimal: it uses a first buffer to write the escape string, and then a new temporary buffer to store the buffer with the right size (instead of just calling _PyBytes_Resize). ---------- components: Library (Lib) files: pickle_unicode.patch keywords: patch messages: 167730 nosy: alexandre.vassalotti, haypo, pitrou priority: normal severity: normal status: open title: pickle: Faster serialization of Unicode strings type: performance versions: Python 3.4 Added file: http://bugs.python.org/file26730/pickle_unicode.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 00:41:33 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Aug 2012 22:41:33 +0000 Subject: [issue15596] pickle: Faster serialization of Unicode strings In-Reply-To: <1344465522.38.0.375715302831.issue15596@psf.upfronthosting.co.za> Message-ID: <1344465693.14.0.199979816453.issue15596@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, I forgot to explain that I initially wrote the patch to fix the following failure on our "bigmem" buildbot. http://buildbot.python.org/all/builders/AMD64%20Ubuntu%20LTS%20bigmem%203.x/builds/165/steps/test/logs/stdio ====================================================================== ERROR: test_huge_str_32b (test.test_pickle.InMemoryPickleTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/opt/python-bigmem/3.x.langa-bigmem/build/Lib/test/support.py", line 1281, in wrapper return f(self, maxsize) File "/opt/python-bigmem/3.x.langa-bigmem/build/Lib/test/pickletester.py", line 1267, in test_huge_str_32b pickled = self.dumps(data, protocol=proto) File "/opt/python-bigmem/3.x.langa-bigmem/build/Lib/test/test_pickle.py", line 49, in dumps return pickle.dumps(arg, protocol) MemoryError ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 00:47:59 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 08 Aug 2012 22:47:59 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1317341390.65.0.255779328054.issue13072@psf.upfronthosting.co.za> Message-ID: <3Wsnmr5yVzzQ1W@mail.python.org> Roundup Robot added the comment: New changeset 4ee4cceda047 by Victor Stinner in branch 'default': Issue #13072: Fix test_array for installation without the ctypes module http://hg.python.org/cpython/rev/4ee4cceda047 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 00:48:29 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Aug 2012 22:48:29 +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: <1344466109.55.0.65262958103.issue15594@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +hynek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 00:59:53 2012 From: report at bugs.python.org (Stefan Krah) Date: Wed, 08 Aug 2012 22:59:53 +0000 Subject: [issue15589] Bus error on Debian sparc In-Reply-To: <1344417411.0.0.396332340112.issue15589@psf.upfronthosting.co.za> Message-ID: <1344466793.11.0.272370842148.issue15589@psf.upfronthosting.co.za> Stefan Krah added the comment: As for the original error: in test_subprocess basically every test fails. With the standard regrtest.py (faulthandler enabled), most tests generate a bus error in subprocess_fork_exec(): 621 cwd_obj2 = NULL; (gdb) 624 pid = fork(); <- bus error (gdb) Fatal Python error: Bus error Current thread 0x00004000: File "/home/user/cpython/Lib/subprocess.py", line 1363 in _execute_child File "/home/user/cpython/Lib/subprocess.py", line 818 in __init__ File "/home/user/cpython/Lib/test/test_subprocess.py", line 728 in test_bufsize_is_none 621 cwd_obj2 = NULL; (gdb) 624 pid = fork(); <- bus error (gdb) Fatal Python error: Bus error Current thread 0x00004000: File "/home/user/cpython/Lib/subprocess.py", line 1363 in _execute_child File "/home/user/cpython/Lib/subprocess.py", line 818 in __init__ File "/home/user/cpython/Lib/test/test_subprocess.py", line 728 in test_bufsize_is_none With all faulthandler references removed from regrtest.py no bus errors happen, but most tests fail anyway. As I said, I'm NOT blaming faulthandler, but suspect some strange platform bug that perhaps involves linuxthreads. Since Floris can't reproduce this error, I'm setting the priority to normal. ---------- priority: critical -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 01:16:49 2012 From: report at bugs.python.org (Ned Deily) Date: Wed, 08 Aug 2012 23:16:49 +0000 Subject: [issue15597] exception __suppress_context__ test failures on OS X ppc systems Message-ID: <1344467808.95.0.390375910208.issue15597@psf.upfronthosting.co.za> New submission from Ned Deily: == CPython 3.3.0b1 (default:efb30bdcfa1e, Aug 8 2012, 15:43:49) [GCC 4.0.1 (Apple Inc. build 5493)] == Darwin-8.11.0-Power_Macintosh-powerpc-32bit big-endian == /private/tmp/test_python_13864 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) [...] ====================================================================== FAIL: testChainingDescriptors (test.test_exceptions.ExceptionTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_exceptions.py", line 432, in testChainingDescriptors self.assertTrue(e.__suppress_context__) AssertionError: False is not true ---------------------------------------------------------------------- Other similar test failures include multiple test cases in test_ipaddress, test_raise, and test_traceback, for example: ====================================================================== FAIL: test_address_errors (test.test_ipaddress.NetworkTestCase_v6) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/ipaddress.py", line 1580, in _ip_int_from_string ip_int |= self._parse_hextet(parts[i]) File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/ipaddress.py", line 1605, in _parse_hextet raise ValueError("Only hex digits permitted in %r" % hextet_str) ValueError: Only hex digits permitted in 'axy' During handling of the above exception, another exception occurred: ipaddress.AddressValueError: Only hex digits permitted in 'axy' in '1234:axy::b' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_ipaddress.py", line 439, in test_address_errors assertBadAddress("1234:axy::b", "Only hex digits") File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_ipaddress.py", line 432, in assertBadAddress self.factory(addr) File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/contextlib.py", line 66, in __exit__ self.gen.throw(type, value, traceback) File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_ipaddress.py", line 50, in assertCleanError self.assertTrue(exc.exception.__suppress_context__) AssertionError: False is not true The same universal build runs without error on an Intel Mac with the same os version. The ppc failures are seen on both PPC OS X 10.5 and 10.4 systems. ---------- messages: 167734 nosy: benjamin.peterson, ned.deily, pitrou priority: critical severity: normal stage: needs patch status: open title: exception __suppress_context__ test failures on OS X ppc systems type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 01:19:27 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Aug 2012 23:19:27 +0000 Subject: [issue15595] subprocess.Popen(universal_newlines=True) does not work for certain locales In-Reply-To: <1344461775.23.0.274836365722.issue15595@psf.upfronthosting.co.za> Message-ID: <1344467967.28.0.437761536813.issue15595@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 01:20:51 2012 From: report at bugs.python.org (Floris Bruynooghe) Date: Wed, 08 Aug 2012 23:20:51 +0000 Subject: [issue15589] Bus error on Debian sparc In-Reply-To: <1344417411.0.0.396332340112.issue15589@psf.upfronthosting.co.za> Message-ID: <1344468051.64.0.652811484912.issue15589@psf.upfronthosting.co.za> Floris Bruynooghe added the comment: I can now confirm the whole testsuite runs, so the BusError part seems fixed on my host: 329 tests OK. 7 tests failed: test_cmd_line test_exceptions test_ipaddress test_os test_raise test_socket test_traceback 1 test altered the execution environment: test_site 32 tests skipped: test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_dbm_gnu test_epoll test_gdb test_kqueue test_lzma test_msilib test_ossaudiodev test_pep277 test_readline test_smtpnet test_socketserver test_sqlite test_ssl test_startfile test_tcl test_timeout test_tk test_ttk_guionly test_ttk_textonly test_unicode_file test_urllib2net test_urllibnet test_winreg test_winsound test_xmlrpc_net test_zipfile64 8 skips unexpected on sunos5: test_lzma test_readline test_smtpnet test_ssl test_tcl test_tk test_ttk_guionly test_ttk_textonly ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 01:26:37 2012 From: report at bugs.python.org (Stefan Krah) Date: Wed, 08 Aug 2012 23:26:37 +0000 Subject: [issue15589] Bus error on Debian sparc In-Reply-To: <1344417411.0.0.396332340112.issue15589@psf.upfronthosting.co.za> Message-ID: <1344468397.29.0.890799555363.issue15589@psf.upfronthosting.co.za> Stefan Krah added the comment: > 329 tests OK. > 7 tests failed: > test_cmd_line test_exceptions test_ipaddress test_os test_raise > test_socket test_traceback Thanks. A lot of these appear to be big-endian related, see #15597. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 01:27:27 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Aug 2012 23:27:27 +0000 Subject: [issue15589] Bus error on Debian sparc In-Reply-To: <1344417411.0.0.396332340112.issue15589@psf.upfronthosting.co.za> Message-ID: <1344468446.99.0.939486407593.issue15589@psf.upfronthosting.co.za> STINNER Victor added the comment: > With all faulthandler references removed from regrtest.py no > bus errors happen, but most tests fail anyway. As I said, I'm > NOT blaming faulthandler, but suspect some strange platform > bug that perhaps involves linuxthreads. Threads + signal is a very complex problem. It is not solved yet in OpenBSD for example. There were a lot of such issues on old versions of FreeBSD. Extract of the Wikipedia article of LinuxThreads: "LinuxThreads had a number of problems, mainly owing to the implementation, which used the clone system call to create a new process sharing the parent's address space. For example, threads had distinct process identifiers, causing problems for signal handling; (...)" If disabling faulthandler avoids new issues, you can add 'if sys.thread_info.version.startswith("linuxthreads"):" on the line: faulthandler.enable(all_threads=True) in regrtest.py. I added sys.thread_info to be able to skip some tests only failing on LinuxThreads... -- > but most tests fail anyway Ah? With which message? Can you get more information in gdb? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 01:28:49 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Aug 2012 23:28:49 +0000 Subject: [issue15597] exception __suppress_context__ test failures on OS X ppc systems In-Reply-To: <1344467808.95.0.390375910208.issue15597@psf.upfronthosting.co.za> Message-ID: <1344468529.24.0.509638776123.issue15597@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 01:30:39 2012 From: report at bugs.python.org (Ned Deily) Date: Wed, 08 Aug 2012 23:30:39 +0000 Subject: [issue15597] exception __suppress_context__ test failures on OS X ppc systems In-Reply-To: <1344467808.95.0.390375910208.issue15597@psf.upfronthosting.co.za> Message-ID: <1344468639.19.0.96199645027.issue15597@psf.upfronthosting.co.za> Ned Deily added the comment: It appears similar failures are occuring on Sparc platforms (see issue15589) another big-endian platform. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 01:56:55 2012 From: report at bugs.python.org (Ned Deily) Date: Wed, 08 Aug 2012 23:56:55 +0000 Subject: [issue15597] exception __suppress_context__ test failures on OS X ppc systems In-Reply-To: <1344467808.95.0.390375910208.issue15597@psf.upfronthosting.co.za> Message-ID: <1344470215.85.0.919448365506.issue15597@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 02:05:34 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 09 Aug 2012 00:05:34 +0000 Subject: [issue15597] exception __suppress_context__ test failures on OS X ppc systems In-Reply-To: <1344467808.95.0.390375910208.issue15597@psf.upfronthosting.co.za> Message-ID: <1344470734.94.0.719041074637.issue15597@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Does this fix it? ---------- keywords: +patch Added file: http://bugs.python.org/file26731/char.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 02:09:39 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Aug 2012 00:09:39 +0000 Subject: [issue15597] exception __suppress_context__ test failures on OS X ppc systems In-Reply-To: <1344467808.95.0.390375910208.issue15597@psf.upfronthosting.co.za> Message-ID: <1344470979.35.0.60856751492.issue15597@psf.upfronthosting.co.za> STINNER Victor added the comment: __suppress_context__ is a member using T_BOOL type. T_BOOL expects the C type "char", whereas the field in the PyBaseExceptionObject is a C "int". Attached patch changes the type and should fix the issue. The test fails because writing into the field uses: *(char*)field = value; Which does not work in big endian if the field is a pointer to an int. ---------- Added file: http://bugs.python.org/file26732/exception.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 02:17:43 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Aug 2012 00:17:43 +0000 Subject: [issue15595] subprocess.Popen(universal_newlines=True) does not work for certain locales In-Reply-To: <1344461775.23.0.274836365722.issue15595@psf.upfronthosting.co.za> Message-ID: <1344471461.67.0.603097282527.issue15595@psf.upfronthosting.co.za> STINNER Victor added the comment: There is a bug, but I'm not conviced that multibyte encodings are used as locale encoding. About your patch: you should test the 3 types of newlines, so use a string like: '1\r\n2\r3\n4'. + # Popen() defaults to locale.getpreferredencoding(False). + locale.getpreferredencoding = lambda do_setlocale: 'utf-16' FYI it's not directly Popen() which uses the locale encoding, but TextIOWrapper. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 02:18:11 2012 From: report at bugs.python.org (Antony Lee) Date: Thu, 09 Aug 2012 00:18:11 +0000 Subject: [issue15598] relative import unexpectedly binds name Message-ID: <1344471488.35.0.495705727003.issue15598@psf.upfronthosting.co.za> New submission from Antony Lee: The language reference is clear: "The from form does not bind the module name" (Section 6.12) However, consider the following example: * package/__init__.py: foo = "FOO" from .foo import bar print(foo) os = "OS" from os import path print(os) * package/foo.py: foo = 42 Now "import package" results in printing: OS i.e., the relative "from ... import" has not only bound "bar", but also "foo", which seems to contradict the documentation. (I get the same behaviour using 3.2.3 as well as 2.7.3.) ---------- messages: 167742 nosy: Antony.Lee priority: normal severity: normal status: open title: relative import unexpectedly binds name versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 02:18:36 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Aug 2012 00:18:36 +0000 Subject: [issue15598] relative import unexpectedly binds name In-Reply-To: <1344471488.35.0.495705727003.issue15598@psf.upfronthosting.co.za> Message-ID: <1344471516.24.0.449779574548.issue15598@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 02:23:08 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 Aug 2012 00:23:08 +0000 Subject: [issue15597] exception __suppress_context__ test failures on OS X ppc systems In-Reply-To: <1344467808.95.0.390375910208.issue15597@psf.upfronthosting.co.za> Message-ID: <3WsqtZ6cZ7zQ1s@mail.python.org> Roundup Robot added the comment: New changeset e2df976b8a33 by Benjamin Peterson in branch 'default': use char instead of int to please T_BOOL (closes #15597) http://hg.python.org/cpython/rev/e2df976b8a33 ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 02:24:43 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 09 Aug 2012 00:24:43 +0000 Subject: [issue15595] subprocess.Popen(universal_newlines=True) does not work for certain locales In-Reply-To: <1344461775.23.0.274836365722.issue15595@psf.upfronthosting.co.za> Message-ID: <1344471883.51.0.40820254044.issue15595@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Thanks for your comments. > FYI it's not directly Popen() which uses the locale encoding, but TextIOWrapper. Yes, I will note that to be more clear. Would you like me to add tests for UTF-16-LE, etc. (via a helper test method), or will UTF-16 alone suffice? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 02:37:21 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Aug 2012 00:37:21 +0000 Subject: [issue15595] subprocess.Popen(universal_newlines=True) does not work for certain locales In-Reply-To: <1344461775.23.0.274836365722.issue15595@psf.upfronthosting.co.za> Message-ID: <1344472641.79.0.520011002357.issue15595@psf.upfronthosting.co.za> STINNER Victor added the comment: > Would you like me to add tests for UTF-16-LE, etc. (via a helper test method), or will UTF-16 alone suffice? You can use a loop insteadd of an helper function. I fail to see other encoding having the same issue, except the UTF-32 family (utf-32, utf-32-le, utf-32-be). I don't think that writing a test for the 6 codecs is required, you can use utf-16 and utf-32-be. So you test without BOM and with BOM, and utf-16 and utf-32. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 02:41:36 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 09 Aug 2012 00:41:36 +0000 Subject: [issue15598] relative import unexpectedly binds name In-Reply-To: <1344471488.35.0.495705727003.issue15598@psf.upfronthosting.co.za> Message-ID: <1344472896.71.0.880748404587.issue15598@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I don't think this is incorrect. Importing a submodule implicit sets its name in the package scope, which is __init__'s module scope. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 02:59:34 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Aug 2012 00:59:34 +0000 Subject: [issue15599] test_circular_imports() of test_threaded_import fails on FreeBSD 9.0 Message-ID: <1344473974.14.0.584788696764.issue15599@psf.upfronthosting.co.za> New submission from STINNER Victor: http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%203.x/builds/3231/steps/test/logs/stdio [111/369] test_threaded_import test_circular_imports (test.test_threaded_import.ThreadedImportTests) ... Exception in thread Thread-586: Traceback (most recent call last): File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/threading.py", line 639, in _bootstrap_inner self.run() File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/threading.py", line 596, in run self._target(*self._args, **self._kwargs) File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_threaded_import.py", line 194, in import_ab import A ImportError: No module named 'A' Exception in thread Thread-587: Traceback (most recent call last): File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/threading.py", line 639, in _bootstrap_inner self.run() File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/threading.py", line 596, in run self._target(*self._args, **self._kwargs) File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_threaded_import.py", line 197, in import_ba import B ImportError: No module named 'B' FAIL test_import_hangers (test.test_threaded_import.ThreadedImportTests) ... ok test_parallel_meta_path (test.test_threaded_import.ThreadedImportTests) ... Trying 20 threads ... OK. Trying 50 threads ... OK. Trying 20 threads ... OK. Trying 50 threads ... OK. Trying 20 threads ... OK. Trying 50 threads ... OK. ok test_parallel_module_init (test.test_threaded_import.ThreadedImportTests) ... Trying 20 threads ... OK. Trying 50 threads ... OK. Trying 20 threads ... OK. Trying 50 threads ... OK. Trying 20 threads ... OK. Trying 50 threads ... OK. ok test_parallel_path_hooks (test.test_threaded_import.ThreadedImportTests) ... Trying 20 threads ... OK. Trying 50 threads ... OK. Trying 20 threads ... OK. Trying 50 threads ... OK. Trying 20 threads ... OK. Trying 50 threads ... OK. ok test_side_effect_import (test.test_threaded_import.ThreadedImportTests) ... ok ====================================================================== FAIL: test_circular_imports (test.test_threaded_import.ThreadedImportTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_threaded_import.py", line 205, in test_circular_imports self.assertEqual(set(results), {'a', 'b'}) AssertionError: Items in the second set but not the first: 'a' 'b' ---------------------------------------------------------------------- ---------- messages: 167747 nosy: brett.cannon, haypo priority: normal severity: normal status: open title: test_circular_imports() of test_threaded_import fails on FreeBSD 9.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 03:02:04 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 09 Aug 2012 01:02:04 +0000 Subject: [issue15595] subprocess.Popen(universal_newlines=True) does not work for certain locales In-Reply-To: <1344461775.23.0.274836365722.issue15595@psf.upfronthosting.co.za> Message-ID: <1344474124.8.0.97280300847.issue15595@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Updating patch with Victor's comments. ---------- Added file: http://bugs.python.org/file26733/issue-15595-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 03:14:21 2012 From: report at bugs.python.org (Ned Deily) Date: Thu, 09 Aug 2012 01:14:21 +0000 Subject: [issue15597] exception __suppress_context__ test failures on OS X ppc systems In-Reply-To: <1344467808.95.0.390375910208.issue15597@psf.upfronthosting.co.za> Message-ID: <1344474861.25.0.374010681672.issue15597@psf.upfronthosting.co.za> Ned Deily added the comment: The patch does indeed fix all of the __suppress_context__ related test failures previously seen, i.e. test_exceptions, test_ipaddress, test_raise, and test_traceback. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 03:20:02 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 09 Aug 2012 01:20:02 +0000 Subject: [issue15595] subprocess.Popen(universal_newlines=True) does not work for certain locales In-Reply-To: <1344461775.23.0.274836365722.issue15595@psf.upfronthosting.co.za> Message-ID: <1344475202.98.0.164152512306.issue15595@psf.upfronthosting.co.za> Chris Jerdonek added the comment: It looks like this also affects 3.2, but I will need to modify the test slightly because in 3.2, TextIOWrapper calls locale.getpreferredencoding() without any arguments. ---------- versions: +Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 03:22:05 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Aug 2012 01:22:05 +0000 Subject: [issue9635] Add Py_BREAKPOINT and sys._breakpoint hooks In-Reply-To: <1282175005.37.0.905894818052.issue9635@psf.upfronthosting.co.za> Message-ID: <1344475325.78.0.360448888195.issue9635@psf.upfronthosting.co.za> STINNER Victor added the comment: > I thought about it making it METH_O instead (to make it easier to > look at a single object), but then you'd be forced to pass an object > in when using it, I think (though None should work). I don't like this API. I really prefer METH_O because it is already very difficult to dump a Python object in a debugger (especially with gdb macros). Why not using two functions? One without argument, One with an argument. The sys module is maybe not the right place for such low level function. You may create a new module with a name starting with _ (ex: _python_dbg). I'm quite sure that you will find other nice functions to add if you have a module dedicated to debugging :-) If you don't want to create a new module, faulthandler might be used to add new debug functions. It's maybe unrelated, but Brian Curtin also created a module to help debugging with Visual Studio: https://bitbucket.org/briancurtin/minidumper/ We may use the same module for all debugging functions? (I suppose that Brian Curtin wants to integrate its minidumper into Python 3.4.) Example: * faulthandler._breakpoint() * faulthandler._inspect(obj) # breakpoint with an object * faulthandler.enable_minidumper(...) * faulthandler.disable_minidumper(...) -- For Power PC, the machine code to generate a breakpoint is 0x0cc00000. The instruction looks to be called twllei. Something like: "twllei reg_ZERO,trap_Cerror". Hum, it looks like there is family of instructions related to trap: all TW* instructions (twle, twlt, twge, ...). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 03:25:55 2012 From: report at bugs.python.org (rurpy the second) Date: Thu, 09 Aug 2012 01:25:55 +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: <1344475555.1.0.370907028163.issue15216@psf.upfronthosting.co.za> Changes by rurpy the second : ---------- nosy: +rurpy2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 03:44:49 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 09 Aug 2012 01:44:49 +0000 Subject: [issue15598] relative import unexpectedly binds name In-Reply-To: <1344471488.35.0.495705727003.issue15598@psf.upfronthosting.co.za> Message-ID: <1344476689.32.0.39448773866.issue15598@psf.upfronthosting.co.za> Eric Snow added the comment: I agree with Benjamin. The name is not bound due to the from-import statement. ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 03:47:35 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 09 Aug 2012 01:47:35 +0000 Subject: [issue15598] relative import unexpectedly binds name In-Reply-To: <1344471488.35.0.495705727003.issue15598@psf.upfronthosting.co.za> Message-ID: <1344476855.02.0.378358765321.issue15598@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 03:48:43 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 09 Aug 2012 01:48:43 +0000 Subject: [issue15595] subprocess.Popen(universal_newlines=True) does not work for certain locales In-Reply-To: <1344461775.23.0.274836365722.issue15595@psf.upfronthosting.co.za> Message-ID: <1344476923.59.0.939554175416.issue15595@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Here is a patch also suitable for applying to Python 3.2. ---------- Added file: http://bugs.python.org/file26734/issue-15595-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 04:08:19 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 09 Aug 2012 02:08:19 +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: <1344478099.91.0.0886645207953.issue15216@psf.upfronthosting.co.za> Nick Coghlan added the comment: To bring back Victor's comments from the list: - stdout/stderr are fairly easy to handle, since the underlying buffers can be flushed before switching the encoding and error settings. Yes, there's a risk of creating mojibake, but that's unavoidable and, for this use case, trumped by the pragmatic need to support overriding the output encoding in a robust fashion (i.e. not breaking sys.__stdout__ or sys.__stderr__, and not crashing if something else displays output during startup, for example, when running under "python -v") - stdin is more challenging, since it isn't entirely clear yet how to handle the case where data is already buffered internally. Victor proposes that it's acceptable to simply disallow changing the encoding of a stream that isn't seekable. My feeling is that such a restriction would largely miss the point, since the original use case that prompted the creation of this was shell pipeline processing, where stdin will often be a PIPE I think the guiding use case here really needs to be this one: "How do I implement the equivalent of 'iconv' as a Python 3 script, without breaking internal interpreter state invariants?" My current thought is that, instead of seeking, the input case can better be handled by manipulating the read ahead buffer directly. Something like (for the pure Python version): self._encoding = new_encoding if self._decoder is not None: old_data = self._get_decoded_chars().encode(old_encoding) old_data += self._decoder.getstate()[0] decoder = self._get_decoder() new_chars = '' if old_data: new_chars = decoder.decode(old_data) self._set_decoded_chars(new_chars) (A similar mechanism could actually be used to support an "initial_data" parameter to TextIOWrapper, which would help in general encoding detection situations where changing encoding *in-place* isn't needed, but the application would like an easy way to "put back" the initial data for inclusion in the text stream without making assumptions about the underlying buffer implementation) Also, StringIO should implement this new API as a no-op. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 05:43:21 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 09 Aug 2012 03:43:21 +0000 Subject: [issue15600] expose the finder details used by the FileFinder path hook Message-ID: <1344483800.66.0.152640034936.issue15600@psf.upfronthosting.co.za> New submission from Eric Snow: The path hook associated with importlib.machinery.FileFinder hides away its loader details in a closure. This is less than ideal for the purposes of introspection and general hacking. Here's a simple patch that exposes the loader details as an attribute on the path hook. This came up in issue 15576 (see msg167632). ---------- components: Interpreter Core files: loader_details.diff keywords: patch messages: 167755 nosy: brett.cannon, eric.snow, scoder priority: normal severity: normal stage: patch review status: open title: expose the finder details used by the FileFinder path hook type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file26735/loader_details.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 05:44:39 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 09 Aug 2012 03:44:39 +0000 Subject: [issue15576] importlib: ExtensionFileLoader not used to load packages from __init__.so files In-Reply-To: <1344364550.12.0.263881849199.issue15576@psf.upfronthosting.co.za> Message-ID: <1344483879.37.0.527960400177.issue15576@psf.upfronthosting.co.za> Eric Snow added the comment: Addressed question of introspecting loader_details in issue 15600. (see msg167632) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 06:00:40 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 09 Aug 2012 04:00:40 +0000 Subject: [issue15600] expose the finder details used by the FileFinder path hook In-Reply-To: <1344483800.66.0.152640034936.issue15600@psf.upfronthosting.co.za> Message-ID: <1344484840.68.0.916352174286.issue15600@psf.upfronthosting.co.za> Eric Snow added the comment: The alternative is this: path_hook.__closure__[1].cell_contents ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 06:03:48 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 Aug 2012 04:03:48 +0000 Subject: [issue14992] os.makedirs expect_ok=True test_os failure when directory has S_ISGID bit set In-Reply-To: <1338750994.84.0.984038556909.issue14992@psf.upfronthosting.co.za> Message-ID: <3WswnG1Yr3zP8w@mail.python.org> Roundup Robot added the comment: New changeset 3f42c9dbd8a7 by Ned Deily in branch '3.2': Issue #14992: Prevent test_os test_exist_ok_s_isgid_directory test case http://hg.python.org/cpython/rev/3f42c9dbd8a7 New changeset a1c8c79e035d by Ned Deily in branch 'default': Issue #14992: merge from 3.2 http://hg.python.org/cpython/rev/a1c8c79e035d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 06:33:53 2012 From: report at bugs.python.org (Ned Deily) Date: Thu, 09 Aug 2012 04:33:53 +0000 Subject: [issue15601] tkinter test_variables fails with OS X Aqua Tk 8.4 Message-ID: <1344486833.0.0.731183249876.issue15601@psf.upfronthosting.co.za> New submission from Ned Deily: ====================================================================== FAIL: test_get (tkinter.test.test_tkinter.test_variables.TestStringVar) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/tkinter/test/test_tkinter/test_variables.py", line 85, in test_get self.assertEqual("1", v.get()) AssertionError: '1' != 'True' - 1 + True The OS X 32-bit installers for OS X 10.5+ link with Tcl/Tk 8.4 as that was the only version supplied by Apple for 10.5. The test passes when linked with the Aqua Tcl/Tk 8.5 available in OS X 10.6+ and used with the 64-/32-bit OS X installers. ---------- components: Tests, Tkinter messages: 167759 nosy: asvetlov, ned.deily priority: normal severity: normal stage: needs patch status: open title: tkinter test_variables fails with OS X Aqua Tk 8.4 versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 07:22:18 2012 From: report at bugs.python.org (Eli Bendersky) Date: Thu, 09 Aug 2012 05:22:18 +0000 Subject: [issue15586] Provide some examples for usage of ElementTree methods/attributes In-Reply-To: <1344407679.24.0.102359835139.issue15586@psf.upfronthosting.co.za> Message-ID: <1344489738.78.0.768217514095.issue15586@psf.upfronthosting.co.za> Changes by Eli Bendersky : ---------- versions: +Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 08:20:46 2012 From: report at bugs.python.org (monson) Date: Thu, 09 Aug 2012 06:20:46 +0000 Subject: [issue15602] zipfile: wrong encoding charset of member filename Message-ID: <1344493246.11.0.837013497182.issue15602@psf.upfronthosting.co.za> New submission from monson: In /cpython/Lib/zipfile.py, there are some codes like if flags & 0x800: # UTF-8 file names extension filename = filename.decode('utf-8') else: # Historical ZIP filename encoding filename = filename.decode('cp437') But actually there is no "Historical ZIP filename encoding", because zip files contain no charset info. In English countries, it's usually not a big deal. But if the files zip on a non-cp437-based system (especially like China or Japan), filename is encoded from charsets like gb18030, but ZipFile decodes the byte stream to cp437, then everything goes wrong and people are hard to find the reason. It's a problem new in py3k, and I found it on python3.2 and python3.4. I suggest the filename returned in Bytes objects, or add decoding parameter when opening zipfile. ---------- components: Library (Lib) messages: 167760 nosy: monson priority: normal severity: normal status: open title: zipfile: wrong encoding charset of member filename type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 08:24:36 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 09 Aug 2012 06:24:36 +0000 Subject: [issue12834] memoryview.to_bytes() and PyBuffer_ToContiguous() incorrect for non-contiguous arrays In-Reply-To: <1314211505.01.0.756597830367.issue12834@psf.upfronthosting.co.za> Message-ID: <1344493476.98.0.0307216309643.issue12834@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Removing 3.1, since its addition was apparently done by mistake. Again, I wonder why this is marked release-critical. It's not a regression from previous versions, is it? Please use release-critical only if not making a release at a certain point in the future is better than making the release (despite all the advantages that the release otherwise might have). If you merely think that the issue is "really important" and "should not be forgotten", use "critical" or "high". ---------- nosy: +loewis versions: -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 08:35:54 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 09 Aug 2012 06:35:54 +0000 Subject: [issue12834] memoryview.to_bytes() and PyBuffer_ToContiguous() incorrect for non-contiguous arrays In-Reply-To: <1314211505.01.0.756597830367.issue12834@psf.upfronthosting.co.za> Message-ID: <1344494154.97.0.295974020678.issue12834@psf.upfronthosting.co.za> Nick Coghlan added the comment: Since the next release of 3.2 is the *last* release of 3.2, yet it will remain supported by distros well beyond that, yes, I think this should block the final 3.2 release. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 08:50:37 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 09 Aug 2012 06:50:37 +0000 Subject: [issue15601] tkinter test_variables fails with OS X Aqua Tk 8.4 In-Reply-To: <1344486833.0.0.731183249876.issue15601@psf.upfronthosting.co.za> Message-ID: <1344495037.32.0.491799455793.issue15601@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The purpose of the test is to test whether get works on a string variable. Any boolean/string conversions aren't really relevant here, so we should just use a second string in the test (e.g. "def"), instead of True. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 08:59:18 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 09 Aug 2012 06:59:18 +0000 Subject: [issue12834] memoryview.to_bytes() and PyBuffer_ToContiguous() incorrect for non-contiguous arrays In-Reply-To: <1344494154.97.0.295974020678.issue12834@psf.upfronthosting.co.za> Message-ID: <50235FC1.5070103@v.loewis.de> Martin v. L?wis added the comment: > Since the next release of 3.2 is the *last* release of 3.2, yet it > will remain supported by distros well beyond that, yes, I think this > should block the final 3.2 release. But the same will be true for any other bug that 3.2 has. If they don't get fixed now, they will remain unfixed. Should we therefore delay the last release of 3.2 until all bugs in it are fixed? The consequence instead should be that people experiencing this bug will have to move to Python 3.3 to get it fixed. Since it only affects NumPy users (AFAICT), and then only those who use tobytes, I wouldn't consider this bug even critical. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 09:44:05 2012 From: report at bugs.python.org (Stefan Krah) Date: Thu, 09 Aug 2012 07:44:05 +0000 Subject: [issue12834] memoryview.to_bytes() and PyBuffer_ToContiguous() incorrect for non-contiguous arrays In-Reply-To: <1314211505.01.0.756597830367.issue12834@psf.upfronthosting.co.za> Message-ID: <1344498245.9.0.728484728947.issue12834@psf.upfronthosting.co.za> Stefan Krah added the comment: > Removing 3.1, since its addition was apparently done by mistake. I'm unable to set 2.7 and 3.2 in my browser without also setting 3.1 (using the Shift key to mark multiple fields). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 09:45:49 2012 From: report at bugs.python.org (Eli Bendersky) Date: Thu, 09 Aug 2012 07:45:49 +0000 Subject: [issue15586] Provide some examples for usage of ElementTree methods/attributes In-Reply-To: <1344407679.24.0.102359835139.issue15586@psf.upfronthosting.co.za> Message-ID: <1344498349.65.0.455737722523.issue15586@psf.upfronthosting.co.za> Eli Bendersky added the comment: I provided some comments on your patch in the code-review tool. Thanks for the contribution, Daniel. It's fine to first apply these changes to 3.3 and then backport to 2.7 (I don't think 3.2 is necessary because most users use the online docs anyway). ---------- versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 09:46:08 2012 From: report at bugs.python.org (Eli Bendersky) Date: Thu, 09 Aug 2012 07:46:08 +0000 Subject: [issue15586] Provide some examples for usage of ElementTree methods/attributes In-Reply-To: <1344407679.24.0.102359835139.issue15586@psf.upfronthosting.co.za> Message-ID: <1344498368.76.0.219352976598.issue15586@psf.upfronthosting.co.za> Changes by Eli Bendersky : ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 09:47:47 2012 From: report at bugs.python.org (Eli Bendersky) Date: Thu, 09 Aug 2012 07:47:47 +0000 Subject: [issue15586] Provide some examples for usage of ElementTree methods/attributes In-Reply-To: <1344407679.24.0.102359835139.issue15586@psf.upfronthosting.co.za> Message-ID: <1344498467.73.0.0850538261643.issue15586@psf.upfronthosting.co.za> Eli Bendersky added the comment: Sarbjit, if you look at the docs of 3.3, I think most of what you're asking for is there (especially once you count Daniel's commit). What else is missing in your opinion? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 09:52:08 2012 From: report at bugs.python.org (Eli Bendersky) Date: Thu, 09 Aug 2012 07:52:08 +0000 Subject: [issue15231] update PyPI upload doc to say --no-raw passed to rst2html.py In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za> Message-ID: <1344498728.4.0.878268594421.issue15231@psf.upfronthosting.co.za> Eli Bendersky added the comment: My job is done here. ?ric - assigning to you for distutils2, once it becomes relevant. ---------- assignee: docs at python -> eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 09:52:29 2012 From: report at bugs.python.org (Eli Bendersky) Date: Thu, 09 Aug 2012 07:52:29 +0000 Subject: [issue15231] update PyPI upload doc to say --no-raw passed to rst2html.py In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za> Message-ID: <1344498749.89.0.396781934889.issue15231@psf.upfronthosting.co.za> Changes by Eli Bendersky : ---------- nosy: -eli.bendersky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 10:08:08 2012 From: report at bugs.python.org (Stefan Krah) Date: Thu, 09 Aug 2012 08:08:08 +0000 Subject: [issue15599] test_circular_imports() of test_threaded_import fails on FreeBSD 9.0 In-Reply-To: <1344473974.14.0.584788696764.issue15599@psf.upfronthosting.co.za> Message-ID: <1344499688.49.0.605859102617.issue15599@psf.upfronthosting.co.za> Stefan Krah added the comment: The buildbot is running inside kvm on a heavily loaded machine. Perhaps some timeout is too low. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 10:11:56 2012 From: report at bugs.python.org (Eli Bendersky) Date: Thu, 09 Aug 2012 08:11:56 +0000 Subject: [issue15586] Provide some examples for usage of ElementTree methods/attributes In-Reply-To: <1344407679.24.0.102359835139.issue15586@psf.upfronthosting.co.za> Message-ID: <1344499916.61.0.398592354834.issue15586@psf.upfronthosting.co.za> Eli Bendersky added the comment: Sarbjit: first of all, look at the up-to-date documentation for 3.3 (it's available online at http://docs.python.org/dev/ Then, on a checkout of the 3.3 code (default branch) you can apply Daniel's patch (it's in the "Files" section in this Issue) and look at the updated documentation. MOST IMPORTANTLY: read http://docs.python.org/devguide/index.html thoroughly - it will answer most of your questions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 10:19:47 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 09 Aug 2012 08:19:47 +0000 Subject: [issue15457] consistent treatment of generator terminology In-Reply-To: <1343302676.51.0.168761959505.issue15457@psf.upfronthosting.co.za> Message-ID: <1344500387.93.0.362933816239.issue15457@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Note to reviewers: changing to "needs patch" because I want to make changes to the latest patch before this is reviewed (e.g. to the index directives). I should be able to do this by the end of the weekend. ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 10:31:22 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Aug 2012 08:31:22 +0000 Subject: [issue15216] Support setting the encoding on a text stream after creation In-Reply-To: <1344478099.91.0.0886645207953.issue15216@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > Victor proposes that it's acceptable to simply disallow changing the encoding of a stream that isn't seekable. It is no what I said. My patch raises an exception if you already started to read stdin. It should work fine if stdin is a pipe but the read buffer is empty. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 10:31:36 2012 From: report at bugs.python.org (Eli Bendersky) Date: Thu, 09 Aug 2012 08:31:36 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <1344501096.15.0.845407373023.issue14814@psf.upfronthosting.co.za> Eli Bendersky added the comment: Here's a patch adding documentation to the *Interface classes. I must say I'm not very psyched about the with_* methods. Their outputs are inconsistent, unlike in *Network, where all return strings. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 10:31:49 2012 From: report at bugs.python.org (Eli Bendersky) Date: Thu, 09 Aug 2012 08:31:49 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <1344501109.96.0.515071222188.issue14814@psf.upfronthosting.co.za> Changes by Eli Bendersky : Added file: http://bugs.python.org/file26736/ipaddr_refdoc_interface.1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 10:36:40 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 09 Aug 2012 08:36:40 +0000 Subject: [issue15355] generator docs should mention already-executing exception In-Reply-To: <1342312261.31.0.534711044354.issue15355@psf.upfronthosting.co.za> Message-ID: <1344501400.08.0.48755334652.issue15355@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Nick, would you be able to take a look at this minor documentation patch re: generators? Would you prefer this blanket statement, or an explicit (possibly repeated) statement inside the documentation of each method? ---------- versions: +Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 10:47:49 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 09 Aug 2012 08:47:49 +0000 Subject: [issue15602] zipfile: wrong encoding charset of member filename In-Reply-To: <1344493246.11.0.837013497182.issue15602@psf.upfronthosting.co.za> Message-ID: <1344502069.88.0.874625002017.issue15602@psf.upfronthosting.co.za> Martin v. L?wis added the comment: You are mistaken: there *is* a character set specification for file names in zip files, see http://www.pkware.com/documents/casestudies/APPNOTE.TXT Appendix D says "The ZIP format has historically supported only the original IBM PC character encoding set, commonly referred to as IBM Code Page 437. This limits storing file name characters to only those within the original MS-DOS range of values and does not properly support file names in other character encodings, or languages." Using bytes objects for file names is not acceptable; in Python 3, file names are (unicode) strings. Adding a new parameter is an option, and already discussed in issue 10614 . People using non-437 code sets should really start using UTF-8 encoded file names in the zip files, and set the general purpose bit 11. Closing this report as a duplicate. ---------- nosy: +loewis resolution: -> duplicate status: open -> closed superseder: -> ZipFile: add a filename_encoding argument _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 10:50:29 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 09 Aug 2012 08:50:29 +0000 Subject: [issue15600] expose the finder details used by the FileFinder path hook In-Reply-To: <1344483800.66.0.152640034936.issue15600@psf.upfronthosting.co.za> Message-ID: <1344502229.81.0.456889801589.issue15600@psf.upfronthosting.co.za> Chris Jerdonek added the comment: It seems like a test and documentation for this would be beneficial (for the usual reasons, etc). ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 12:33:50 2012 From: report at bugs.python.org (Stefan Krah) Date: Thu, 09 Aug 2012 10:33:50 +0000 Subject: [issue15589] Bus error on Debian sparc In-Reply-To: <1344417411.0.0.396332340112.issue15589@psf.upfronthosting.co.za> Message-ID: <1344508430.91.0.946604358984.issue15589@psf.upfronthosting.co.za> Stefan Krah added the comment: > If disabling faulthandler avoids new issues, you can add 'if > [not] sys.thread_info.version.startswith("linuxthreads")' That suppresses some bus errors. However, they still occur without being raised (some print statements and a WIFSIGNALED test inserted in posix_waitpid): >>> import subprocess, os >>> p = subprocess.Popen(["/bin/true"]) >>> os.waitpid(p.pid, os.WNOHANG) pid: 4461 options: 1 signo: 10 (4461, 10) >>> So a bus error occurs in waitpid(pid, &status, options).WAIT_TYPE is int, perhaps that's incorrect for the platform, but I can't get hold of the posix man pages for debian-etch-sparc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 13:03:00 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 09 Aug 2012 11:03:00 +0000 Subject: [issue15151] Documentation for Signature, Parameter and signature in inspect module In-Reply-To: <1340432030.73.0.594662136445.issue15151@psf.upfronthosting.co.za> Message-ID: <1344510180.33.0.279276102224.issue15151@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Update patch ---------- Added file: http://bugs.python.org/file26737/inspect.pep362.4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 13:25:09 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 09 Aug 2012 11:25:09 +0000 Subject: [issue15216] Support setting the encoding on a text stream after creation In-Reply-To: Message-ID: Nick Coghlan added the comment: Ah, you're right - peeking into the underlying buffer would be enough to handle encoding detection. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 13:26:49 2012 From: report at bugs.python.org (Anton Barkovsky) Date: Thu, 09 Aug 2012 11:26:49 +0000 Subject: [issue15501] Document exception classes in subprocess module In-Reply-To: <1343655102.86.0.835171642678.issue15501@psf.upfronthosting.co.za> Message-ID: <1344511609.88.0.197223857486.issue15501@psf.upfronthosting.co.za> Changes by Anton Barkovsky : Added file: http://bugs.python.org/file26738/subprocess_doc_2.7_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 13:26:57 2012 From: report at bugs.python.org (Anton Barkovsky) Date: Thu, 09 Aug 2012 11:26:57 +0000 Subject: [issue15501] Document exception classes in subprocess module In-Reply-To: <1343655102.86.0.835171642678.issue15501@psf.upfronthosting.co.za> Message-ID: <1344511617.26.0.723533877873.issue15501@psf.upfronthosting.co.za> Changes by Anton Barkovsky : Added file: http://bugs.python.org/file26739/subprocess_doc_3.2_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 13:27:04 2012 From: report at bugs.python.org (Anton Barkovsky) Date: Thu, 09 Aug 2012 11:27:04 +0000 Subject: [issue15501] Document exception classes in subprocess module In-Reply-To: <1343655102.86.0.835171642678.issue15501@psf.upfronthosting.co.za> Message-ID: <1344511624.09.0.453236504484.issue15501@psf.upfronthosting.co.za> Changes by Anton Barkovsky : Added file: http://bugs.python.org/file26740/subprocess_doc_3.3_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 13:27:31 2012 From: report at bugs.python.org (Anton Barkovsky) Date: Thu, 09 Aug 2012 11:27:31 +0000 Subject: [issue15501] Document exception classes in subprocess module In-Reply-To: <1343655102.86.0.835171642678.issue15501@psf.upfronthosting.co.za> Message-ID: <1344511651.69.0.162930884196.issue15501@psf.upfronthosting.co.za> Anton Barkovsky added the comment: Updated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 13:47:22 2012 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 09 Aug 2012 11:47:22 +0000 Subject: [issue15151] Documentation for Signature, Parameter and signature in inspect module In-Reply-To: <1340432030.73.0.594662136445.issue15151@psf.upfronthosting.co.za> Message-ID: <1344512842.58.0.765500370943.issue15151@psf.upfronthosting.co.za> Yury Selivanov added the comment: Thanks a lot for the patch update, Andrew! Please let me glance over it once again today/tomorrow before you commit it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 14:28:03 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 Aug 2012 12:28:03 +0000 Subject: [issue15501] Document exception classes in subprocess module In-Reply-To: <1343655102.86.0.835171642678.issue15501@psf.upfronthosting.co.za> Message-ID: <3Wt7z24nkPzQ26@mail.python.org> Roundup Robot added the comment: New changeset b863e231ad9f by Andrew Svetlov in branch 'default': Issue #15501: Document exception classes in subprocess module. http://hg.python.org/cpython/rev/b863e231ad9f New changeset 1e8f6d8e5c0e by Andrew Svetlov in branch '3.2': Issue #15501: Document exception classes in subprocess module. http://hg.python.org/cpython/rev/1e8f6d8e5c0e New changeset 9c99f31a9c2a by Andrew Svetlov in branch '2.7': Issue #15501: Document exception classes in subprocess module. http://hg.python.org/cpython/rev/9c99f31a9c2a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 14:34:07 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 09 Aug 2012 12:34:07 +0000 Subject: [issue14966] Fully document subprocess.CalledProcessError In-Reply-To: <1338446762.96.0.360332771622.issue14966@psf.upfronthosting.co.za> Message-ID: <1344515647.09.0.389586767185.issue14966@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Documented in #15501. I like to close this issue as duplicate. If anybody don't agree with closing feel free to reopen this one. ---------- nosy: +asvetlov resolution: -> duplicate stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 14:35:14 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 09 Aug 2012 12:35:14 +0000 Subject: [issue15501] Document exception classes in subprocess module In-Reply-To: <1343655102.86.0.835171642678.issue15501@psf.upfronthosting.co.za> Message-ID: <1344515714.7.0.495055669817.issue15501@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Fixed. Thank you, Anton. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed superseder: -> Fully document subprocess.CalledProcessError _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 15:14:48 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 09 Aug 2012 13:14:48 +0000 Subject: [issue15527] Double parens in functions references In-Reply-To: <1343833557.96.0.948912415493.issue15527@psf.upfronthosting.co.za> Message-ID: <1344518088.2.0.389463244262.issue15527@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 15:22:11 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 09 Aug 2012 13:22:11 +0000 Subject: [issue15557] Tests for webbrowser module In-Reply-To: <1344102778.31.0.864118033074.issue15557@psf.upfronthosting.co.za> Message-ID: <1344518531.78.0.526961324168.issue15557@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- dependencies: +A file is not properly closed by webbrowser._invoke, webbrowser.open sometimes passes zero-length argument to the browser. versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 15:22:17 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 09 Aug 2012 13:22:17 +0000 Subject: [issue4966] Improving Lib Doc Sequence Types Section In-Reply-To: <1232149418.64.0.0450574767427.issue4966@psf.upfronthosting.co.za> Message-ID: <1344518537.39.0.48354909717.issue4966@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 15:26:59 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 09 Aug 2012 13:26:59 +0000 Subject: [issue15561] update subprocess docs to reference io.TextIOWrapper In-Reply-To: <1344196317.87.0.366111796882.issue15561@psf.upfronthosting.co.za> Message-ID: <1344518819.53.0.702058379311.issue15561@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 15:28:02 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 09 Aug 2012 13:28:02 +0000 Subject: [issue10702] bytes and bytearray methods are not documented In-Reply-To: <1292347564.88.0.542769666771.issue10702@psf.upfronthosting.co.za> Message-ID: <1344518882.25.0.920920731396.issue10702@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti, ncoghlan stage: -> needs patch type: -> enhancement versions: +Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 15:31:53 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 09 Aug 2012 13:31:53 +0000 Subject: [issue11643] Use |version| instead of X.Y in the doc In-Reply-To: <1300838111.66.0.617899175478.issue11643@psf.upfronthosting.co.za> Message-ID: <1344519113.22.0.337640944886.issue11643@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- type: -> enhancement versions: +Python 3.4 -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 15:41:41 2012 From: report at bugs.python.org (Daniel Ellis) Date: Thu, 09 Aug 2012 13:41:41 +0000 Subject: [issue15586] Provide some examples for usage of ElementTree methods/attributes In-Reply-To: <1344407679.24.0.102359835139.issue15586@psf.upfronthosting.co.za> Message-ID: <1344519701.44.0.966525118285.issue15586@psf.upfronthosting.co.za> Daniel Ellis added the comment: Changes to documentation per Ezio and Eli's suggestions. ---------- Added file: http://bugs.python.org/file26741/default_branch_etree_doc_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 16:21:00 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Aug 2012 14:21:00 +0000 Subject: [issue15586] Provide some examples for usage of ElementTree methods/attributes In-Reply-To: <1344407679.24.0.102359835139.issue15586@psf.upfronthosting.co.za> Message-ID: <1344522060.61.0.113264137853.issue15586@psf.upfronthosting.co.za> R. David Murray added the comment: My understanding is that we try to keep the documentation of all active branches (2.7, 3.2, and 3.3 currently) in sync except where there are new features/new deprecations in the development version. So if the 2.7 docs are update, I think the 3.2 docs should be too. There will be one more release of 3.2, and the Windows version will bundle the docs, so I think it is worthwhile to do. But I'm not going to do it, so if no one volunteers to do it and apply the patch, that's fine :) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 16:44:00 2012 From: report at bugs.python.org (Daniel Ellis) Date: Thu, 09 Aug 2012 14:44:00 +0000 Subject: [issue15586] Provide some examples for usage of ElementTree methods/attributes In-Reply-To: <1344407679.24.0.102359835139.issue15586@psf.upfronthosting.co.za> Message-ID: <1344523440.85.0.843900868417.issue15586@psf.upfronthosting.co.za> Daniel Ellis added the comment: At the moment, the documentation for 2.7 is behind the documentation for 3.3. I will be working on backporting this next, but it will be a little more difficult than simply copying the existing documentation, since some key things in etree changed in the transition to 3.x. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 17:03:19 2012 From: report at bugs.python.org (Chris) Date: Thu, 09 Aug 2012 15:03:19 +0000 Subject: [issue15603] Multiprocessing creates incorrect pids Message-ID: <1344524599.55.0.473734451095.issue15603@psf.upfronthosting.co.za> New submission from Chris: http://stackoverflow.com/questions/11884864/python-multiprocessing-creates-incorrect-pids Jesse Noller suggested that I submit this stack overflow as a bug so it can be examined. As the problem is kind of domain specific, it's not easy to come up with a test case that can reproduce the issue. Please let me know what more information I can provide. Thanks! ---------- messages: 167788 nosy: cfriedline priority: normal severity: normal status: open title: Multiprocessing creates incorrect pids type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 17:24:16 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Aug 2012 15:24:16 +0000 Subject: [issue15604] PyObject_IsTrue failure checks Message-ID: <1344525855.66.0.08938802791.issue15604@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: PyObject_IsTrue can fail, but not everywhere in a code a returned value checked. Here is a patches which add such checks. Note, patches for all three Python versions are rather different. ---------- components: Interpreter Core, Library (Lib) files: istrue_check-3.3.patch keywords: needs review, patch messages: 167789 nosy: storchaka priority: normal severity: normal stage: patch review status: open title: PyObject_IsTrue failure checks type: resource usage versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file26742/istrue_check-3.3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 17:25:19 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Aug 2012 15:25:19 +0000 Subject: [issue15604] PyObject_IsTrue failure checks In-Reply-To: <1344525855.66.0.08938802791.issue15604@psf.upfronthosting.co.za> Message-ID: <1344525919.31.0.365913594465.issue15604@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file26743/istrue_check-3.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 17:25:54 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 09 Aug 2012 15:25:54 +0000 Subject: [issue11643] Use |version| instead of X.Y in the doc In-Reply-To: <1300838111.66.0.617899175478.issue11643@psf.upfronthosting.co.za> Message-ID: <1344525954.67.0.87811729273.issue11643@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 17:25:57 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Aug 2012 15:25:57 +0000 Subject: [issue15604] PyObject_IsTrue failure checks In-Reply-To: <1344525855.66.0.08938802791.issue15604@psf.upfronthosting.co.za> Message-ID: <1344525957.6.0.289048328998.issue15604@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file26744/istrue_check-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 17:32:23 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 09 Aug 2012 15:32:23 +0000 Subject: [issue15561] update subprocess docs to reference io.TextIOWrapper In-Reply-To: <1344196317.87.0.366111796882.issue15561@psf.upfronthosting.co.za> Message-ID: <1344526343.04.0.144376466148.issue15561@psf.upfronthosting.co.za> Chris Jerdonek added the comment: In the process of working on issue 15595, I noticed that the documentation change will need to be slightly different for Python 3.2 than for 3.3. In 3.2, it is locale.getpreferredencoding() (which defaults to do_setlocale=True) instead of locale.getpreferredencoding(False). I will provide a patch adjusted for 3.2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 17:35:48 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 09 Aug 2012 15:35:48 +0000 Subject: [issue15561] update subprocess docs to reference io.TextIOWrapper In-Reply-To: <1344196317.87.0.366111796882.issue15561@psf.upfronthosting.co.za> Message-ID: <1344526548.18.0.381969790049.issue15561@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Please do. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 18:40:23 2012 From: report at bugs.python.org (pmoody) Date: Thu, 09 Aug 2012 16:40:23 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <1344530423.88.0.849970228932.issue14814@psf.upfronthosting.co.za> pmoody added the comment: There's no reason why IPv?Network().with_prefixlen can't return str(self). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 19:02:52 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 09 Aug 2012 17:02:52 +0000 Subject: [issue15603] Multiprocessing creates incorrect pids In-Reply-To: <1344524599.55.0.473734451095.issue15603@psf.upfronthosting.co.za> Message-ID: <1344531772.69.0.342514692.issue15603@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Your report is rather ambiguous. Do you claim that said pids don't exist, or that they don't appear in "top"? Also, do you manage to reproduce without R, or do you need to use R to reproduce? I would suspect an issue (or a misunderstanding on your part) with the R-Python bindings, rather than a bug in multiprocessing. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 19:04:18 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 09 Aug 2012 17:04:18 +0000 Subject: [issue15604] PyObject_IsTrue failure checks In-Reply-To: <1344525855.66.0.08938802791.issue15604@psf.upfronthosting.co.za> Message-ID: <1344531858.02.0.637993525993.issue15604@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Is it possible to add test cases for (at least some of) these issues? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 19:07:00 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 09 Aug 2012 17:07:00 +0000 Subject: [issue15599] test_circular_imports() of test_threaded_import fails on FreeBSD 9.0 In-Reply-To: <1344473974.14.0.584788696764.issue15599@psf.upfronthosting.co.za> Message-ID: <1344532020.09.0.819478176894.issue15599@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > The buildbot is running inside kvm on a heavily loaded machine. Perhaps > some timeout is too low. Could you try to run the tests manually after having upped said timeouts? (look for "sleep" in the test file) ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 19:10:28 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 09 Aug 2012 17:10:28 +0000 Subject: [issue15596] pickle: Faster serialization of Unicode strings In-Reply-To: <1344465522.38.0.375715302831.issue15596@psf.upfronthosting.co.za> Message-ID: <1344532228.54.0.720522458026.issue15596@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Looks interesting. Can you post benchmark numbers? (you can use the pickle tests from http://hg.python.org/benchmarks ) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 19:14:39 2012 From: report at bugs.python.org (Chris) Date: Thu, 09 Aug 2012 17:14:39 +0000 Subject: [issue15603] Multiprocessing creates incorrect pids In-Reply-To: <1344524599.55.0.473734451095.issue15603@psf.upfronthosting.co.za> Message-ID: <1344532479.32.0.804821606469.issue15603@psf.upfronthosting.co.za> Chris added the comment: That they don't appear in top. I was using that as a proxy for existence. I wrote a test case without R and realized (accidentally) that tracebacks will now flow up to the main process from the worker processes (which makes perfect sense, actually). I added explicit try/except to __get_valid_triplets. Will report back. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 19:24:27 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 09 Aug 2012 17:24:27 +0000 Subject: [issue15603] Multiprocessing creates incorrect pids In-Reply-To: <1344532479.32.0.804821606469.issue15603@psf.upfronthosting.co.za> Message-ID: <5023F146.6090102@free.fr> Antoine Pitrou added the comment: > Chris added the comment: > > That they don't appear in top. I was using that as a proxy for existence. Well, I don't know in which way you use "top", but by default it will only show you the N most CPU-consuming processes. If the R bindings, for example (here begins the wild speculation on my part :-)), fork in the background so as to run the R engine in a separate process, the CPU-consuming processes would not be those directly created by multiprocessing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 19:32:47 2012 From: report at bugs.python.org (Chris) Date: Thu, 09 Aug 2012 17:32:47 +0000 Subject: [issue15603] Multiprocessing creates incorrect pids In-Reply-To: <1344524599.55.0.473734451095.issue15603@psf.upfronthosting.co.za> Message-ID: <1344533567.01.0.976865439594.issue15603@psf.upfronthosting.co.za> Chris added the comment: Using top/'ps aux' is not the issue. I have code running now with the try/except. Will report back ASAP. I suspect that you're correct about something in the R pipeline failing. Hopefully, I'll get a good traceback. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 19:36:09 2012 From: report at bugs.python.org (Daniel Ellis) Date: Thu, 09 Aug 2012 17:36:09 +0000 Subject: [issue15605] Explain sphinx documentation building in devguide Message-ID: <1344533769.31.0.609415214451.issue15605@psf.upfronthosting.co.za> New submission from Daniel Ellis: At the bottom of this page: http://docs.python.org/devguide/documenting.html There is a command explaining how to build the documentation without using make: python tools/sphinx-build.py -b . build/ It is unclear as to which directory the "tools" is referring to. In the "Tools" directory of the main branch, there is no sphinx-build.py file. On my system, I was able to do the build using sphinx-build as a bare command: sphinx-build -b . build/ I am not sure if this is system specific, but for someone building the documentation for the first time (as I was), this could be confusing. Perhaps someone could explain whether the command that is currently written is obsolete or just differs by system. ---------- components: Devguide messages: 167800 nosy: Daniel.Ellis, eric.araujo, ezio.melotti, ncoghlan priority: normal severity: normal status: open title: Explain sphinx documentation building in devguide _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 19:37:50 2012 From: report at bugs.python.org (Chris) Date: Thu, 09 Aug 2012 17:37:50 +0000 Subject: [issue15603] Multiprocessing creates incorrect pids In-Reply-To: <1344524599.55.0.473734451095.issue15603@psf.upfronthosting.co.za> Message-ID: <1344533870.28.0.0940068279025.issue15603@psf.upfronthosting.co.za> Chris added the comment: Also, when I said "...that tracebacks will now flow up to the main process from the worker processes (which makes perfect sense, actually)", I meant to say "...that tracebacks will NOT flow up to the main process from the worker processes (which makes perfect sense, actually)" ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 19:42:27 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 09 Aug 2012 17:42:27 +0000 Subject: [issue15578] Crash when modifying sys.modules during import In-Reply-To: <1344372630.36.0.657008264392.issue15578@psf.upfronthosting.co.za> Message-ID: <1344534147.93.0.905069190772.issue15578@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- versions: -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 19:42:44 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Aug 2012 17:42:44 +0000 Subject: [issue15605] Explain sphinx documentation building in devguide In-Reply-To: <1344533769.31.0.609415214451.issue15605@psf.upfronthosting.co.za> Message-ID: <1344534164.66.0.165749530887.issue15605@psf.upfronthosting.co.za> R. David Murray added the comment: It refers to the 'tools' subdirectory in the Doc directory, but that doesn't exist unless you've built the docs with 'make' before, or done a 'make checkout'. Presumably you have sphinx installed on your system separately, and that's why you were able to run the command without having done the checkout. This will most work fine I think, though occasionally differences between the system sphinx version and the version the checkout is using will cause issues. Yes, the devguide should be updated to explain how one gets a 'tools' directory. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 19:50:17 2012 From: report at bugs.python.org (Steven Collins) Date: Thu, 09 Aug 2012 17:50:17 +0000 Subject: [issue15606] re.VERBOSE doesn't ignore certain whitespace Message-ID: <1344534617.67.0.49137100671.issue15606@psf.upfronthosting.co.za> New submission from Steven Collins: Given the way the documentation is written for re.VERBOSE - "Whitespace within the pattern is ignored, except when in a character class or preceded by an unescaped backslash" - I would expect all three of the findall() commands below to return successfully with the same result: Python 3.2.3 (default, Jun 8 2012, 05:37:15) [GCC 4.7.0 20120507 (Red Hat 4.7.0-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import re >>> re.findall('(?x) (?: a | b ) + ', 'abaabc') ['abaab'] >>> re.findall('(?x) (? : a | b ) + ', 'abaabc') Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.2/re.py", line 193, in findall return _compile(pattern, flags).findall(string) File "/usr/lib/python3.2/re.py", line 255, in _compile return _compile_typed(type(pattern), pattern, flags) File "/usr/lib/python3.2/functools.py", line 184, in wrapper result = user_function(*args, **kwds) File "/usr/lib/python3.2/re.py", line 267, in _compile_typed return sre_compile.compile(pattern, flags) File "/usr/lib/python3.2/sre_compile.py", line 491, in compile p = sre_parse.parse(p, flags) File "/usr/lib/python3.2/sre_parse.py", line 692, in parse p = _parse_sub(source, pattern, 0) File "/usr/lib/python3.2/sre_parse.py", line 315, in _parse_sub itemsappend(_parse(source, state)) File "/usr/lib/python3.2/sre_parse.py", line 627, in _parse raise error("unexpected end of pattern") sre_constants.error: unexpected end of pattern >>> re.findall('(?x) ( ?: a | b ) + ', 'abaabc') Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.2/re.py", line 193, in findall return _compile(pattern, flags).findall(string) File "/usr/lib/python3.2/re.py", line 255, in _compile return _compile_typed(type(pattern), pattern, flags) File "/usr/lib/python3.2/functools.py", line 184, in wrapper result = user_function(*args, **kwds) File "/usr/lib/python3.2/re.py", line 267, in _compile_typed return sre_compile.compile(pattern, flags) File "/usr/lib/python3.2/sre_compile.py", line 491, in compile p = sre_parse.parse(p, flags) File "/usr/lib/python3.2/sre_parse.py", line 692, in parse p = _parse_sub(source, pattern, 0) File "/usr/lib/python3.2/sre_parse.py", line 315, in _parse_sub itemsappend(_parse(source, state)) File "/usr/lib/python3.2/sre_parse.py", line 640, in _parse p = _parse_sub(source, state) File "/usr/lib/python3.2/sre_parse.py", line 315, in _parse_sub itemsappend(_parse(source, state)) File "/usr/lib/python3.2/sre_parse.py", line 520, in _parse raise error("nothing to repeat") sre_constants.error: nothing to repeat >>> The behavior is the same in Python 2.7. Apparently the scan for the special '(?' character sequences happens before the whitespace is stripped out. In my opinion, the behavior should be changed, the documentation should be more clear about the current behavior, or at least the errors given should be more informative (I spent an hour or two debugging the "nothing to repeat" error in my work yesterday.) Thank you. ---------- components: Regular Expressions messages: 167803 nosy: ezio.melotti, mrabarnett, stevencollins priority: normal severity: normal status: open title: re.VERBOSE doesn't ignore certain whitespace type: behavior versions: Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 19:55:11 2012 From: report at bugs.python.org (Eli Bendersky) Date: Thu, 09 Aug 2012 17:55:11 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <1344534911.76.0.713924112739.issue14814@psf.upfronthosting.co.za> Eli Bendersky added the comment: pmoody - you mean IPv?Interface, right? The network classes consistently return strings in with_* methods ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 19:57:13 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 09 Aug 2012 17:57:13 +0000 Subject: [issue15589] Bus error on Debian sparc In-Reply-To: <1344417411.0.0.396332340112.issue15589@psf.upfronthosting.co.za> Message-ID: <1344535033.43.0.100415801647.issue15589@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I'd like to urge everybody to focus at one issue at a time. This issue is about Python crashing on a SparcLinux qemu image, so I think it should have priority "low" - there is absolutely no requirement that this needs to work. As for the test failures on Solaris - please report them as separate issues (one per failure, "normal" priority seems right). ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 20:08:55 2012 From: report at bugs.python.org (pmoody) Date: Thu, 09 Aug 2012 18:08:55 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <1344535735.75.0.58345455109.issue14814@psf.upfronthosting.co.za> pmoody added the comment: sorry, yes, I meant the interface classes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 20:29:03 2012 From: report at bugs.python.org (Daniel Ellis) Date: Thu, 09 Aug 2012 18:29:03 +0000 Subject: [issue15605] Explain sphinx documentation building in devguide In-Reply-To: <1344533769.31.0.609415214451.issue15605@psf.upfronthosting.co.za> Message-ID: <1344536943.55.0.513793467448.issue15605@psf.upfronthosting.co.za> Daniel Ellis added the comment: That makes sense. I've added a brief explanation noting that the user should be in the "Docs" directory to run the command. When trying to update the dev guide, I noticed that this same "tools" directory does not exist in the repo, so I also added instructions for using the command as mentioned above. For concision's sake, would it be good to remove the reference to the "tools/sphinx-build.py" file altogether? ---------- keywords: +patch Added file: http://bugs.python.org/file26745/devguide_sphinx_fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 20:35:43 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 09 Aug 2012 18:35:43 +0000 Subject: [issue15527] Double parens in functions references In-Reply-To: <1343833557.96.0.948912415493.issue15527@psf.upfronthosting.co.za> Message-ID: <1344537343.47.0.041636432563.issue15527@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Fixed. Sorry, I forgot to mention issue number in commit messages. So it's 9c99f31a9c2a 96cc3ab243e5 and 1e8f6d8e5c0e commits. Thanks for report. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 20:40:15 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Aug 2012 18:40:15 +0000 Subject: [issue15607] New print's argument "flush" is not mentioned in docstring Message-ID: <1344537615.2.0.181912402642.issue15607@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: New print's argument "flush" is not mentioned in docstring. ---------- assignee: docs at python components: Documentation keywords: easy messages: 167809 nosy: docs at python, storchaka priority: normal severity: normal stage: needs patch status: open title: New print's argument "flush" is not mentioned in docstring versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 20:51:02 2012 From: report at bugs.python.org (Georg Brandl) Date: Thu, 09 Aug 2012 18:51:02 +0000 Subject: [issue15527] Double parens in functions references In-Reply-To: <1343833557.96.0.948912415493.issue15527@psf.upfronthosting.co.za> Message-ID: <1344538262.15.0.0510768769297.issue15527@psf.upfronthosting.co.za> Georg Brandl added the comment: These commit hashes don't seem to match this issue. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 20:51:41 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 Aug 2012 18:51:41 +0000 Subject: [issue15601] tkinter test_variables fails with OS X Aqua Tk 8.4 In-Reply-To: <1344486833.0.0.731183249876.issue15601@psf.upfronthosting.co.za> Message-ID: <3WtJTm1v13zPrL@mail.python.org> Roundup Robot added the comment: New changeset 20a46c73855f by Andrew Svetlov in branch 'default': Issue #15601: fix tkinter test_variables failure with OS X Aqua Tk 8.4 http://hg.python.org/cpython/rev/20a46c73855f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 20:52:31 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 09 Aug 2012 18:52:31 +0000 Subject: [issue15601] tkinter test_variables fails with OS X Aqua Tk 8.4 In-Reply-To: <1344486833.0.0.731183249876.issue15601@psf.upfronthosting.co.za> Message-ID: <1344538351.63.0.466112233207.issue15601@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Agree with Martin. Fixed. Thanks. ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 20:53:13 2012 From: report at bugs.python.org (Daniel Ellis) Date: Thu, 09 Aug 2012 18:53:13 +0000 Subject: [issue15607] New print's argument "flush" is not mentioned in docstring In-Reply-To: <1344537615.2.0.181912402642.issue15607@psf.upfronthosting.co.za> Message-ID: <1344538393.81.0.776008847341.issue15607@psf.upfronthosting.co.za> Daniel Ellis added the comment: I've updated the docstring. This is my first time editing a C module, so please let me know if I've done something egregiously wrong. ---------- keywords: +patch nosy: +Daniel.Ellis Added file: http://bugs.python.org/file26746/print_doc_add_flush.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 20:54:03 2012 From: report at bugs.python.org (Stefan Krah) Date: Thu, 09 Aug 2012 18:54:03 +0000 Subject: [issue15599] test_circular_imports() of test_threaded_import fails on FreeBSD 9.0 In-Reply-To: <1344532020.09.0.819478176894.issue15599@psf.upfronthosting.co.za> Message-ID: <20120809185403.GA11634@sleipnir.bytereef.org> Stefan Krah added the comment: Antoine Pitrou wrote: > Could you try to run the tests manually after having upped said timeouts? (look for "sleep" in the test file) No luck there: The tests pass unmodified (100 times with the -F option). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 20:56:16 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 09 Aug 2012 18:56:16 +0000 Subject: [issue15527] Double parens in functions references In-Reply-To: <1343833557.96.0.948912415493.issue15527@psf.upfronthosting.co.za> Message-ID: <1344538576.29.0.946498087252.issue15527@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Sorry, Georg. A'm apologizing. Actual commit numbers are: 6dab233a115e a979b005a814 4787b9b2f860 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 20:56:20 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 09 Aug 2012 18:56:20 +0000 Subject: [issue15605] Explain sphinx documentation building in devguide In-Reply-To: <1344533769.31.0.609415214451.issue15605@psf.upfronthosting.co.za> Message-ID: <1344538580.14.0.212507532685.issue15605@psf.upfronthosting.co.za> Chris Jerdonek added the comment: +If you are building the developer's guide, or for some other reason can not use +the `tools/sphinx-build.py` file, you can also run the following command from +the directory containing `conf.py` :: + + sphinx-build -b . build/ Note that the build instructions for the Developer's Guide live at a separate location at the bottom of this page: http://docs.python.org/devguide/docquality.html#helping-with-the-developer-s-guide Also, IIRC the build directory for the Developer's Guide is "_build" rather than "build" as it is for the main Python documentation. Lastly, a couple nits: "Developer's Guide" should be capitalized and "can not" should be one word. ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 21:02:41 2012 From: report at bugs.python.org (Georg Brandl) Date: Thu, 09 Aug 2012 19:02:41 +0000 Subject: [issue15527] Double parens in functions references In-Reply-To: <1343833557.96.0.948912415493.issue15527@psf.upfronthosting.co.za> Message-ID: <1344538961.76.0.227251990196.issue15527@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 21:05:40 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 09 Aug 2012 19:05:40 +0000 Subject: [issue15527] Double parens in functions references In-Reply-To: <1343833557.96.0.948912415493.issue15527@psf.upfronthosting.co.za> Message-ID: <1344539140.29.0.601620259813.issue15527@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Thank you for reviewing every minor update. It's a big deal and heavy work! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 21:08:30 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 09 Aug 2012 19:08:30 +0000 Subject: [issue5819] Add PYTHONPREFIXES environment variable In-Reply-To: <1240475142.53.0.423262271042.issue5819@psf.upfronthosting.co.za> Message-ID: <1344539310.12.0.596221377747.issue5819@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Close issue as superseded by venv package. ---------- resolution: -> out of date stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 21:11:18 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 09 Aug 2012 19:11:18 +0000 Subject: [issue15555] Default newlines of io.TextIOWrapper In-Reply-To: <1344095998.81.0.573935781933.issue15555@psf.upfronthosting.co.za> Message-ID: <1344539478.2.0.877567820443.issue15555@psf.upfronthosting.co.za> Chris Jerdonek added the comment: What is the change to the documentation being suggested here? The code does reference os.linesep, so it seems like the documentation is correct, or am I missing something? self._writetranslate = newline != '' self._writenl = newline or os.linesep self._encoder = None http://hg.python.org/cpython/file/20a46c73855f/Lib/_pyio.py#l1501 ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 21:22:21 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Aug 2012 19:22:21 +0000 Subject: [issue15555] Default newlines of io.TextIOWrapper In-Reply-To: <1344095998.81.0.573935781933.issue15555@psf.upfronthosting.co.za> Message-ID: <1344540141.81.0.0422018084178.issue15555@psf.upfronthosting.co.za> R. David Murray added the comment: I don't think the C version does, though. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 21:34:19 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Aug 2012 19:34:19 +0000 Subject: [issue15527] Double parens in functions references In-Reply-To: <1343833557.96.0.948912415493.issue15527@psf.upfronthosting.co.za> Message-ID: <1344540859.33.0.931473927251.issue15527@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Hmm, I'm hoping that will be fixed by fixing of some markup words (:c:func:, :func:, :meth:, etc) processing, and not that they will simply be removed. :c:func: works only for function name without parameters or for function name with empty list of parameters inside the parentheses (:c:func:`PyMem_Malloc`, :c:func:`PyMem_Malloc()`, but not :c:func:`PyMem_Malloc(1)`). :c:macro: works also for non-empty list (:c:macro:`Py_CLEAR(obj)` for example). And Doc/c-api/memory.rst is not only one issue file. The list of suspicious places you can get by the followed command: find Doc/ -type f -name '*.rst' -exec egrep -n --color ':`\w+[(][^)]' '{}' + ---------- resolution: fixed -> stage: committed/rejected -> needs patch status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 21:37:19 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 09 Aug 2012 19:37:19 +0000 Subject: [issue15561] update subprocess docs to reference io.TextIOWrapper In-Reply-To: <1344196317.87.0.366111796882.issue15561@psf.upfronthosting.co.za> Message-ID: <1344541039.7.0.94160585165.issue15561@psf.upfronthosting.co.za> Changes by Chris Jerdonek : Added file: http://bugs.python.org/file26747/issue-15561-2-branch-32.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 21:38:44 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 09 Aug 2012 19:38:44 +0000 Subject: [issue15561] update subprocess docs to reference io.TextIOWrapper In-Reply-To: <1344196317.87.0.366111796882.issue15561@psf.upfronthosting.co.za> Message-ID: <1344541124.26.0.676070640068.issue15561@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I have uploaded updated patches for both 3.2 and the default branch. Thanks, Andrew. ---------- Added file: http://bugs.python.org/file26748/issue-15561-2-branch-default.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 21:42:40 2012 From: report at bugs.python.org (Georg Brandl) Date: Thu, 09 Aug 2012 19:42:40 +0000 Subject: [issue15527] Double parens in functions references In-Reply-To: <1343833557.96.0.948912415493.issue15527@psf.upfronthosting.co.za> Message-ID: <1344541360.91.0.652347212955.issue15527@psf.upfronthosting.co.za> Georg Brandl added the comment: The markup you mentioned will not be changed: these are two different usecases. Either you link to the function itself (:func:`blah`), or you show a piece of code (``blah(n)``). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 21:44:26 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 09 Aug 2012 19:44:26 +0000 Subject: [issue15608] Improve socketserver doc Message-ID: <1344541466.79.0.410789330017.issue15608@psf.upfronthosting.co.za> New submission from Terry J. Reedy: On Windows, 3.3 socketserver defines 12 classes in 3 categories: servers, server mixins, and handlers. (At least, these are the one listed with dir(socketserver). Only BaseServer is indexed. I think all should be. There are also a couple of text issues. BaseServer - indexed, doc is 20.19.2. Server Objects TCPServer - mentioned in diagram and text of 20.19.1 UDPServer - ditto (I presume *nix version have unixxxx classes also) ForkingMixIn - text of 20.19.1 ThreadingMixIn - ditto ForkingTCPServer ForkingUDPServer ThreadingTCPServer ThreadingUDPServer Text says "Forking and threading versions of each type of server can be created using the ForkingMixIn and ThreadingMixIn mix-in classes. For instance, a threading UDP server class is created as follows: class ThreadingUDPServer(ThreadingMixIn, UDPServer): pass The mix-in class must come first, since it overrides a method defined in UDPServer." "can be" means to me that user must create these. I am guessing that pre-defining them was added later. So text should change to 'have been'. The pre-created combinations should be listed. The last sentence could then say "Thhe mix-in class comes first since it overrides...". --- BaseRequestHandler This is documented in 20.19.2 RequestHandler Objects. But instead of starting with something like class socketserver.BaseRequestHandler This is the superclass of all RequestHandler objects. It defines the interface, given below, but does not implement most of the methods, which is done in subclasses. A new instance of the subclass is created for each request. analogous to the initial entry in 20.19.1, 20.19.2 starts with "The request handler class must define a new handle() method, and can override any of the following methods. A new instance is created for each request. I suggest that this be replaced with a standard class entry like the one above. If done, I resume the "RequestHandler" method prefix should be "BaseRequestHandler". StreamRequestHandler - these two are described in a paragraph DatagramRequestHandler - after the handle method entry --- In summary: 1. index all classes to point to locations indicated above. 2. state that mixin combinations are pre-defined. 3. give BaseRequestHandler a proper entry. 4. revise above as needed for *nix. 5. optionally adjust as needed for 2.7. ---------- assignee: docs at python components: Documentation messages: 167825 nosy: docs at python, terry.reedy priority: normal severity: normal status: open title: Improve socketserver doc versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 21:52:37 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 09 Aug 2012 19:52:37 +0000 Subject: [issue15527] Double parens in functions references In-Reply-To: <1343833557.96.0.948912415493.issue15527@psf.upfronthosting.co.za> Message-ID: <1344541957.18.0.324979517511.issue15527@psf.upfronthosting.co.za> Andrew Svetlov added the comment: >From my perspective sphinx doesn't allow notations like :c:func:`PyMem_Malloc(1)` Do you want to publish bugfix for sphinx? Sounds like good idea, but that fix is out my current competence. I just fixed weird stuff which you pointed out. If you want to do more ? you are welcome. Please push a patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 22:01:47 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Aug 2012 20:01:47 +0000 Subject: [issue15609] Format string: add more fast-path Message-ID: <1344542506.78.0.404794794491.issue15609@psf.upfronthosting.co.za> New submission from STINNER Victor: Attached patch adds tests to check that str%args and str.format(args) take all optimization opportunities for simple format strings. It takes also the fast-path when Unicode string argument when width and/or precision is set. For example, "%.3s" % "abc" now returns "abc" unmodified (instead of creating a copy). The patch also takes the fast-path when formatting integers with str%args when the argument is not an int, but an object with __int__ method. ---------- files: optimize_format.patch keywords: patch messages: 167827 nosy: haypo, pitrou priority: normal severity: normal status: open title: Format string: add more fast-path type: performance versions: Python 3.4 Added file: http://bugs.python.org/file26749/optimize_format.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 22:04:09 2012 From: report at bugs.python.org (Dave Malcolm) Date: Thu, 09 Aug 2012 20:04:09 +0000 Subject: [issue15610] PyImport_ImportModuleEx always fails in 3.3 with "ValueError: level must be >= 0" Message-ID: <1344542648.98.0.69001231241.issue15610@psf.upfronthosting.co.za> New submission from Dave Malcolm: I've been testing various 3rd-party python code against 3.3b1, and see ValueError: level must be >= 0 exceptions where C code is using PyImport_ImportModuleEx. PyImport_ImportModuleEx reads as 63 #define PyImport_ImportModuleEx(n, g, l, f) \ 64 PyImport_ImportModuleLevel(n, g, l, f, -1) within http://hg.python.org/cpython/file/aaa68dce117e/Include/import.h as of now (2012-08-09) Within PyImport_ImportModuleLevel there's this check: 1280 if (level < 0) { 1281 PyErr_SetString(PyExc_ValueError, "level must be >= 0"); 1282 goto error; 1283 } which thus always fires. So it would seem that currently any usage of PyImport_ImportModuleEx will fail. ---------- components: Interpreter Core messages: 167828 nosy: dmalcolm priority: normal severity: normal status: open title: PyImport_ImportModuleEx always fails in 3.3 with "ValueError: level must be >= 0" type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 22:15:15 2012 From: report at bugs.python.org (Dave Malcolm) Date: Thu, 09 Aug 2012 20:15:15 +0000 Subject: [issue15610] PyImport_ImportModuleEx always fails in 3.3 with "ValueError: level must be >= 0" In-Reply-To: <1344542648.98.0.69001231241.issue15610@psf.upfronthosting.co.za> Message-ID: <1344543315.39.0.351140850189.issue15610@psf.upfronthosting.co.za> Dave Malcolm added the comment: (FWIW, this was observed when compiling pygobject-3.3.4 against Python-3.3.0b1) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 22:20:37 2012 From: report at bugs.python.org (Chris) Date: Thu, 09 Aug 2012 20:20:37 +0000 Subject: [issue15603] Multiprocessing creates incorrect pids In-Reply-To: <1344524599.55.0.473734451095.issue15603@psf.upfronthosting.co.za> Message-ID: <1344543637.27.0.923393231448.issue15603@psf.upfronthosting.co.za> Chris added the comment: Ugh, a server reboot seems to have cleared this all up (FML). It's been running well past the point of previous failure. I suppose I'll never know why it was failing. I'm going to close this out. Thanks for your time in helping me think this through. ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 22:42:50 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Aug 2012 20:42:50 +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: <1344544970.59.0.677493089722.issue15216@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, set_encoding.patch is wrong: + offset = self._decoded_chars_used - len(next_input) self._decoded_chars_used is a number of Unicode characters, len(next_input) is a number of bytes. It only works with 7 and 8 bit encodings like ascii or latin1, but not with multibyte encodings like utf8 or ucs-4. > peeking into the underlying buffer would be enough to > handle encoding detection. I wrote a new patch using this idea. It does not work (yet?) with non seekable streams. The raw read buffer (bytes string) is not stored in the _snapshot attribute if the stream is not seeakble. It may be changed to solve this issue. set_encoding-2.patch is still a work-in-progress. It does not patch the _io module for example. ---------- Added file: http://bugs.python.org/file26750/set_encoding-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 22:46:43 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Aug 2012 20:46:43 +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: <1344545203.11.0.1551159181.issue15216@psf.upfronthosting.co.za> STINNER Victor added the comment: Note: it is not possible to reencode the buffer of decoded characters to compute the offset in bytes. Some codecs are not bijective. Examples: * b'\x00'.decode('utf7').encode('utf7') == b'+AAA-' * b'\xff'.decode('ascii', 'replace').encode('ascii', 'replace') == b'?' * b'\xff'.decode('ascii', 'ignore').encode('ascii', 'ignore') == b'' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 22:53:10 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Aug 2012 20:53:10 +0000 Subject: [issue15610] PyImport_ImportModuleEx always fails in 3.3 with "ValueError: level must be >= 0" In-Reply-To: <1344542648.98.0.69001231241.issue15610@psf.upfronthosting.co.za> Message-ID: <1344545590.42.0.358255092053.issue15610@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 22:54:22 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Aug 2012 20:54:22 +0000 Subject: [issue15610] PyImport_ImportModuleEx always fails in 3.3 with "ValueError: level must be >= 0" In-Reply-To: <1344542648.98.0.69001231241.issue15610@psf.upfronthosting.co.za> Message-ID: <1344545662.41.0.685263360086.issue15610@psf.upfronthosting.co.za> STINNER Victor added the comment: Can you please try my amazing patch? ---------- keywords: +patch nosy: +haypo Added file: http://bugs.python.org/file26751/amazing_patch.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 23:04:17 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Aug 2012 21:04:17 +0000 Subject: [issue15610] PyImport_ImportModuleEx always fails in 3.3 with "ValueError: level must be >= 0" In-Reply-To: <1344542648.98.0.69001231241.issue15610@psf.upfronthosting.co.za> Message-ID: <1344546257.44.0.487087180764.issue15610@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, I didn't realize that the documentation says that the default value is -1. http://docs.python.org/library/functions.html#__import__ "level specifies whether to use absolute or relative imports. The default is -1 which indicates both absolute and relative imports will be attempted. 0 means only perform absolute imports. Positive values for level indicate the number of parent directories to search relative to the directory of the module calling __import__()." We should probably tolerate -1, or just drop the exception. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 23:07:09 2012 From: report at bugs.python.org (Dave Malcolm) Date: Thu, 09 Aug 2012 21:07:09 +0000 Subject: [issue15610] PyImport_ImportModuleEx always fails in 3.3 with "ValueError: level must be >= 0" In-Reply-To: <1344546257.44.0.487087180764.issue15610@psf.upfronthosting.co.za> Message-ID: <1344546393.25885.22.camel@surprise> Dave Malcolm added the comment: On Thu, 2012-08-09 at 21:04 +0000, STINNER Victor wrote: > STINNER Victor added the comment: > > Oh, I didn't realize that the documentation says that the default value is -1. > http://docs.python.org/library/functions.html#__import__ > > "level specifies whether to use absolute or relative imports. The default is -1 which indicates both absolute and relative imports will be attempted. 0 means only perform absolute imports. Positive values for level indicate the number of parent directories to search relative to the directory of the module calling __import__()." That's the python 2 documentation The 3.3 docs here: http://docs.python.org/dev/library/functions.html#__import__ say "Changed in version 3.3: Negative values for level are no longer supported (which also changes the default value to 0)." > We should probably tolerate -1, or just drop the exception. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 23:14:55 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 09 Aug 2012 21:14:55 +0000 Subject: [issue15611] devguide: add "core mentors" area to Experts Index Message-ID: <1344546895.77.0.0864519810759.issue15611@psf.upfronthosting.co.za> New submission from Chris Jerdonek: On the core-mentorship list, Nick Coghlan suggested adding an "area" to the Experts Index for core developers who are on the core-mentorship list (or at least those who wish to be listed). This issue is to do that. This can be done by adding a row to the Miscellaneous section with Interest Area "core mentors" or "core mentorship". http://docs.python.org/devguide/experts.html#miscellaneous ---------- components: Devguide messages: 167836 nosy: cjerdonek, eric.araujo, ezio.melotti, ncoghlan priority: normal severity: normal stage: needs patch status: open title: devguide: add "core mentors" area to Experts Index type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 23:35:34 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 09 Aug 2012 21:35:34 +0000 Subject: [issue15611] devguide: add "core mentors" area to Experts Index In-Reply-To: <1344546895.77.0.0864519810759.issue15611@psf.upfronthosting.co.za> Message-ID: <1344548134.7.0.850848445373.issue15611@psf.upfronthosting.co.za> Ezio Melotti added the comment: I think you should better define the goal of this new section. How would people use this information? * If it's just to know what developers are on the core-mentorship list, I think it's a bit pointless, especially because not all of them might want to be listed or they might be listed and not following it actively; * If it's to know if someone you see on core-mentorship is a core developer, the full list of developers is a better way to check, since it contains all the names; * If (as Nick's message seems to suggest) the goal is to find people willing to be added to the nosy list of issues about orphaned modules, then the "core mentors" header is a bit misleading because people might be on core-mentorship but they might not want to be added to issues (or vice versa); The last goal makes some amount of sense, but it's somewhat orthogonal with the core-mentorship ML. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 23:47:04 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 09 Aug 2012 21:47:04 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1344548824.94.0.320312666672.issue15573@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Can someone please explain why this is a release blocker? What is the specific regression from 3.2 that this deals with? ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 23:49:42 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Aug 2012 21:49:42 +0000 Subject: [issue15596] pickle: Faster serialization of Unicode strings In-Reply-To: <1344465522.38.0.375715302831.issue15596@psf.upfronthosting.co.za> Message-ID: <1344548982.89.0.222109717042.issue15596@psf.upfronthosting.co.za> STINNER Victor added the comment: Here is a benchmark comparing Python 3.3 without and with my patch ned$ python3 perf.py -b fastpickle,pickle_dict,pickle_list,slowpickle ../default/python ../fasterpickle/python Running fastpickle... INFO:root:Running ../fasterpickle/python performance/bm_pickle.py -n 50 --use_cpickle pickle INFO:root:Running ../default/python performance/bm_pickle.py -n 50 --use_cpickle pickle Running pickle_dict... INFO:root:Running ../fasterpickle/python performance/bm_pickle.py -n 50 --use_cpickle pickle_dict INFO:root:Running ../default/python performance/bm_pickle.py -n 50 --use_cpickle pickle_dict Running pickle_list... INFO:root:Running ../fasterpickle/python performance/bm_pickle.py -n 50 --use_cpickle pickle_list INFO:root:Running ../default/python performance/bm_pickle.py -n 50 --use_cpickle pickle_list Running slowpickle... INFO:root:Running ../fasterpickle/python performance/bm_pickle.py -n 50 pickle INFO:root:Running ../default/python performance/bm_pickle.py -n 50 pickle Report on Linux ned 3.4.4-4.fc16.x86_64 #1 SMP Thu Jul 5 20:01:38 UTC 2012 x86_64 x86_64 Total CPU cores: 8 ### fastpickle ### Min: 0.530622 -> 0.332841: 1.59x faster Avg: 0.539450 -> 0.336833: 1.60x faster Significant (t=232.04) Stddev: 0.00552 -> 0.00276: 2.0032x smaller Timeline: b'http://tinyurl.com/dyu3vap' The following not significant results are hidden, use -v to show them: pickle_dict, pickle_list, slowpickle. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 23:50:20 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 09 Aug 2012 21:50:20 +0000 Subject: [issue15611] devguide: add "core mentors" area to Experts Index In-Reply-To: <1344546895.77.0.0864519810759.issue15611@psf.upfronthosting.co.za> Message-ID: <1344549020.59.0.554474352797.issue15611@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > I think you should better define the goal of this new section. I see your point and may not have fully understood the intent. I'll defer to Nick on this since the initial suggestion was his. I'm not personally wedded to any particular resolution of the issue. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 9 23:59:43 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 09 Aug 2012 21:59:43 +0000 Subject: [issue15610] PyImport_ImportModuleEx always fails in 3.3 with "ValueError: level must be >= 0" In-Reply-To: <1344542648.98.0.69001231241.issue15610@psf.upfronthosting.co.za> Message-ID: <1344549583.1.0.675766347501.issue15610@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Sounds like a rather annoying regression. Changing the macro's expansion would be good enough IMO. ---------- nosy: +georg.brandl, pitrou priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 00:03:38 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Aug 2012 22:03:38 +0000 Subject: [issue15596] pickle: Faster serialization of Unicode strings In-Reply-To: <1344465522.38.0.375715302831.issue15596@psf.upfronthosting.co.za> Message-ID: <1344549818.53.0.700171963452.issue15596@psf.upfronthosting.co.za> STINNER Victor added the comment: For your information, results of benchmark comparing Python 3.2 to 3.3: ned$ python3 perf.py -b fastpickle,pickle_dict,pickle_list,slowpickle ../3.2/python ../default/python Running fastpickle... INFO:root:Running ../default/python performance/bm_pickle.py -n 50 --use_cpickle pickle INFO:root:Running ../3.2/python performance/bm_pickle.py -n 50 --use_cpickle pickle Running pickle_dict... INFO:root:Running ../default/python performance/bm_pickle.py -n 50 --use_cpickle pickle_dict INFO:root:Running ../3.2/python performance/bm_pickle.py -n 50 --use_cpickle pickle_dict Running pickle_list... INFO:root:Running ../default/python performance/bm_pickle.py -n 50 --use_cpickle pickle_list INFO:root:Running ../3.2/python performance/bm_pickle.py -n 50 --use_cpickle pickle_list Running slowpickle... INFO:root:Running ../default/python performance/bm_pickle.py -n 50 pickle INFO:root:Running ../3.2/python performance/bm_pickle.py -n 50 pickle Report on Linux ned 3.4.4-4.fc16.x86_64 #1 SMP Thu Jul 5 20:01:38 UTC 2012 x86_64 x86_64 Total CPU cores: 8 ### fastpickle ### Min: 0.455842 -> 0.542103: 1.19x slower Avg: 0.462334 -> 0.547271: 1.18x slower Significant (t=-101.15) Stddev: 0.00362 -> 0.00471: 1.3028x larger Timeline: b'http://tinyurl.com/btr644x' ### pickle_dict ### Min: 0.360125 -> 0.345850: 1.04x faster Avg: 0.364019 -> 0.348431: 1.04x faster Significant (t=30.84) Stddev: 0.00308 -> 0.00181: 1.6973x smaller Timeline: b'http://tinyurl.com/cd3ashu' ### pickle_list ### Min: 0.803941 -> 0.584800: 1.37x faster Avg: 0.811115 -> 0.589200: 1.38x faster Significant (t=455.00) Stddev: 0.00261 -> 0.00225: 1.1612x smaller Timeline: b'http://tinyurl.com/8u4m2wf' ### slowpickle ### Min: 0.409008 -> 0.461257: 1.13x slower Avg: 0.413668 -> 0.466201: 1.13x slower Significant (t=-115.31) Stddev: 0.00236 -> 0.00219: 1.0772x smaller Timeline: b'http://tinyurl.com/czrg5kf' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 00:04:51 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 09 Aug 2012 22:04:51 +0000 Subject: [issue15608] Improve socketserver doc In-Reply-To: <1344541466.79.0.410789330017.issue15608@psf.upfronthosting.co.za> Message-ID: <1344549891.23.0.892964953014.issue15608@psf.upfronthosting.co.za> Terry J. Reedy added the comment: BaseRequestHandler.__init__(self, request) apparently attaches request to the instance as self.request. The methods are called in this order: setup, handle, finish. If they must be confusingly documented in the opposite order, it would be good for the head entry to state the correct order. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 00:06:00 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Aug 2012 22:06:00 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1344549960.85.0.0142812304209.issue15573@psf.upfronthosting.co.za> STINNER Victor added the comment: > What is the specific regression from 3.2 that this deals with? I don't know if it must be called a regression, but at least the behaviour is different in Python 3.2 and 3.3. For example, an Unicode array is no more equal to its memoryview: Python 3.3.0b1 (default:aaa68dce117e, Aug 9 2012, 22:45:00) [GCC 4.6.3 20120306 (Red Hat 4.6.3-2)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import array >>> a=array.array('u', 'abc') >>> v=memoryview(a) >>> a == v False ned$ python3 Python 3.2.3 (default, Jun 8 2012, 05:40:07) [GCC 4.6.3 20120306 (Red Hat 4.6.3-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import array >>> a=array.array('u', 'abc') >>> v=memoryview(a) >>> a == v True ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 00:07:10 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 09 Aug 2012 22:07:10 +0000 Subject: [issue15444] Incorrectly written contributor's names In-Reply-To: <1343161512.09.0.0619646494936.issue15444@psf.upfronthosting.co.za> Message-ID: <1344550030.08.0.717288503724.issue15444@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > While working on issue 15437, it occurred to me that storing the names in a structured form might come in handy. In a separate discussion, Ezio pointed out a case where we are already scraping data about members from doc files: http://hg.python.org/tracker/python-dev/file/69984a770ab5/extensions/jnosy.py So there is another case where we would benefit from storing names with associated attributes in a centralized, structured way. Sorry if this is a departure from the topic of this issue. I may create a separate issue for this or raise the idea in another forum. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 00:07:43 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Aug 2012 22:07:43 +0000 Subject: [issue15610] PyImport_ImportModuleEx always fails in 3.3 with "ValueError: level must be >= 0" In-Reply-To: <1344549583.1.0.675766347501.issue15610@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > Sounds like a rather annoying regression. PyImport_ImportModuleLevel() is part of the stable API. Is it an acceptable to not only change the default value but also fail with the previous *default* value? Can't we just drop the check "level < 0"? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 00:08:24 2012 From: report at bugs.python.org (Alexandre Vassalotti) Date: Thu, 09 Aug 2012 22:08:24 +0000 Subject: [issue15596] pickle: Faster serialization of Unicode strings In-Reply-To: <1344465522.38.0.375715302831.issue15596@psf.upfronthosting.co.za> Message-ID: <1344550104.71.0.298318184936.issue15596@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: Amazing! Though, it would probably be good idea to benchmarks non-ASCII strings as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 00:08:26 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Aug 2012 22:08:26 +0000 Subject: [issue15596] pickle: Faster serialization of Unicode strings In-Reply-To: <1344465522.38.0.375715302831.issue15596@psf.upfronthosting.co.za> Message-ID: <1344550106.65.0.414383394759.issue15596@psf.upfronthosting.co.za> STINNER Victor added the comment: Last one: Python 3.2 vs patched Python 3.3. ned$ python3 perf.py -b fastpickle,pickle_dict,pickle_list,slowpickle ../3.2/python ../fasterpickle/python Running fastpickle... INFO:root:Running ../fasterpickle/python performance/bm_pickle.py -n 50 --use_cpickle pickle INFO:root:Running ../3.2/python performance/bm_pickle.py -n 50 --use_cpickle pickle Running pickle_dict... INFO:root:Running ../fasterpickle/python performance/bm_pickle.py -n 50 --use_cpickle pickle_dict INFO:root:Running ../3.2/python performance/bm_pickle.py -n 50 --use_cpickle pickle_dict Running pickle_list... INFO:root:Running ../fasterpickle/python performance/bm_pickle.py -n 50 --use_cpickle pickle_list INFO:root:Running ../3.2/python performance/bm_pickle.py -n 50 --use_cpickle pickle_list Running slowpickle... INFO:root:Running ../fasterpickle/python performance/bm_pickle.py -n 50 pickle INFO:root:Running ../3.2/python performance/bm_pickle.py -n 50 pickle Report on Linux ned 3.4.4-4.fc16.x86_64 #1 SMP Thu Jul 5 20:01:38 UTC 2012 x86_64 x86_64 Total CPU cores: 8 ### fastpickle ### Min: 0.470211 -> 0.322453: 1.46x faster Avg: 0.475718 -> 0.328496: 1.45x faster Significant (t=205.65) Stddev: 0.00317 -> 0.00395: 1.2456x larger Timeline: b'http://tinyurl.com/9qpphzp' ### pickle_dict ### Min: 0.353965 -> 0.347959: 1.02x faster Avg: 0.358980 -> 0.350596: 1.02x faster Significant (t=10.44) Stddev: 0.00545 -> 0.00160: 3.3956x smaller Timeline: b'http://tinyurl.com/9pfeqf9' ### pickle_list ### Min: 0.838222 -> 0.593497: 1.41x faster Avg: 0.844636 -> 0.599491: 1.41x faster Significant (t=296.53) Stddev: 0.00520 -> 0.00267: 1.9521x smaller Timeline: b'http://tinyurl.com/9rynvnv' ### slowpickle ### Min: 0.408205 -> 0.458309: 1.12x slower Avg: 0.413738 -> 0.463916: 1.12x slower Significant (t=-53.85) Stddev: 0.00263 -> 0.00604: 2.3019x larger Timeline: b'http://tinyurl.com/coffkbg' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 00:53:52 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 09 Aug 2012 22:53:52 +0000 Subject: [issue15610] PyImport_ImportModuleEx always fails in 3.3 with "ValueError: level must be >= 0" In-Reply-To: <1344542648.98.0.69001231241.issue15610@psf.upfronthosting.co.za> Message-ID: <1344552832.79.0.0900126028019.issue15610@psf.upfronthosting.co.za> Eric Snow added the comment: > Changing the macro's expansion would be good enough IMO. Sounds good to me. > PyImport_ImportModuleLevel() is part of the stable API... >From what I understand, as long as the function header has not changed, the stable ABI is still stable. > Can't we just drop the check "level < 0"? In Python 3 a negative value makes no sense, since there are no accommodations for implicit relative imports. The fact that builtins.__import__() accommodated -1 still was an oversight that was corrected in 3.3. Looks like this is just one bit that got missed. ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 01:52:19 2012 From: report at bugs.python.org (Atsuo Ishimoto) Date: Thu, 09 Aug 2012 23:52:19 +0000 Subject: [issue12782] Multiple context expressions do not support parentheses for continuation across lines In-Reply-To: <1313719817.79.0.828403712604.issue12782@psf.upfronthosting.co.za> Message-ID: <1344556339.36.0.153469047392.issue12782@psf.upfronthosting.co.za> Changes by Atsuo Ishimoto : ---------- nosy: +ishimoto _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 04:30:31 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Aug 2012 02:30:31 +0000 Subject: [issue15612] Rewriter StringIO to use the _PyUnicodeWriter API Message-ID: <1344565830.56.0.384034899089.issue15612@psf.upfronthosting.co.za> New submission from STINNER Victor: Attached patch rewrites the C implementation of StringIO to use the _PyUnicodeWriter API instead of the PyAccu API. It provides better performance when writing non-ASCII strings. The patch adds new functions: - _PyUnicodeWriter_Truncate() - _PyUnicodeWriter_WriteStrAt() - _PyUnicodeWriter_GetValue() ---------- components: IO, Unicode files: stringio_unicode_writer.patch keywords: patch messages: 167850 nosy: ezio.melotti, haypo, pitrou priority: normal severity: normal status: open title: Rewriter StringIO to use the _PyUnicodeWriter API versions: Python 3.4 Added file: http://bugs.python.org/file26752/stringio_unicode_writer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 04:32:19 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Aug 2012 02:32:19 +0000 Subject: [issue15612] Rewriter StringIO to use the _PyUnicodeWriter API In-Reply-To: <1344565830.56.0.384034899089.issue15612@psf.upfronthosting.co.za> Message-ID: <1344565939.94.0.968437363437.issue15612@psf.upfronthosting.co.za> STINNER Victor added the comment: Results of my micro benchmark. Use attached bench_stringio.py with benchmark.py: https://bitbucket.org/haypo/misc/src/tip/python/benchmark.py Command: ./python benchmark.py script bench_stringio.py ---- Common platform: CPU model: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz Python unicode implementation: PEP 393 Platform: Linux-3.4.4-4.fc16.x86_64-x86_64-with-fedora-16-Verne Bits: int=32, long=64, long long=64, pointer=64 CFLAGS: -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes Platform of campaign pyaccu: Date: 2012-08-10 04:24:53 SCM: hg revision=aaa68dce117e tag=tip branch=default date="2012-08-09 21:38 +0200" Python version: 3.3.0b1 (default:aaa68dce117e, Aug 10 2012, 04:24:19) [GCC 4.6.3 20120306 (Red Hat 4.6.3-2)] Platform of campaign writer: Date: 2012-08-10 04:23:21 SCM: hg revision=aaa68dce117e+ tag=tip branch=default date="2012-08-09 21:38 +0200" Python version: 3.3.0b1 (default:aaa68dce117e+, Aug 10 2012, 04:18:39) [GCC 4.6.3 20120306 (Red Hat 4.6.3-2)] --------------------------------------+-------------+--------------- Tests | pyaccu | writer --------------------------------------+-------------+--------------- writer ascii | 30.4 ms (*) | 30.4 ms writer reader ascii | 37.1 ms (*) | 37 ms writer latin1 | 31.5 ms (*) | 30.6 ms writer reader latin1 | 38.6 ms (*) | 37.4 ms writer bmp | 31.8 ms (*) | 29.7 ms (-7%) writer reader bmp | 40.8 ms (*) | 36.6 ms (-10%) writer non-bmp | 33.4 ms (*) | 30.2 ms (-10%) writer reader non-bmp | 40.9 ms (*) | 36.7 ms (-10%) writer long lines ascii | 7.96 ms (*) | 7.34 ms (-8%) writer-reader long lines ascii | 8.16 ms (*) | 7.39 ms (-9%) writer long lines latin1 | 8.01 ms (*) | 7.4 ms (-8%) writer-reader long lines latin1 | 8.05 ms (*) | 7.4 ms (-8%) writer long lines bmp | 14 ms (*) | 9.42 ms (-33%) writer-reader long lines bmp | 14.2 ms (*) | 9.45 ms (-34%) writer long lines non-bmp | 13.9 ms (*) | 9.62 ms (-31%) writer-reader long lines non-bmp | 14.3 ms (*) | 9.63 ms (-32%) writer very long lines ascii | 7.96 ms (*) | 7.36 ms (-7%) writer-reader very long lines ascii | 8.05 ms (*) | 7.37 ms (-8%) writer very long lines latin1 | 7.98 ms (*) | 7.33 ms (-8%) writer-reader very long lines latin1 | 8 ms (*) | 7.39 ms (-8%) writer very long lines bmp | 14.1 ms (*) | 9.34 ms (-34%) writer-reader very long lines bmp | 14.2 ms (*) | 9.4 ms (-34%) writer very long lines non-bmp | 13.9 ms (*) | 9.5 ms (-32%) writer-reader very long lines non-bmp | 14 ms (*) | 9.61 ms (-31%) reader ascii | 6.48 ms (*) | 6.22 ms reader latin1 | 6.59 ms (*) | 6.57 ms reader bmp | 7.22 ms (*) | 6.9 ms reader non-bmp | 7.65 ms (*) | 7.31 ms --------------------------------------+-------------+--------------- Total | 489 ms (*) | 431 ms (-12%) --------------------------------------+-------------+--------------- ---------- Added file: http://bugs.python.org/file26753/bench_stringio.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 04:33:22 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Aug 2012 02:33:22 +0000 Subject: [issue15612] Rewriter StringIO to use the _PyUnicodeWriter API In-Reply-To: <1344565830.56.0.384034899089.issue15612@psf.upfronthosting.co.za> Message-ID: <1344566002.98.0.79070792614.issue15612@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- type: -> performance _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 04:33:33 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Aug 2012 02:33:33 +0000 Subject: [issue15612] Rewrite StringIO to use the _PyUnicodeWriter API In-Reply-To: <1344565830.56.0.384034899089.issue15612@psf.upfronthosting.co.za> Message-ID: <1344566013.12.0.0351331347235.issue15612@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: Rewriter StringIO to use the _PyUnicodeWriter API -> Rewrite StringIO to use the _PyUnicodeWriter API _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 05:47:38 2012 From: report at bugs.python.org (Eli Bendersky) Date: Fri, 10 Aug 2012 03:47:38 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <1344570458.1.0.966229297962.issue14814@psf.upfronthosting.co.za> Eli Bendersky added the comment: Attaching a new patch that fixes the with_* methods to be more consistent, and the relevant tests too. The doc is now consistent as well. For some reason IPv6Interface.with_netmask also returned the prefixlen representation. The test justified it by quoting RFC3513/2.3 but I did not see anything there that really forces us to do that. Perhaps the with_netmask/with_hostmask representations are nonsensical for v6 and we keep them for v4 compatibility, but in that case let them be compatible! ---------- Added file: http://bugs.python.org/file26754/ipaddr_interface.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 06:05:32 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Aug 2012 04:05:32 +0000 Subject: [issue15567] threading.py contains undefined name in self-test code In-Reply-To: <1344251123.58.0.751879223209.issue15567@psf.upfronthosting.co.za> Message-ID: <3WtXml5DLXzPtR@mail.python.org> Roundup Robot added the comment: New changeset 260f3ad7af4b by Brian Curtin in branch '2.7': Fix #15567. collections.deque wasn't imported http://hg.python.org/cpython/rev/260f3ad7af4b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 06:08:56 2012 From: report at bugs.python.org (Brian Curtin) Date: Fri, 10 Aug 2012 04:08:56 +0000 Subject: [issue15567] threading.py contains undefined name in self-test code In-Reply-To: <1344251123.58.0.751879223209.issue15567@psf.upfronthosting.co.za> Message-ID: <1344571735.94.0.618540862757.issue15567@psf.upfronthosting.co.za> Changes by Brian Curtin : ---------- assignee: -> brian.curtin nosy: +brian.curtin resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 08:06:53 2012 From: report at bugs.python.org (Alex Jurkiewicz) Date: Fri, 10 Aug 2012 06:06:53 +0000 Subject: [issue15613] argparse ArgumentDefaultsHelpFormatter interacts badly with --arg and nargs=+ Message-ID: <1344578813.57.0.70269968542.issue15613@psf.upfronthosting.co.za> New submission from Alex Jurkiewicz: Sample code: #!/usr/bin/env python import argparse print("\n\narg=foo, nargs=+") parser = argparse.ArgumentParser(formatter_class=argparse.ArgumentDefaultsHelpFormatter) parser.add_argument('foo', nargs='+', help='foos', default=['foo1', 'foo2']) parser.print_help() print("\n\narg=foo, nargs=*") parser = argparse.ArgumentParser(formatter_class=argparse.ArgumentDefaultsHelpFormatter) parser.add_argument('foo', nargs='*', help='foos', default=['foo1', 'foo2']) parser.print_help() print("\n\narg=--foo, nargs=+") parser = argparse.ArgumentParser(formatter_class=argparse.ArgumentDefaultsHelpFormatter) parser.add_argument('--foo', nargs='+', help='foos', default=['foo1', 'foo2']) parser.print_help() print("\n\narg=--foo, nargs=*") parser = argparse.ArgumentParser(formatter_class=argparse.ArgumentDefaultsHelpFormatter) parser.add_argument('--foo', nargs='*', help='foos', default=['foo1', 'foo2']) parser.print_help() The first example's help text for 'foo' is missing "(default: ['foo1', 'foo2'])". I tested 2.7.2, 2.7.3, 3.2.3. ---------- components: Library (Lib) messages: 167854 nosy: Alex.Jurkiewicz priority: normal severity: normal status: open title: argparse ArgumentDefaultsHelpFormatter interacts badly with --arg and nargs=+ type: behavior versions: Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 08:29:50 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 10 Aug 2012 06:29:50 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1344580190.66.0.854066587643.issue15573@psf.upfronthosting.co.za> Martin v. L?wis added the comment: haypo: thanks for stating the issue. ISTM that this classifies as an "obscure" bug: you have to use memoryviews, and you need to compare them for equality, and the comparison needs to be "non-trivial", where "trivial" is defined by "both are 1D byte arrays". While this is a bug, I think it still can be fixed in a bug fix release of 3.3, so un-blocking. I also think that as a first step, a specification needs to be drafted defining when exactly a memory view should compare equal with some other object. I can easily provide a specification that makes the current implementation "correct". ---------- priority: release blocker -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 09:48:39 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 10 Aug 2012 07:48:39 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1344584919.64.0.468432828178.issue15573@psf.upfronthosting.co.za> Stefan Krah added the comment: > I can easily provide a specification that makes the current implementation "correct" Yes, the current specification is: memoryview only attempts to compare arrays with known (single character native) formats and returns "not equal" otherwise. The problem is that for backwards compatibility memoryview accepts arrays with arbitrary format strings. In operations like tolist() it's possible to raise NotImplemented, but for equality comparisons that's not possible. Note that in 3.2 memoryview would return "equal" for arrays that simply aren't equal, if those arrays happen to have the same bit pattern. One way to deal with this is to demand a strict canonical form of format strings for PEP-3118, see msg167687. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 10:10:01 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 10 Aug 2012 08:10:01 +0000 Subject: [issue15612] Rewrite StringIO to use the _PyUnicodeWriter API In-Reply-To: <1344565830.56.0.384034899089.issue15612@psf.upfronthosting.co.za> Message-ID: <1344586201.69.0.953899934471.issue15612@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > It provides better performance when writing non-ASCII strings. I would like to know why that is the case. If PyUnicode_Join is not optimal, then perhaps we should better optimize it. Also, you should post benchmarks with tiny strings as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 10:12:09 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 10 Aug 2012 08:12:09 +0000 Subject: [issue15612] Rewrite StringIO to use the _PyUnicodeWriter API In-Reply-To: <1344565830.56.0.384034899089.issue15612@psf.upfronthosting.co.za> Message-ID: <1344586329.14.0.892728812979.issue15612@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Also, you should post benchmarks with tiny strings as well. Oops, sorry, they are already there. Thanks for the numbers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 10:20:17 2012 From: report at bugs.python.org (laki) Date: Fri, 10 Aug 2012 08:20:17 +0000 Subject: [issue15614] print statement not showing valid result Message-ID: <1344586817.32.0.627259473007.issue15614@psf.upfronthosting.co.za> New submission from laki: Python 2.7.3 (default, Apr 10 2012, 23:24:47) [MSC v.1500 64 bit (AMD64)] on win32 >>> a = [1,2] >>> b = [2,3] >>> a.extend(b) >>> a [1, 2, 2, 3] >>> print [1,2].extend([2,3]) None I did not test this in linux. ---------- components: Windows messages: 167859 nosy: laki priority: normal severity: normal status: open title: print statement not showing valid result type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 10:53:28 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 10 Aug 2012 08:53:28 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344584919.64.0.468432828178.issue15573@psf.upfronthosting.co.za> Message-ID: <5024CC08.5090405@v.loewis.de> Martin v. L?wis added the comment: > Note that in 3.2 memoryview would return "equal" for arrays that > simply aren't equal, if those arrays happen to have the same bit > pattern. This is exactly my point. If a "memoryview" has the same "memory" as another, why are they then not rightfully considered equal? IOW, the 3.2 behavior looks fine to me. You apparently have a vision that equality should mean something different for memoryviews - please explicitly state what that view is. A mathematical definition ("two memoryviews A and B are equal iff ...") would be appreciated. > One way to deal with this is to demand a strict canonical form > of format strings for PEP-3118, see msg167687. You are talking about the solution already - I still don't know what the problem is exactly (not that I *need* to understand the problem, but at a minimum, the documentation should state what the intended behavior is - better if people would also agree that the proposed behavior is "reasonable"). For 3.3, I see two approaches: either move backwards to the 3.2 behavior and defer this change to 3.4 - this would make it release-critical indeed. Or move forward to a yet-to-be specified equality operation which as of now may not be implemented correctly, treating any improvement to it as a bug fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 10:58:14 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 10 Aug 2012 08:58:14 +0000 Subject: [issue15614] print statement not showing valid result In-Reply-To: <1344586817.32.0.627259473007.issue15614@psf.upfronthosting.co.za> Message-ID: <1344589094.3.0.980341755863.issue15614@psf.upfronthosting.co.za> Martin v. L?wis added the comment: This is not a bug. extend is a procedure with a side effect: the "self" object (i.e. "a" in your example) is modified. By convention, procedures return None in Python, as opposed to functions, which have no side effect but return a result. This is to avoid code like def combine(a, b): return a.extend(b) a = ... b = ... c = combine(a,b) If extend would return the "self" list, then people may think that they get a fresh, new list, and then wonder why a is modified. IOW: your bug report is actually invalid; the result that print shows is exactly the right result that extend returns. ---------- nosy: +loewis resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 11:53:15 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 10 Aug 2012 09:53:15 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <5024CC08.5090405@v.loewis.de> Message-ID: <20120810095316.GA17449@sleipnir.bytereef.org> Stefan Krah added the comment: PEP-3118 specifies strongly typed multi-dimensional arrays. The existing code in the 3.2 memoryview as well as numerous comments by Travis Oliphant make it clear that these capabilities were intended from the start for memoryview as well. Perhaps the name "memoryview" is a misnomer, since the boundaries between memoryview and NumPy's ndarray become blurry. In fact, the small implementation of an ndarray in Modules/_testbuffer.c is *also* a memoryview in some sense, since it can grab a buffer from an exporter and expose it in the same manner as memoryview. So what I implemented is certainly not only *my* vision. The PEP essentially describes NumPy arrays with an interchange format to convert between NumPy and PIL arrays. It is perhaps unfortunate that the protocol was named "buffer" protocol, since it is actually an advanced "array" protocol. NumPy arrays don't care about the raw memory. It is always the logical array that matters. For example, Fortran and C arrays have different bit patterns in memory but compare equal, a fact that the 3.2 implementation completely misses. Arrays v and w are equal iff format and shape are equal and for all valid indices allowed by shape memcmp((char *)PyBuffer_GetPointer(v, indices), (char *)PyBuffer_GetPointer(w, indices), itemsize) == 0. Equal formats of course imply equal itemsize. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 12:12:46 2012 From: report at bugs.python.org (Kushal Das) Date: Fri, 10 Aug 2012 10:12:46 +0000 Subject: [issue15615] More tests for JSON decoder to test Exceptions Message-ID: <1344593566.55.0.653447713109.issue15615@psf.upfronthosting.co.za> New submission from Kushal Das: Added two more tests in json module to test exception cases. test_extra_data: this test checks the error condition when we have extra data in the stream. test_invalid_escape: this test checks for the invalid escape sequence in the stream ---------- components: Tests files: json_tests.patch keywords: patch messages: 167863 nosy: kushaldas priority: normal severity: normal status: open title: More tests for JSON decoder to test Exceptions type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file26755/json_tests.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 12:49:17 2012 From: report at bugs.python.org (Jordi Puigsegur) Date: Fri, 10 Aug 2012 10:49:17 +0000 Subject: [issue15616] logging.FileHandler not correctly created with PyYaml (unpickling problems?) Message-ID: <1344595757.56.0.0377955516485.issue15616@psf.upfronthosting.co.za> New submission from Jordi Puigsegur: logging.FileHandler and logging.RotatingFileHandler (haven't tried other handlers) do not get correctly initialized in python 2.7 when loaded using PyYaml. Therefore I suspect that there is some problem with the implementation of the pickle protocol of these clases in python 2.7. Attached you can find a small test to reproduce the problem. It works in python 2.5 and 2.6 but fails in python 2.7. In all cases I've used PyYaml 3.10. ---------- components: Extension Modules messages: 167864 nosy: jordipf priority: normal severity: normal status: open title: logging.FileHandler not correctly created with PyYaml (unpickling problems?) type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 12:50:32 2012 From: report at bugs.python.org (Jordi Puigsegur) Date: Fri, 10 Aug 2012 10:50:32 +0000 Subject: [issue15616] logging.FileHandler not correctly created with PyYaml (unpickling problems?) In-Reply-To: <1344595757.56.0.0377955516485.issue15616@psf.upfronthosting.co.za> Message-ID: <1344595832.03.0.687864705467.issue15616@psf.upfronthosting.co.za> Jordi Puigsegur added the comment: import logging import logging.handlers import yaml logger = logging.getLogger() # root logger # Option 1 - OK ##handler = logging.handlers.RotatingFileHandler(filename = "test.log", maxBytes = 262144, backupCount = 3) # Option 2 - RotatingFileHandler fails when created through yaml handler = yaml.load(""" !!python/object/new:logging.handlers.RotatingFileHandler kwds: filename: test.log maxBytes: 262144 backupCount: 3 """) # Option 3 - FileHandler also fails when created through yaml ##handler = yaml.load(""" ##!!python/object/new:logging.FileHandler ## kwds: ## filename: test.log ##""") logger.addHandler(handler) logger.warning("test handler") ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 14:18:32 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 10 Aug 2012 12:18:32 +0000 Subject: [issue15616] logging.FileHandler not correctly created with PyYaml (unpickling problems?) In-Reply-To: <1344595757.56.0.0377955516485.issue15616@psf.upfronthosting.co.za> Message-ID: <1344601112.53.0.314347929175.issue15616@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 14:24:19 2012 From: report at bugs.python.org (=?utf-8?q?Ludwig_H=C3=A4hne?=) Date: Fri, 10 Aug 2012 12:24:19 +0000 Subject: [issue15424] __sizeof__ of array should include size of items In-Reply-To: <1342974161.65.0.374402048104.issue15424@psf.upfronthosting.co.za> Message-ID: <1344601459.63.0.958200046931.issue15424@psf.upfronthosting.co.za> Changes by Ludwig H?hne : Added file: http://bugs.python.org/file26756/array_sizeof_2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 14:24:40 2012 From: report at bugs.python.org (=?utf-8?q?Ludwig_H=C3=A4hne?=) Date: Fri, 10 Aug 2012 12:24:40 +0000 Subject: [issue15424] __sizeof__ of array should include size of items In-Reply-To: <1342974161.65.0.374402048104.issue15424@psf.upfronthosting.co.za> Message-ID: <1344601479.99.0.431210408532.issue15424@psf.upfronthosting.co.za> Changes by Ludwig H?hne : Added file: http://bugs.python.org/file26757/array_sizeof_3.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 14:25:24 2012 From: report at bugs.python.org (=?utf-8?q?Ludwig_H=C3=A4hne?=) Date: Fri, 10 Aug 2012 12:25:24 +0000 Subject: [issue15424] __sizeof__ of array should include size of items In-Reply-To: <1342974161.65.0.374402048104.issue15424@psf.upfronthosting.co.za> Message-ID: <1344601524.71.0.543820502789.issue15424@psf.upfronthosting.co.za> Changes by Ludwig H?hne : Removed file: http://bugs.python.org/file26713/array_sizeof_v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 14:25:34 2012 From: report at bugs.python.org (=?utf-8?q?Ludwig_H=C3=A4hne?=) Date: Fri, 10 Aug 2012 12:25:34 +0000 Subject: [issue15424] __sizeof__ of array should include size of items In-Reply-To: <1342974161.65.0.374402048104.issue15424@psf.upfronthosting.co.za> Message-ID: <1344601534.7.0.953841048603.issue15424@psf.upfronthosting.co.za> Changes by Ludwig H?hne : Removed file: http://bugs.python.org/file26510/array_sizeof_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 14:25:41 2012 From: report at bugs.python.org (=?utf-8?q?Ludwig_H=C3=A4hne?=) Date: Fri, 10 Aug 2012 12:25:41 +0000 Subject: [issue15424] __sizeof__ of array should include size of items In-Reply-To: <1342974161.65.0.374402048104.issue15424@psf.upfronthosting.co.za> Message-ID: <1344601541.31.0.243763739362.issue15424@psf.upfronthosting.co.za> Changes by Ludwig H?hne : Removed file: http://bugs.python.org/file26480/array_sizeof_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 14:25:48 2012 From: report at bugs.python.org (=?utf-8?q?Ludwig_H=C3=A4hne?=) Date: Fri, 10 Aug 2012 12:25:48 +0000 Subject: [issue15424] __sizeof__ of array should include size of items In-Reply-To: <1342974161.65.0.374402048104.issue15424@psf.upfronthosting.co.za> Message-ID: <1344601548.29.0.564681265233.issue15424@psf.upfronthosting.co.za> Changes by Ludwig H?hne : Removed file: http://bugs.python.org/file26479/array_sizeof.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 14:28:41 2012 From: report at bugs.python.org (=?utf-8?q?Ludwig_H=C3=A4hne?=) Date: Fri, 10 Aug 2012 12:28:41 +0000 Subject: [issue15424] __sizeof__ of array should include size of items In-Reply-To: <1342974161.65.0.374402048104.issue15424@psf.upfronthosting.co.za> Message-ID: <1344601721.29.0.805132567637.issue15424@psf.upfronthosting.co.za> Ludwig H?hne added the comment: Meador, Serhiy, I've add patches for Python 2.7 and Python 3.2 following Serhiy suggestions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 15:00:52 2012 From: report at bugs.python.org (Floris Bruynooghe) Date: Fri, 10 Aug 2012 13:00:52 +0000 Subject: [issue15617] FAIL: test_create_connection (test.test_socket.NetworkConnectionNoServer) Message-ID: <1344603652.0.0.278766609424.issue15617@psf.upfronthosting.co.za> New submission from Floris Bruynooghe: The SPARC Solaris 10 OpenCSW 3.x builder fails with ====================================================================== FAIL: test_create_connection (test.test_socket.NetworkConnectionNoServer) ---------------------------------------------------------------------- Traceback (most recent call last): File "/export/home/buildbot/buildarea/3.x.bruynooghe-solaris-csw/build/Lib/test/test_socket.py", line 4101, in test_create_connection self.assertEqual(cm.exception.errno, errno.ECONNREFUSED) AssertionError: 128 != 146 Here 128 is ENETUNREACH I think the issue here is that socket.create_connection iterates over the result of socket.getaddrinfo('localhost', port, 0, SOCK_STREAM) which returns [(2, 2, 0, '', ('127.0.0.1', 0)), (26, 2, 0, '', ('::1', 0, 0, 0))] on this host. The first result is tried and returns ECONNREFUSED but then the second address is tried and this returns ENETUNREACH because this host has not IPv6 network configured. And create_connection() raises the last exception it received. If getaddrinfo() is called with the AI_ADDRCONFIG flag then it will only return the IPv4 version of localhost. ---------- components: Tests messages: 167867 nosy: flub priority: normal severity: normal status: open title: FAIL: test_create_connection (test.test_socket.NetworkConnectionNoServer) type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 15:27:01 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 10 Aug 2012 13:27:01 +0000 Subject: [issue15617] FAIL: test_create_connection (test.test_socket.NetworkConnectionNoServer) In-Reply-To: <1344603652.0.0.278766609424.issue15617@psf.upfronthosting.co.za> Message-ID: <1344605221.3.0.494416329862.issue15617@psf.upfronthosting.co.za> R. David Murray added the comment: But if getaddrinfo returns an IPv6 address, shouldn't a localhost connection on that address work? It seems to me that a localhost connection failing when an IPv6 localhost address is returned is an OS configuration bug. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 15:29:24 2012 From: report at bugs.python.org (Floris Bruynooghe) Date: Fri, 10 Aug 2012 13:29:24 +0000 Subject: [issue15617] FAIL: test_create_connection (test.test_socket.NetworkConnectionNoServer) In-Reply-To: <1344605221.3.0.494416329862.issue15617@psf.upfronthosting.co.za> Message-ID: Floris Bruynooghe added the comment: It was my understanding that this is what the AI_ADDRCONFIG flag is for, if you don't use it you have no such guarantee. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 15:32:00 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 10 Aug 2012 13:32:00 +0000 Subject: [issue15528] Better support for finalization with weakrefs In-Reply-To: <1343837927.06.0.561023898829.issue15528@psf.upfronthosting.co.za> Message-ID: <1344605520.28.0.946157301969.issue15528@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 15:53:28 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 10 Aug 2012 13:53:28 +0000 Subject: [issue15617] FAIL: test_create_connection (test.test_socket.NetworkConnectionNoServer) In-Reply-To: <1344603652.0.0.278766609424.issue15617@psf.upfronthosting.co.za> Message-ID: <1344606808.93.0.882984967295.issue15617@psf.upfronthosting.co.za> R. David Murray added the comment: That sounds reasonable. However, on my box that has an IPv6 address configured on lo, I get the same result with or without that flag: lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:48000 errors:0 dropped:0 overruns:0 frame:0 TX packets:48000 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:3991442 (3.8 MiB) TX bytes:3991442 (3.8 MiB) Python 2.7.3 (default, Jun 19 2012, 16:12:47) [GCC 4.5.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import socket >>> socket.getaddrinfo('localhost', 80, 0, socket.SOCK_STREAM, 0) [(2, 1, 6, '', ('127.0.0.1', 80))] >>> socket.getaddrinfo('localhost', 80, 0, socket.SOCK_STREAM, 0, socket.AI_ADDRCONFIG) [(2, 1, 6, '', ('127.0.0.1', 80))] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 15:57:03 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 10 Aug 2012 13:57:03 +0000 Subject: [issue15365] Traceback reporting can fail if IO cannot be imported In-Reply-To: <1342434495.02.0.347473954517.issue15365@psf.upfronthosting.co.za> Message-ID: <1344607023.2.0.88815365889.issue15365@psf.upfronthosting.co.za> Changes by Kristj?n Valur J?nsson : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 16:08:46 2012 From: report at bugs.python.org (Floris Bruynooghe) Date: Fri, 10 Aug 2012 14:08:46 +0000 Subject: [issue15617] FAIL: test_create_connection (test.test_socket.NetworkConnectionNoServer) In-Reply-To: <1344606808.93.0.882984967295.issue15617@psf.upfronthosting.co.za> Message-ID: Floris Bruynooghe added the comment: I think this is influenced by what you have in /etc/hosts. On my laptop I also have IPv6 loopback as well as an IPv6 link-local on eth0. But I have both 127.0.0.1 and ::1 in /etc/hosts as locahost. With that configuration I get the same getaddrinfo results as on the solaris host (which btw, has the same /etc/hosts configuration for localhost, i.e. both IPv4 & IPv6). Basically I don't think loopback and link-local addresses count as "configured address" for getaddrinfo. Btw, removing the "::1 localhost" line from /etc/hosts on the solaris host does fix the issue and gives the same results you show. But I don't think this is correct. My linux laptop behaves exactly the same as the solaris host here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 16:14:12 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Aug 2012 14:14:12 +0000 Subject: [issue15617] FAIL: test_create_connection (test.test_socket.NetworkConnectionNoServer) In-Reply-To: <1344603652.0.0.278766609424.issue15617@psf.upfronthosting.co.za> Message-ID: <1344608052.11.0.777712219504.issue15617@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 16:39:36 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 10 Aug 2012 14:39:36 +0000 Subject: [issue15617] FAIL: test_create_connection (test.test_socket.NetworkConnectionNoServer) In-Reply-To: <1344603652.0.0.278766609424.issue15617@psf.upfronthosting.co.za> Message-ID: <1344609576.4.0.605511554322.issue15617@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I was about to say that I agree that AI_ADDRCONFIG should be used in create_connection. However, RFC 3493 deviates from RFC 2553 by stating """If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be returned only if an IPv4 address is configured on the local system, and IPv6 addresses shall be returned only if an IPv6 address is configured on the local system. The loopback address is not considered for this case as valid as a configured address. """ If this is taken literally, then it would not be possible to connect anymore to localhost if you have no IP address configured except for the loopback addresses - which in turn would make the test fail also (and would clearly be undesirable). OSX clearly ignores that RFC - even with no IPv4 address configured, I get a result that includes 127.0.0.1. I wonder how other systems respond to socket.getaddrinfo('localhost', 80, 0, socket.SOCK_STREAM, 0, socket.AI_ADDRCONFIG) if all interfaces except for lo are down (remember to reactivate the interfaces before posting a response to the bug tracker :-) Any patch needs to be careful to use the flag only if available. Microsoft points out that the flag works only on Vista+. Not sure whether it just has no effect on XP, or makes the call fail. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 16:45:26 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 10 Aug 2012 14:45:26 +0000 Subject: [issue15617] FAIL: test_create_connection (test.test_socket.NetworkConnectionNoServer) In-Reply-To: <1344603652.0.0.278766609424.issue15617@psf.upfronthosting.co.za> Message-ID: <1344609926.92.0.0655088328433.issue15617@psf.upfronthosting.co.za> R. David Murray added the comment: Hmm. I wonder what is different on my (linux) box. I have ::1 in /etc/hosts for localhost. Regardless, it certainly wouldn't hurt to add the flag to the test. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 17:03:31 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 10 Aug 2012 15:03:31 +0000 Subject: [issue15610] PyImport_ImportModuleEx always fails in 3.3 with "ValueError: level must be >= 0" In-Reply-To: <1344542648.98.0.69001231241.issue15610@psf.upfronthosting.co.za> Message-ID: <1344611011.01.0.251797192531.issue15610@psf.upfronthosting.co.za> Brett Cannon added the comment: OK, the macro expansion should get fixed, a versionchanged should probably be added to the C API docs (for PyImport_ImportModuleLevel()), and a line in What's New for porting C code should be added. We can't go back to -1, as Eric said, because it makes no sense anymore since you can't syntactically do an import that has -1 level semantics in Python 3. The fact that __import__ accepted a negative level was a bug that went unnoticed up until this point since so few people import modules programmatically and want implicit relative imports. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 17:04:48 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 10 Aug 2012 15:04:48 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1344611088.2.0.46094405318.issue15502@psf.upfronthosting.co.za> Brett Cannon added the comment: I still need a core committer to double-check me on Eric's patch to make sure the ABC changes are acceptable. I can handle the commit if someone will just sign off. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 17:23:50 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 10 Aug 2012 15:23:50 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1344612230.82.0.0415417731028.issue15502@psf.upfronthosting.co.za> Nick Coghlan added the comment: Done. Only substantive comment was that Finder should be registered with both of the more specific metaclasses, but there were a couple of docs comments as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 17:25:25 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 10 Aug 2012 15:25:25 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1344612325.52.0.645262731486.issue15502@psf.upfronthosting.co.za> Nick Coghlan added the comment: Oh, and +1 for Eric's "path-based finder". States clearly that it is a finder that *uses* import paths, rather than finding them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 17:33:41 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 10 Aug 2012 15:33:41 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1344612821.69.0.869863447998.issue15502@psf.upfronthosting.co.za> Brett Cannon added the comment: Thanks for the review, Nick! I will get this patch committed sometime today with your comments integrated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 17:36:34 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 10 Aug 2012 15:36:34 +0000 Subject: [issue15617] FAIL: test_create_connection (test.test_socket.NetworkConnectionNoServer) In-Reply-To: <1344603652.0.0.278766609424.issue15617@psf.upfronthosting.co.za> Message-ID: <1344612994.8.0.551526892718.issue15617@psf.upfronthosting.co.za> Martin v. L?wis added the comment: David: I get the same on Linux as you, however, in the standard Debian installation, ::1 is *not* an address for "localhost", only for "ip6-localhost" and "ip6-loopback". Likewise, on Redhat, it seems that only "localhost6" gives you ::1. What Linux distribution are you using? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 17:37:20 2012 From: report at bugs.python.org (Vinay Sajip) Date: Fri, 10 Aug 2012 15:37:20 +0000 Subject: [issue15616] logging.FileHandler not correctly created with PyYaml (unpickling problems?) In-Reply-To: <1344595757.56.0.0377955516485.issue15616@psf.upfronthosting.co.za> Message-ID: <1344613040.81.0.856319228806.issue15616@psf.upfronthosting.co.za> Vinay Sajip added the comment: The problem appears to be in PyYAML, not logging. Note the content of the attribute dictionaries in the following script: import logging import logging.handlers from pprint import pprint import yaml # Option 1 - OK h1 = logging.handlers.RotatingFileHandler(filename = "test.log", maxBytes = 262144, backupCount = 3) h2 = yaml.load(""" !!python/object/new:logging.handlers.RotatingFileHandler kwds: filename: test.log maxBytes: 262144 backupCount: 3 """) h3 = logging.FileHandler('test.log') h4 = yaml.load(""" !!python/object/new:logging.FileHandler kwds: filename: test.log """) print('RotatingFileHandler using code: %s' % type(h1)) pprint(h1.__dict__) print('RotatingFileHandler using YAML: %s' % type(h2)) pprint(h2.__dict__) print('FileHandler using code: %s' % type(h3)) pprint(h3.__dict__) print('FileHandler using YAML: %s' % type(h4)) pprint(h4.__dict__) which prints RotatingFileHandler using code: {'_name': None, 'backupCount': 3, 'baseFilename': '/home/vinay/projects/scratch/test.log', 'encoding': None, 'filters': [], 'formatter': None, 'level': 0, 'lock': <_RLock owner=None count=0>, 'maxBytes': 262144, 'mode': 'a', 'stream': } RotatingFileHandler using YAML: {} FileHandler using code: {'_name': None, 'baseFilename': '/home/vinay/projects/scratch/test.log', 'encoding': None, 'filters': [], 'formatter': None, 'level': 0, 'lock': <_RLock owner=None count=0>, 'mode': 'a', 'stream': } FileHandler using YAML: {} I suggest that you: (a) Consider logging an issue with PyYAML. (b) Consider using dictConfig(), which is available in Python 2.7 amd also available for older Pythons through http://code.google.com/p/logutils/ ---------- assignee: -> vinay.sajip resolution: -> invalid status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 17:53:36 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 10 Aug 2012 15:53:36 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1344614016.22.0.27729128725.issue15502@psf.upfronthosting.co.za> Brett Cannon added the comment: Actually there is one issue with PathEntryFinder inheriting from Finder; it doesn't need to implement find_module() if it doesn't want to in Python 3.3. So I will need to stick in a dummy find_module() on the class that calls find_loader() and then returns any found loader and tosses the namespace paths. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 17:58:44 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 10 Aug 2012 15:58:44 +0000 Subject: [issue15617] FAIL: test_create_connection (test.test_socket.NetworkConnectionNoServer) In-Reply-To: <1344603652.0.0.278766609424.issue15617@psf.upfronthosting.co.za> Message-ID: <1344614324.94.0.921059072831.issue15617@psf.upfronthosting.co.za> R. David Murray added the comment: I see our previous messages crossed, I'm glad you investigated this more throughly than I did, since clearly just adding the flag could break things. I'm using gentoo linux (gentoo stable on that particular machine). I don't guarantee my /etc/hosts file is stock gentoo, but I think it is other than adding my host name to the localhost lines. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 18:03:20 2012 From: report at bugs.python.org (=?utf-8?q?Juancarlo_A=C3=B1ez?=) Date: Fri, 10 Aug 2012 16:03:20 +0000 Subject: [issue15618] turtle.pencolor() chokes on unicode Message-ID: <1344614600.09.0.172205125468.issue15618@psf.upfronthosting.co.za> New submission from Juancarlo A?ez: >>> t.pencolor(u'red') Traceback (most recent call last): File "", line 1, in File "", line 1, in pencolor File "/usr/lib/python2.7/lib-tk/turtle.py", line 2166, in pencolor color = self._colorstr(args) File "/usr/lib/python2.7/lib-tk/turtle.py", line 2600, in _colorstr return self.screen._colorstr(args) File "/usr/lib/python2.7/lib-tk/turtle.py", line 1111, in _colorstr r, g, b = [round(255.0*x) for x in (r, g, b)] TypeError: can't multiply sequence by non-int of type 'float' ---------- components: Library (Lib) messages: 167883 nosy: apalala priority: normal severity: normal status: open title: turtle.pencolor() chokes on unicode type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 18:04:14 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 10 Aug 2012 16:04:14 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1344614654.36.0.275586824245.issue15573@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Can you please elaborate on the specification: 1. what does it mean that the formats of v and w are equal? 2. Victor's clarification about this issue isn't about comparing two arrays, but an array with a string object. So: when is an array equal to some other (non-array) object? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 18:05:25 2012 From: report at bugs.python.org (Jordi Puigsegur) Date: Fri, 10 Aug 2012 16:05:25 +0000 Subject: [issue15616] logging.FileHandler not correctly created with PyYaml (unpickling problems?) In-Reply-To: <1344595757.56.0.0377955516485.issue15616@psf.upfronthosting.co.za> Message-ID: <1344614725.81.0.0715130074809.issue15616@psf.upfronthosting.co.za> Jordi Puigsegur added the comment: Thanks for your answer. I am not sure it is a PyYaml bug. Did you notice that the same code works perfectly (with the same version of PyYaml) using python 2.6 and python 2.5? Could it be that the issue lies in some change in the way the pickle protocol is implemented in logging classes? ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 18:08:59 2012 From: report at bugs.python.org (Jordi Puigsegur) Date: Fri, 10 Aug 2012 16:08:59 +0000 Subject: [issue15616] logging.FileHandler not correctly created with PyYaml (unpickling problems?) In-Reply-To: <1344595757.56.0.0377955516485.issue15616@psf.upfronthosting.co.za> Message-ID: <1344614939.56.0.123330324369.issue15616@psf.upfronthosting.co.za> Jordi Puigsegur added the comment: This is the output of your script when run in python 2.6 and the exact same PyYaml version: C:\>test.py RotatingFileHandler using code: {'backupCount': 3, 'baseFilename': 'C:\\test.log', 'encoding': None, 'filters': [], 'formatter': None, 'level': 0, 'lock': <_RLock(None, 0)>, 'maxBytes': 262144, 'mode': 'a', 'stream': } RotatingFileHandler using YAML: {'backupCount': 3, 'baseFilename': 'C:\\test.log', 'encoding': None, 'filters': [], 'formatter': None, 'level': 0, 'lock': <_RLock(None, 0)>, 'maxBytes': 262144, 'mode': 'a', 'stream': } FileHandler using code: {'baseFilename': 'C:\\test.log', 'encoding': None, 'filters': [], 'formatter': None, 'level': 0, 'lock': <_RLock(None, 0)>, 'mode': 'a', 'stream': } FileHandler using YAML: {'baseFilename': 'C:\\test.log', 'encoding': None, 'filters': [], 'formatter': None, 'level': 0, 'lock': <_RLock(None, 0)>, 'mode': 'a', 'stream': } ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 18:09:17 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 10 Aug 2012 16:09:17 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1344614957.62.0.419063092003.issue15502@psf.upfronthosting.co.za> Nick Coghlan added the comment: Sounds good. Perhaps steal the impl from FileFinder.find_module (i.e. the one with the ImportWarning). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 18:21:23 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Aug 2012 16:21:23 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <3Wts5s5xP7zPvR@mail.python.org> Roundup Robot added the comment: New changeset 0a75ce232f56 by Brett Cannon in branch 'default': Issue #15502: Finish bringing importlib.abc in line with the current http://hg.python.org/cpython/rev/0a75ce232f56 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 18:21:52 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 10 Aug 2012 16:21:52 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1344615712.45.0.630829202405.issue15502@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: -> brett.cannon resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 18:33:01 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Aug 2012 16:33:01 +0000 Subject: [issue15424] __sizeof__ of array should include size of items In-Reply-To: <1342974161.65.0.374402048104.issue15424@psf.upfronthosting.co.za> Message-ID: <1344616381.45.0.10679275234.issue15424@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Patches look good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 18:37:06 2012 From: report at bugs.python.org (Matthew Barnett) Date: Fri, 10 Aug 2012 16:37:06 +0000 Subject: [issue15606] re.VERBOSE doesn't ignore certain whitespace In-Reply-To: <1344534617.67.0.49137100671.issue15606@psf.upfronthosting.co.za> Message-ID: <1344616626.06.0.69092952466.issue15606@psf.upfronthosting.co.za> Matthew Barnett added the comment: Ideally, yes, that whitespace should be ignored. The question is whether it's worth fixing the code for the small case of when there's whitespace within "tokens", such as within "(?:". Usually those who use verbose mode use whitespace as in the first example rather than the second or third examples. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 18:46:00 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 10 Aug 2012 16:46:00 +0000 Subject: [issue15576] importlib: ExtensionFileLoader not used to load packages from __init__.so files In-Reply-To: <1344364550.12.0.263881849199.issue15576@psf.upfronthosting.co.za> Message-ID: <1344617160.9.0.174696431501.issue15576@psf.upfronthosting.co.za> Brett Cannon added the comment: To add a nice wrinkle to all of this, Windows debug builds use _d.pyd as the extension suffix. Notice how that doesn't start with a nice '.' to make finding the suffix easy? Yeah, that complicates ExtensionLoader.is_package() as I will have to now directly reference imp.extension_suffixes() which sucks as it hard codes what extensions are used instead of being more flexible and just ignoring that bit of detail. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 18:46:43 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 10 Aug 2012 16:46:43 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344614654.36.0.275586824245.issue15573@psf.upfronthosting.co.za> Message-ID: <20120810164643.GA21311@sleipnir.bytereef.org> Stefan Krah added the comment: > 1. what does it mean that the formats of v and w are equal? I'm using array and Py_buffer interchangeably since a Py_buffer struct actually describes a multi-dimensional array. v and w are Py_buffer structs. So v.format must equal w.format, where format is a format string in struct module syntax. The topic of this issue is to determine under what circumstances two strings in struct module syntax are considered equal. > 2. Victor's clarification about this issue isn't about comparing > two arrays, but an array with a string object. So: when is an > array equal to some other (non-array) object? >>> a=array.array('u', 'abc') >>> v=memoryview(a) >>> a == v False memoryview can compare against any object with a getbufferproc, in this case array.array. memoryview_richcompare() calls PyObject_GetBuffer(other) and proceeds to compare its own internal Py_buffer v against the obtained Py_buffer w. In the case of v.format == w.format the fix for unknown formats is trivial: Just allow the comparison using v.itemsize == w.itemsize. However, the struct module format string syntax has multiple representations for the exact same formats, which makes a general fmtcmp() function tricky to write. Hence my proposal to demand a strict canonical form for PEP-3118 format strings, which would be a proper subset of struct module format strings. Example: "1Q 1h 1h 0c" must be written as "Q2h" The attached patch should largely implement this proposal. A canonical form is perhaps not such a severe restriction, since format strings should usually come from the exporting object. E.g. NumPy must translate its own internal format to struct module syntax anyway. Another option is to commit the patch that misses "1Q 1h 1h 0c" == "Q2h" now and aim for a completely general fmtcmp() function later. IMO any general fmtcmp() function should also be reasonably fast. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 18:55:59 2012 From: report at bugs.python.org (=?utf-8?q?Juancarlo_A=C3=B1ez?=) Date: Fri, 10 Aug 2012 16:55:59 +0000 Subject: [issue15618] turtle.pencolor() chokes on unicode In-Reply-To: <1344614600.09.0.172205125468.issue15618@psf.upfronthosting.co.za> Message-ID: <1344617759.7.0.314082673575.issue15618@psf.upfronthosting.co.za> Juancarlo A?ez added the comment: This patch solves the problem by making turtle check for string against basestring insted of str. ---------- keywords: +patch Added file: http://bugs.python.org/file26758/turtle_unicode.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 18:57:17 2012 From: report at bugs.python.org (=?utf-8?q?Juancarlo_A=C3=B1ez?=) Date: Fri, 10 Aug 2012 16:57:17 +0000 Subject: [issue15618] turtle.pencolor() chokes on unicode In-Reply-To: <1344614600.09.0.172205125468.issue15618@psf.upfronthosting.co.za> Message-ID: <1344617837.33.0.296574155415.issue15618@psf.upfronthosting.co.za> Juancarlo A?ez added the comment: The bug showed up in a script that used: from __future__ import unicode_literals ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 19:00:37 2012 From: report at bugs.python.org (Anton Barkovsky) Date: Fri, 10 Aug 2012 17:00:37 +0000 Subject: [issue15619] set.pop() documentation is confusing Message-ID: <1344618037.56.0.180857991175.issue15619@psf.upfronthosting.co.za> New submission from Anton Barkovsky: I've seen people being confused by the documentation for set.pop() method. It makes it look like the element is selected randomly while it's just unspecified. I'm attaching a patch that clarifies the doc, tested on 3.3, 3.2 and 2.7 ---------- assignee: docs at python components: Documentation files: set_pop_doc.patch keywords: patch messages: 167895 nosy: anton.barkovsky, docs at python priority: normal severity: normal status: open title: set.pop() documentation is confusing versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file26759/set_pop_doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 19:06:17 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 10 Aug 2012 17:06:17 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1344618377.61.0.10268510321.issue15573@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 19:14:18 2012 From: report at bugs.python.org (Georg Brandl) Date: Fri, 10 Aug 2012 17:14:18 +0000 Subject: [issue15619] set.pop() documentation is confusing In-Reply-To: <1344618037.56.0.180857991175.issue15619@psf.upfronthosting.co.za> Message-ID: <1344618858.85.0.0163811307339.issue15619@psf.upfronthosting.co.za> Georg Brandl added the comment: Sorry, I don't see how "arbitrary" implies "random". So I'm -1 on making the docs more verbose for no apparent gain. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 19:22:17 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 10 Aug 2012 17:22:17 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <1344619337.09.0.964580455559.issue15502@psf.upfronthosting.co.za> Brett Cannon added the comment: I will go back and steal the FileFinder.find_module implementation after I finish the current patch I'm working on. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 19:28:33 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 10 Aug 2012 17:28:33 +0000 Subject: [issue15577] Real argc and argv in embedded interpreter In-Reply-To: <1344371910.44.0.262957922939.issue15577@psf.upfronthosting.co.za> Message-ID: <1344619713.29.0.870675892579.issue15577@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 19:40:16 2012 From: report at bugs.python.org (Eli Bendersky) Date: Fri, 10 Aug 2012 17:40:16 +0000 Subject: [issue15619] set.pop() documentation is confusing In-Reply-To: <1344618037.56.0.180857991175.issue15619@psf.upfronthosting.co.za> Message-ID: <1344620416.35.0.529877050886.issue15619@psf.upfronthosting.co.za> Eli Bendersky added the comment: I agree with Georg. As far as I understand the word "arbitrary" - it describes the situation exactly. ---------- nosy: +eli.bendersky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 19:47:10 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 10 Aug 2012 17:47:10 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <20120810164643.GA21311@sleipnir.bytereef.org> Message-ID: <50254916.2050400@v.loewis.de> Martin v. L?wis added the comment: > So v.format must equal w.format, where format is a format string in > struct module syntax. The topic of this issue is to determine under > what circumstances two strings in struct module syntax are considered > equal. And that is exactly my question: We don't need a patch implementing it (yet), but a specification of what is to be implemented first. I know when two strings are equal (regardless of their syntax): if they have the same length, and contain the same characters in the same order. Apparently, you have a different notion of "equal" for strings in mind, please be explicitly what that notion is. > memoryview can compare against any object with a getbufferproc, in this > case array.array. memoryview_richcompare() calls PyObject_GetBuffer(other) > and proceeds to compare its own internal Py_buffer v against the obtained > Py_buffer w. Can this be expressed on Python level as well? I.e. is it correct to say: an array/buffer/memoryview A is equal to an object O iff A is equal to memoryview(O)? Or could it be that these two equivalences might reasonably differ? > Hence my proposal to demand a strict canonical form for PEP-3118 format > strings, which would be a proper subset of struct module format strings. Can you kindly phrase this as a specification? Who is demanding what from whom? Proposal: two format strings are equal if their canonical forms are equal strings. The canonical form C of a string S is created by ??? However, it appears that you may have something different in mind where things are rejected/fail to work if the canonical form isn't originally provided by somebody (whom?) So another Proposal: two format strings are equal iff they are in both in canonical form and are equal strings. This would imply that a format string which is not in canonical form is not equal to any other strings, not even to itself, so this may still not be what you want. But I can't guess what it is that you want. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 19:48:03 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Aug 2012 17:48:03 +0000 Subject: [issue15576] importlib: ExtensionFileLoader not used to load packages from __init__.so files In-Reply-To: <1344364550.12.0.263881849199.issue15576@psf.upfronthosting.co.za> Message-ID: <3Wtv1t3GK8zPkK@mail.python.org> Roundup Robot added the comment: New changeset 1db6553f3f8c by Brett Cannon in branch 'default': Issue #15576: Allow extension modules to be a package's __init__ http://hg.python.org/cpython/rev/1db6553f3f8c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 19:48:52 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 10 Aug 2012 17:48:52 +0000 Subject: [issue15576] importlib: ExtensionFileLoader not used to load packages from __init__.so files In-Reply-To: <1344364550.12.0.263881849199.issue15576@psf.upfronthosting.co.za> Message-ID: <1344620932.19.0.404421770187.issue15576@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: -> brett.cannon resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 19:55:03 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Aug 2012 17:55:03 +0000 Subject: [issue15444] Incorrectly written contributor's names In-Reply-To: <1343161512.09.0.0619646494936.issue15444@psf.upfronthosting.co.za> Message-ID: <1344621303.17.0.292931184532.issue15444@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What about patch review? ---------- keywords: +needs review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 19:56:11 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Aug 2012 17:56:11 +0000 Subject: [issue15444] Incorrectly written contributor's names In-Reply-To: <1343161512.09.0.0619646494936.issue15444@psf.upfronthosting.co.za> Message-ID: <1344621371.96.0.891246518428.issue15444@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file26504/doc-nonascii-names.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 20:01:11 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Aug 2012 18:01:11 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <50254916.2050400@v.loewis.de> Message-ID: STINNER Victor added the comment: Can't we start with something simple (for ptyhon 3.3?), and elaborate later? In my specific example, both object have the same format string and the same content. So i expect that they are equal. Le 10 ao?t 2012 19:47, "Martin v. L?wis" a ?crit : > > Martin v. L?wis added the comment: > > > So v.format must equal w.format, where format is a format string in > > struct module syntax. The topic of this issue is to determine under > > what circumstances two strings in struct module syntax are considered > > equal. > > And that is exactly my question: We don't need a patch implementing > it (yet), but a specification of what is to be implemented first. > > I know when two strings are equal (regardless of their syntax): > if they have the same length, and contain the same characters in > the same order. Apparently, you have a different notion of "equal" > for strings in mind, please be explicitly what that notion is. > > > memoryview can compare against any object with a getbufferproc, in this > > case array.array. memoryview_richcompare() calls > PyObject_GetBuffer(other) > > and proceeds to compare its own internal Py_buffer v against the obtained > > Py_buffer w. > > Can this be expressed on Python level as well? I.e. is it correct > to say: an array/buffer/memoryview A is equal to an object O iff > A is equal to memoryview(O)? Or could it be that these two equivalences > might reasonably differ? > > > Hence my proposal to demand a strict canonical form for PEP-3118 format > > strings, which would be a proper subset of struct module format strings. > > Can you kindly phrase this as a specification? Who is demanding what > from whom? > > Proposal: two format strings are equal if their canonical forms > are equal strings. The canonical form C of a string S is created by ??? > > However, it appears that you may have something different in mind > where things are rejected/fail to work if the canonical form isn't > originally provided by somebody (whom?) > > So another Proposal: two format strings are equal iff they are > in both in canonical form and are equal strings. > > This would imply that a format string which is not in canonical > form is not equal to any other strings, not even to itself, so > this may still not be what you want. But I can't guess what it > is that you want. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 20:11:49 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 10 Aug 2012 18:11:49 +0000 Subject: [issue15618] turtle.pencolor() chokes on unicode In-Reply-To: <1344614600.09.0.172205125468.issue15618@psf.upfronthosting.co.za> Message-ID: <1344622309.28.0.890359276421.issue15618@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 20:18:24 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Aug 2012 18:18:24 +0000 Subject: [issue15527] Double parens in functions references In-Reply-To: <1343833557.96.0.948912415493.issue15527@psf.upfronthosting.co.za> Message-ID: <1344622704.44.0.0726340180796.issue15527@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Sorry, I don't know anything about the Sphinx, therefore, I do not know what is the problem and what the solution should be. 1) If this is the improper use of markup (the arguments are not supported and must not), we need to remove markup from other doc files (Doc/library/os.rst, Doc/library/platform.rst, Doc/library/unittest.rst, Doc/whatsnew/2.0.rst, Doc/whatsnew/2.1.rst, Doc/whatsnew/2.2.rst, Doc/whatsnew/2.3.rst, Doc/whatsnew/2.4.rst, Doc/whatsnew/2.5.rst, Doc/whatsnew/3.0.rst). 2) If the behaviour of the markup is controlled by configuration files, which are under the management of the CPython team, then these configuration files should be fixed. 3) If the behaviour of the markup is hardcoded inside the Sphinx, then it is the Sphinx bug and it should be reported to Sphinx team. I don't know what CPython team can/should do with it. Which of these variants is actual? Note, :c:macro: works for names with arguments, and :c:func:, :func:, :meth: did not. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 20:22:34 2012 From: report at bugs.python.org (Georg Brandl) Date: Fri, 10 Aug 2012 18:22:34 +0000 Subject: [issue15527] Double parens in functions references In-Reply-To: <1343833557.96.0.948912415493.issue15527@psf.upfronthosting.co.za> Message-ID: <1344622954.71.0.756568130815.issue15527@psf.upfronthosting.co.za> Georg Brandl added the comment: 1) is correct. (And cmacro works because it's only for non-function macros anyway.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 20:27:03 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Aug 2012 18:27:03 +0000 Subject: [issue15607] New print's argument "flush" is not mentioned in docstring In-Reply-To: <1344537615.2.0.181912402642.issue15607@psf.upfronthosting.co.za> Message-ID: <1344623223.76.0.851348214289.issue15607@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 20:30:43 2012 From: report at bugs.python.org (Georg Brandl) Date: Fri, 10 Aug 2012 18:30:43 +0000 Subject: [issue15607] New print's argument "flush" is not mentioned in docstring In-Reply-To: <1344537615.2.0.181912402642.issue15607@psf.upfronthosting.co.za> Message-ID: <1344623443.6.0.51233053263.issue15607@psf.upfronthosting.co.za> Georg Brandl added the comment: LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 20:32:34 2012 From: report at bugs.python.org (Georg Brandl) Date: Fri, 10 Aug 2012 18:32:34 +0000 Subject: [issue15619] set.pop() documentation is confusing In-Reply-To: <1344618037.56.0.180857991175.issue15619@psf.upfronthosting.co.za> Message-ID: <1344623554.17.0.902923521132.issue15619@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 20:37:44 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Aug 2012 18:37:44 +0000 Subject: [issue15604] PyObject_IsTrue failure checks In-Reply-To: <1344525855.66.0.08938802791.issue15604@psf.upfronthosting.co.za> Message-ID: <1344623864.36.0.991881738919.issue15604@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I shall try to do this, but it will take a lot of time. Besides, now in the code there are a lot of *correct* checked usage of PyObject_IsTrue without test cases. So I'm not sure that the tests are needed here, and that they are worth the effort. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 21:15:59 2012 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Fri, 10 Aug 2012 19:15:59 +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: <1344626159.06.0.172652512692.issue15594@psf.upfronthosting.co.za> ?ukasz Langa added the comment: I will be able to look at this on Monday (currently on vacation). The only unusual thing that comes to mind is that this is a virtual machine. Oh, and it's Snow Leopard *Server* (unfortunately I don't have any desktop licenses handy, and I'm not sure if I could use them on a VM anyway). Expect more info on Monday. ---------- assignee: -> lukasz.langa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 21:18:07 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 10 Aug 2012 19:18:07 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: Message-ID: <50255E72.4050803@v.loewis.de> Martin v. L?wis added the comment: > Can't we start with something simple (for ptyhon 3.3?), and elaborate > later? Sure: someone would have to make a proposal what exactly that is. IMO, the 3.2 definition *was* simple, but apparently it was considered too simple. So either Stefan gets to define his view of equality, or somebody else needs to make a (specific) counter-proposal. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 21:23:38 2012 From: report at bugs.python.org (Eric Snow) Date: Fri, 10 Aug 2012 19:23:38 +0000 Subject: [issue15365] Traceback reporting can fail if IO cannot be imported In-Reply-To: <1342434495.02.0.347473954517.issue15365@psf.upfronthosting.co.za> Message-ID: <1344626618.05.0.74333579642.issue15365@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 21:31:19 2012 From: report at bugs.python.org (Eric Snow) Date: Fri, 10 Aug 2012 19:31:19 +0000 Subject: [issue15582] Enhance inspect.getdoc to follow inheritance chains In-Reply-To: <1344394334.01.0.280520797106.issue15582@psf.upfronthosting.co.za> Message-ID: <1344627079.84.0.958561310293.issue15582@psf.upfronthosting.co.za> Eric Snow added the comment: I have just the thing for this, but haven't had a chance to put a patch together. I might be able to get to it in the next week if Dave "bitey" Beazley isn't too much of a distraction. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 21:40:02 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 10 Aug 2012 19:40:02 +0000 Subject: [issue15527] Double parens in functions references In-Reply-To: <1343833557.96.0.948912415493.issue15527@psf.upfronthosting.co.za> Message-ID: <1344627602.31.0.85799452246.issue15527@psf.upfronthosting.co.za> Chris Jerdonek added the comment: - a distinct non-*NULL* pointer if possible, as if :c:func:`PyMem_Malloc(1)` had + a distinct non-*NULL* pointer if possible, as if ``PyMem_Malloc(1)`` had > From my perspective sphinx doesn't allow notations like :c:func:`PyMem_Malloc(1)` I believe that it does. Sphinx allows you to specify link text distinct from the target for various roles: http://docs.python.org/devguide/documenting.html#id3 So for the above, it would be-- :c:func:`PyMem_Malloc(1) ` I confirmed that this works. I think this is preferable to displaying the preferred text without any hyperlink. ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 22:03:59 2012 From: report at bugs.python.org (Glenn Linderman) Date: Fri, 10 Aug 2012 20:03:59 +0000 Subject: [issue15564] cgi.FieldStorage should not call read_multi on files In-Reply-To: <1344245506.28.0.499641288303.issue15564@psf.upfronthosting.co.za> Message-ID: <1344629039.75.0.49719721717.issue15564@psf.upfronthosting.co.za> Changes by Glenn Linderman : ---------- nosy: +v+python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 22:05:49 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 10 Aug 2012 20:05:49 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <50255E72.4050803@v.loewis.de> Message-ID: <20120810200549.GA23186@sleipnir.bytereef.org> Stefan Krah added the comment: The ideal specification is: 1) Arrays v and w are equal iff format and shape are equal and for all valid indices allowed by shape memcmp((char *)PyBuffer_GetPointer(v, indices), (char *)PyBuffer_GetPointer(w, indices), itemsize) == 0. 2) Two format strings s and t are equal if canonical(s) == canonical(t). End ideal specification. Purely to *facilitate* the implementation of a format comparison function, I suggested: 3) An exporter must initialize the format field of a Py_buffer structure with canonical(s). If *all* exporters obey 3), a format comparison function can simply call strcmp(s, t) (after sorting out the byte order specifier). Specifically, if x and y are equal, then: a) x == memoryview(x) == memoryview(y) == y If x and y are equal and exporter x does *not* obey 3), but exporter y does, then: b) x == memoryview(x) != memoryview(y) == y Under rule 3) this would be the fault of exporter x. For Python 3.3 it is also possible to state only 1) and 2), with a caveat in the documentation that case b) might occur until the format comparison function in memoryview implements the reductions to canonical forms. The problem is that reductions to canonical forms might get very complicated if #3132 is implemented. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 22:18:01 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Fri, 10 Aug 2012 20:18:01 +0000 Subject: [issue15564] cgi.FieldStorage should not call read_multi on files In-Reply-To: <1344245506.28.0.499641288303.issue15564@psf.upfronthosting.co.za> Message-ID: <1344629881.3.0.726469075171.issue15564@psf.upfronthosting.co.za> Changes by Senthil Kumaran : ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 22:53:42 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 10 Aug 2012 20:53:42 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1344632022.73.0.465608137429.issue15573@psf.upfronthosting.co.za> Stefan Krah added the comment: Martin v. Loewis wrote: > Sure: someone would have to make a proposal what exactly that is. > IMO, the 3.2 definition *was* simple, but apparently it was considered > too simple. It was simply broken in multiple ways. Example: >>> from numpy import * >>> x = array([1,2,3,4,5], dtype='B') >>> y = array([5,4,3,2,1], dtype='B') >>> z = y[::-1] >>> >>> x == z array([ True, True, True, True, True], dtype=bool) >>> memoryview(x) == memoryview(z) False Segmentation fault I'm not even talking about the segfault here. Note that x == z, but memoryview(x) != memoryview(z), because the logical structure is not taken into account. Likewise, one could construct cases where one array contains a float NaN and the other an integer that happens to have the same bit pattern. The arrays would not be equal, but their memoryviews would be equal. > So either Stefan gets to define his view of equality, or > somebody else needs to make a (specific) counter-proposal. The view is defined by the PEP that clearly models NumPy. I'm curious what counter-proposal will work with NumPy and PIL. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 22:54:09 2012 From: report at bugs.python.org (Francois Dion) Date: Fri, 10 Aug 2012 20:54:09 +0000 Subject: [issue13405] Add DTrace probes In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za> Message-ID: <1344632049.73.0.360445272732.issue13405@psf.upfronthosting.co.za> Changes by Francois Dion : ---------- nosy: +Francois.Dion _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 22:55:53 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Aug 2012 20:55:53 +0000 Subject: [issue15607] New print's argument "flush" is not mentioned in docstring In-Reply-To: <1344537615.2.0.181912402642.issue15607@psf.upfronthosting.co.za> Message-ID: <3WtzBY4yLwzQ4H@mail.python.org> Roundup Robot added the comment: New changeset e4877d59613d by Senthil Kumaran in branch 'default': Fix issue #15607: Update the print builtin function docstring with the new flush keyword. http://hg.python.org/cpython/rev/e4877d59613d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 23:03:37 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Fri, 10 Aug 2012 21:03:37 +0000 Subject: [issue15607] New print's argument "flush" is not mentioned in docstring In-Reply-To: <1344537615.2.0.181912402642.issue15607@psf.upfronthosting.co.za> Message-ID: <1344632617.02.0.300630500518.issue15607@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Thanks for raising this issue, Serhiy and thanks for the patch, Daniel. It is committed now. ---------- nosy: +orsenthil resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 23:05:59 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Aug 2012 21:05:59 +0000 Subject: [issue15527] Double parens in functions references In-Reply-To: <1343833557.96.0.948912415493.issue15527@psf.upfronthosting.co.za> Message-ID: <1344632759.65.0.667311598784.issue15527@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks Chris. Here's the patch. ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 23:06:40 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Aug 2012 21:06:40 +0000 Subject: [issue15527] Double parens in functions references In-Reply-To: <1343833557.96.0.948912415493.issue15527@psf.upfronthosting.co.za> Message-ID: <1344632800.66.0.14970012465.issue15527@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 23:07:44 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Aug 2012 21:07:44 +0000 Subject: [issue15527] Double parens in functions references In-Reply-To: <1343833557.96.0.948912415493.issue15527@psf.upfronthosting.co.za> Message-ID: <1344632864.34.0.945023619984.issue15527@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file26760/doc_dbl_parens.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 23:17:51 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Aug 2012 21:17:51 +0000 Subject: [issue15239] Abandoned Tools/unicode/mkstringprep.py In-Reply-To: <1341164174.42.0.994750295138.issue15239@psf.upfronthosting.co.za> Message-ID: <1344633471.36.0.616839242678.issue15239@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: To protect themselves from the surprises we need working mkstringprep.py. Martin, what do you say about a patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 23:33:10 2012 From: report at bugs.python.org (Vinay Sajip) Date: Fri, 10 Aug 2012 21:33:10 +0000 Subject: [issue15616] logging.FileHandler not correctly created with PyYaml (unpickling problems?) In-Reply-To: <1344595757.56.0.0377955516485.issue15616@psf.upfronthosting.co.za> Message-ID: <1344634390.27.0.349423910751.issue15616@psf.upfronthosting.co.za> Vinay Sajip added the comment: You've only shown that the YAML loading produces the correct results on 2.6. Logging changed from old-style classes in 2.6 to new-style classes in 2.7. This may be what is causing PyYAML a problem, but AFAICT PyYAML should work with new-style classes. Perhaps you need to invoke it differently for new-style classes? Logging doesn't do anything special related to pickling, except that it takes care not to send objects which can't be pickled across the network (which is not relevant here). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 23:41:32 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Aug 2012 21:41:32 +0000 Subject: [issue15502] Meta path finders and path entry finders are different, but share an ABC In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za> Message-ID: <3Wv0CH08xhzPJ9@mail.python.org> Roundup Robot added the comment: New changeset e7a67f1bf604 by Brett Cannon in branch 'default': Issue #15502: Refactor some code. http://hg.python.org/cpython/rev/e7a67f1bf604 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 23:49:13 2012 From: report at bugs.python.org (=?utf-8?q?Juancarlo_A=C3=B1ez?=) Date: Fri, 10 Aug 2012 21:49:13 +0000 Subject: [issue15620] readline.clear_history() missing in test_readline.py Message-ID: <1344635353.75.0.297337587104.issue15620@psf.upfronthosting.co.za> New submission from Juancarlo A?ez: $ lsb_release -a LSB Version: core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch Distributor ID: Ubuntu Description: Ubuntu 12.04.1 LTS Release: 12.04 Codename: precise $ hg branch 2.7 $ ./python Lib/test/test_readline.py testHistoryUpdates (__main__.TestHistoryManipulation) ... ERROR ====================================================================== ERROR: testHistoryUpdates (__main__.TestHistoryManipulation) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_readline.py", line 16, in testHistoryUpdates readline.clear_history() AttributeError: 'module' object has no attribute 'clear_history' ---------------------------------------------------------------------- Ran 1 test in 0.003s FAILED (errors=1) Traceback (most recent call last): File "Lib/test/test_readline.py", line 43, in test_main() File "Lib/test/test_readline.py", line 40, in test_main run_unittest(TestHistoryManipulation) File "/art/python/cpython/Lib/test/test_support.py", line 1125, in run_unittest _run_suite(suite) File "/art/python/cpython/Lib/test/test_support.py", line 1108, in _run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_readline.py", line 16, in testHistoryUpdates readline.clear_history() AttributeError: 'module' object has no attribute 'clear_history' ---------- components: Tests messages: 167919 nosy: apalala priority: normal severity: normal status: open title: readline.clear_history() missing in test_readline.py type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 10 23:53:27 2012 From: report at bugs.python.org (=?utf-8?q?Juancarlo_A=C3=B1ez?=) Date: Fri, 10 Aug 2012 21:53:27 +0000 Subject: [issue15620] readline.clear_history() missing in test_readline.py In-Reply-To: <1344635353.75.0.297337587104.issue15620@psf.upfronthosting.co.za> Message-ID: <1344635607.22.0.451240874258.issue15620@psf.upfronthosting.co.za> Juancarlo A?ez added the comment: $ dpkg -l | grep readline ii libreadline-dev 6.2-8 GNU readline and history libraries, development files ii libreadline5 5.2-11 GNU readline and history libraries, run-time libraries ii libreadline6 6.2-8 GNU readline and history libraries, run-time libraries ii libreadline6-dev 6.2-8 GNU readline and history libraries, development files ii readline-common 6.2-8 GNU readline and history libraries, common files ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 00:33:21 2012 From: report at bugs.python.org (Glenn Linderman) Date: Fri, 10 Aug 2012 22:33:21 +0000 Subject: [issue15564] cgi.FieldStorage should not call read_multi on files In-Reply-To: <1344245506.28.0.499641288303.issue15564@psf.upfronthosting.co.za> Message-ID: <1344638001.05.0.81254155697.issue15564@psf.upfronthosting.co.za> Glenn Linderman added the comment: So the issue you perceive is that a correctly MIME-typed .mht file has a MIME type of multipart/related -- but that for the purposes of uploading the file, you don't want to treat it as that MIME type, but rather as an opaque data file. Just give it a different MIME type at the time of upload, like application/octet-stream. That is appropriate, if your application wants to treat the data as an opaque data stream. But, you say, none of the browsers support user-specified or user-selectable MIME types, but rather they infer the MIME type from the file extension. So that sounds like a bug in the browsers... but also gives an out... change the name of the file before uploading it. The only bug I see here is your comment that the parsing fails. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 00:45:54 2012 From: report at bugs.python.org (=?utf-8?q?Juancarlo_A=C3=B1ez?=) Date: Fri, 10 Aug 2012 22:45:54 +0000 Subject: [issue15620] readline.clear_history() missing in test_readline.py In-Reply-To: <1344635353.75.0.297337587104.issue15620@psf.upfronthosting.co.za> Message-ID: <1344638754.68.0.0772158889225.issue15620@psf.upfronthosting.co.za> Juancarlo A?ez added the comment: Check if clear_history() is available before calling it. ---------- keywords: +patch Added file: http://bugs.python.org/file26761/readline_clear_history_available.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 00:47:14 2012 From: report at bugs.python.org (=?utf-8?q?Juancarlo_A=C3=B1ez?=) Date: Fri, 10 Aug 2012 22:47:14 +0000 Subject: [issue15620] readline.clear_history() missing in test_readline.py In-Reply-To: <1344635353.75.0.297337587104.issue15620@psf.upfronthosting.co.za> Message-ID: <1344638834.7.0.891494871356.issue15620@psf.upfronthosting.co.za> Changes by Juancarlo A?ez : Removed file: http://bugs.python.org/file26761/readline_clear_history_available.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 00:51:14 2012 From: report at bugs.python.org (=?utf-8?q?Juancarlo_A=C3=B1ez?=) Date: Fri, 10 Aug 2012 22:51:14 +0000 Subject: [issue15620] readline.clear_history() missing in test_readline.py In-Reply-To: <1344635353.75.0.297337587104.issue15620@psf.upfronthosting.co.za> Message-ID: <1344639074.04.0.390806273809.issue15620@psf.upfronthosting.co.za> Juancarlo A?ez added the comment: Check if clear_history() is available before calling it. ---------- Added file: http://bugs.python.org/file26762/readline_clear_history_available.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 00:55:16 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Aug 2012 22:55:16 +0000 Subject: [issue15610] PyImport_ImportModuleEx always fails in 3.3 with "ValueError: level must be >= 0" In-Reply-To: <1344542648.98.0.69001231241.issue15610@psf.upfronthosting.co.za> Message-ID: <3Wv1rM0wlnzPnJ@mail.python.org> Roundup Robot added the comment: New changeset 9804aec74d4a by Brett Cannon in branch 'default': Issue #15610: The PyImport_ImportModuleEx macro now calls http://hg.python.org/cpython/rev/9804aec74d4a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 00:56:43 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 10 Aug 2012 22:56:43 +0000 Subject: [issue15610] PyImport_ImportModuleEx always fails in 3.3 with "ValueError: level must be >= 0" In-Reply-To: <1344542648.98.0.69001231241.issue15610@psf.upfronthosting.co.za> Message-ID: <1344639403.12.0.595336000436.issue15610@psf.upfronthosting.co.za> Brett Cannon added the comment: Hopefully the 3rd-party code using PyImport_ImportModuleEx will work as expected with a 'level' of 0. ---------- assignee: -> brett.cannon resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 01:12:29 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Aug 2012 23:12:29 +0000 Subject: [issue15612] Rewrite StringIO to use the _PyUnicodeWriter API In-Reply-To: <1344565830.56.0.384034899089.issue15612@psf.upfronthosting.co.za> Message-ID: <1344640349.15.0.138189133173.issue15612@psf.upfronthosting.co.za> STINNER Victor added the comment: > I would like to know why that is the case. > If PyUnicode_Join is not optimal, then perhaps we should > better optimize it. I don't know. _PyUnicodeWriter overallocates its buffer (+25%). It may reduce the number of realloc(), and so the number of times that the buffer is copied. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 01:20:23 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 10 Aug 2012 23:20:23 +0000 Subject: [issue15612] Rewrite StringIO to use the _PyUnicodeWriter API In-Reply-To: <1344640349.15.0.138189133173.issue15612@psf.upfronthosting.co.za> Message-ID: <1344640663.3412.14.camel@localhost.localdomain> Antoine Pitrou added the comment: > > I would like to know why that is the case. > > If PyUnicode_Join is not optimal, then perhaps we should > > better optimize it. > > I don't know. _PyUnicodeWriter overallocates its buffer (+25%). It may > reduce the number of realloc(), and so the number of times that the > buffer is copied. But PyUnicode_Join doesn't realloc() anything, since it creates a buffer of exactly the right size. So this can't be the answer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 02:19:22 2012 From: report at bugs.python.org (zipher) Date: Sat, 11 Aug 2012 00:19:22 +0000 Subject: [issue15621] UnboundLocalError on simple in-place assignment of an inner scope Message-ID: <1344644361.49.0.381165931673.issue15621@psf.upfronthosting.co.za> New submission from zipher: >>> num = 1 >>> def t1(): print num >>> t1() 1 >>> def t2(): ... num+=1 ... print num >>> t2() UnboundLocalError: local variable 'num' referenced before assignment It seems num is bound in t1, but not t2, even though they are the same scope. Am I missing something? ---------- components: Interpreter Core messages: 167928 nosy: Mark.Janssen priority: normal severity: normal status: open title: UnboundLocalError on simple in-place assignment of an inner scope versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 03:01:09 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 11 Aug 2012 01:01:09 +0000 Subject: [issue15621] UnboundLocalError on simple in-place assignment of an inner scope In-Reply-To: <1344644361.49.0.381165931673.issue15621@psf.upfronthosting.co.za> Message-ID: <1344646869.54.0.714530705146.issue15621@psf.upfronthosting.co.za> R. David Murray added the comment: In t2, you assign to num. That makes it local. In t1, you don't, so num is picked up from the global scope. ---------- nosy: +r.david.murray resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 04:16:47 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Sat, 11 Aug 2012 02:16:47 +0000 Subject: [issue15596] pickle: Faster serialization of Unicode strings In-Reply-To: <1344465522.38.0.375715302831.issue15596@psf.upfronthosting.co.za> Message-ID: <1344651407.85.0.181932059916.issue15596@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 06:16:00 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 11 Aug 2012 04:16:00 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1344658560.61.0.165773551095.issue15573@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I find Stefan's proposed equality confusing. Why is it based on memcmp? Either it compares memory (i.e. internal representations), or it compares abstract values. If it compares abstract values, then it shouldn't be a requirement that the format strings are equal in any sense. Instead, the resulting values should be equal. So I propose this definition: v == w iff v.shape() == w.shape() and v.tolist() == w.tolist() if either operation fails with an exception, the objects are not equal Of course, the implementation doesn't need to literally call tolist; instead, behaving as-if it had been called is fine. However, as time is running out, I would actually propose this to be the implementation in 3.3. In addition, I would propose to support the 'u' and 'w' codes in tolist, to resolve what Victor says the actual issue is. I'm -1 on a definition that involves equivalence of format strings. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 06:18:06 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 11 Aug 2012 04:18:06 +0000 Subject: [issue15239] Abandoned Tools/unicode/mkstringprep.py In-Reply-To: <1341164174.42.0.994750295138.issue15239@psf.upfronthosting.co.za> Message-ID: <1344658686.19.0.603952278422.issue15239@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I don't consider it relevant for 3.3; I may have time to review only post-3.3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 06:26:51 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 11 Aug 2012 04:26:51 +0000 Subject: [issue15424] __sizeof__ of array should include size of items In-Reply-To: <1342974161.65.0.374402048104.issue15424@psf.upfronthosting.co.za> Message-ID: <3Wv9Bx6Kh6zPpn@mail.python.org> Roundup Robot added the comment: New changeset 91382d4e2dfb by Meador Inge in branch '2.7': Issue #15424: Add a __sizeof__ implementation for array objects. http://hg.python.org/cpython/rev/91382d4e2dfb New changeset 45ef9bc8739f by Meador Inge in branch '3.2': Issue #15424: Add a __sizeof__ implementation for array objects. http://hg.python.org/cpython/rev/45ef9bc8739f New changeset 7d82a60850fd by Meador Inge in branch 'default': Issue #15424: Add a __sizeof__ implementation for array objects. http://hg.python.org/cpython/rev/7d82a60850fd ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 06:28:44 2012 From: report at bugs.python.org (Stefan Behnel) Date: Sat, 11 Aug 2012 04:28:44 +0000 Subject: [issue15576] importlib: ExtensionFileLoader not used to load packages from __init__.so files In-Reply-To: <1344364550.12.0.263881849199.issue15576@psf.upfronthosting.co.za> Message-ID: <1344659324.28.0.0906969535366.issue15576@psf.upfronthosting.co.za> Stefan Behnel added the comment: I understand that this is not trivial to test as part of the regression test suite. However, when I try it now I get this: Traceback (most recent call last): File "", line 1, in File "__init__.py", line 8, in init my_test_package (my_test_package/__init__.c:1032) SystemError: Parent module 'my_test_package' not loaded, cannot perform relative import This is running Cython's "initial_file_path" test, which is meant to check that we provide a fake __path__ for the package module for the init function (as long as issue13429 isn't resolved). The test code is here, failing in line 21 (each section is a separate file): https://github.com/cython/cython/blob/master/tests/run/initial_file_path.srctree I'm running the test like this: python3 runtests.py --no-cpp --no-pyregr --no-unit --debug -vv initial_file_path I also let it print sys.modules and the package isn't registered there yet at the time of the import. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 06:31:26 2012 From: report at bugs.python.org (Meador Inge) Date: Sat, 11 Aug 2012 04:31:26 +0000 Subject: [issue15424] __sizeof__ of array should include size of items In-Reply-To: <1342974161.65.0.374402048104.issue15424@psf.upfronthosting.co.za> Message-ID: <1344659486.74.0.414072003481.issue15424@psf.upfronthosting.co.za> Meador Inge added the comment: Thanks for the patches! (I fixed a minor nit on the 2.7 patch where 'array_sizeof' was defined inside #ifdef Py_USING_UNICODE). ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 08:32:20 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 11 Aug 2012 06:32:20 +0000 Subject: [issue15527] Double parens in functions references In-Reply-To: <1343833557.96.0.948912415493.issue15527@psf.upfronthosting.co.za> Message-ID: <1344666740.22.0.0186868999048.issue15527@psf.upfronthosting.co.za> Georg Brandl added the comment: Is anyone even reading my messages...? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 08:33:41 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 11 Aug 2012 06:33:41 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1317341390.65.0.255779328054.issue13072@psf.upfronthosting.co.za> Message-ID: <1344666821.88.0.985562829878.issue13072@psf.upfronthosting.co.za> Georg Brandl added the comment: Deferring. ---------- priority: release blocker -> deferred blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 09:48:53 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 11 Aug 2012 07:48:53 +0000 Subject: [issue15622] memoryview.to_list() incorrect for 'c' format Message-ID: <1344671333.76.0.693259168971.issue15622@psf.upfronthosting.co.za> New submission from Martin v. L?wis: PEP 3118 specifies that the 'c'format denotes UCS-1 characters, yet .tolist() converts the memoryview into a list of bytes objects. This is incorrect; it ought to be a list of string objects (as it should for 'u' and 'w' codes). The same holds for item access. ---------- messages: 167937 nosy: loewis, skrah priority: normal severity: normal status: open title: memoryview.to_list() incorrect for 'c' format versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 09:54:11 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 11 Aug 2012 07:54:11 +0000 Subject: [issue15622] memoryview.to_list() incorrect for 'c' format In-Reply-To: <1344671333.76.0.693259168971.issue15622@psf.upfronthosting.co.za> Message-ID: <1344671651.15.0.645751639756.issue15622@psf.upfronthosting.co.za> Martin v. L?wis added the comment: To reproduce: >>> memoryview(array.array('B',b'foo')).cast('c').tolist() [b'f', b'o', b'o'] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 09:54:37 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Aug 2012 07:54:37 +0000 Subject: [issue15527] Double parens in functions references In-Reply-To: <1343833557.96.0.948912415493.issue15527@psf.upfronthosting.co.za> Message-ID: <1344671677.09.0.245959325266.issue15527@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Georg, I see that :meth: with arguments works in the form :meth:`name(args) `. I believe that the hyperlinks are helpful and it was designed that way. Replacing :meth:/:func:/:c:func: for names with arguments on double backquotes can be done almost automatically. Here's another patch (I like it less). ---------- Added file: http://bugs.python.org/file26763/doc_dbl_parens_drop_markup.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 10:04:04 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 11 Aug 2012 08:04:04 +0000 Subject: [issue15622] memoryview.to_list() incorrect for 'c' format In-Reply-To: <1344671333.76.0.693259168971.issue15622@psf.upfronthosting.co.za> Message-ID: <1344672244.05.0.944554110367.issue15622@psf.upfronthosting.co.za> Stefan Krah added the comment: You have rejected the PEP-3118 'u' and 'w' specifiers here: http://mail.python.org/pipermail/python-dev/2012-March/117390.html Otherwise, memoryview follows the existing struct module syntax: http://docs.python.org/dev/library/struct.html#format-characters I hope it did not escape you that _testbuffer.c *uses* the struct module to verify the correctness of memoryview. ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 10:06:01 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 11 Aug 2012 08:06:01 +0000 Subject: [issue15622] struct module 'c' specifier does not follow PEP-3118 In-Reply-To: <1344671333.76.0.693259168971.issue15622@psf.upfronthosting.co.za> Message-ID: <1344672361.66.0.701189345109.issue15622@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- title: memoryview.to_list() incorrect for 'c' format -> struct module 'c' specifier does not follow PEP-3118 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 10:59:32 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 11 Aug 2012 08:59:32 +0000 Subject: [issue15620] readline.clear_history() missing in test_readline.py In-Reply-To: <1344635353.75.0.297337587104.issue15620@psf.upfronthosting.co.za> Message-ID: <3WvHFb18VLzPjl@mail.python.org> Roundup Robot added the comment: New changeset 961a15aff2a6 by Georg Brandl in branch '3.2': Closes #15620: check for presence of readline.clear_history(), which is apparently missing on some readline versions, before calling it in the test. http://hg.python.org/cpython/rev/961a15aff2a6 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 11:07:51 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 11 Aug 2012 09:07:51 +0000 Subject: [issue15620] readline.clear_history() missing in test_readline.py In-Reply-To: <1344635353.75.0.297337587104.issue15620@psf.upfronthosting.co.za> Message-ID: <3WvHRB4Mk5zPmY@mail.python.org> Roundup Robot added the comment: New changeset dda08ec9fbd5 by Georg Brandl in branch '2.7': Graft a89d654adaa2 from 3.2 branch. Fixes #15620. http://hg.python.org/cpython/rev/dda08ec9fbd5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 11:09:36 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 11 Aug 2012 09:09:36 +0000 Subject: [issue15239] Abandoned Tools/unicode/mkstringprep.py In-Reply-To: <1341164174.42.0.994750295138.issue15239@psf.upfronthosting.co.za> Message-ID: <1344676176.58.0.24276145693.issue15239@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- versions: +Python 3.4 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 11:18:16 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 11 Aug 2012 09:18:16 +0000 Subject: [issue15622] struct module 'c' specifier does not follow PEP-3118 In-Reply-To: <1344671333.76.0.693259168971.issue15622@psf.upfronthosting.co.za> Message-ID: <1344676696.4.0.195802686762.issue15622@psf.upfronthosting.co.za> Martin v. L?wis added the comment: No, I haven't rejected the format codes. What I did ask to revert is that 'u' in the array module denotes Py_UCS4, I requested that it should continue to be compatible with 3.2. I didn't have an opinion on memoryview at all then. It's unfortunate that PEP 3118 deviates from the struct module, however, memoryview is based onthe buffer interface,and its formatcodes ought to conform to the PEP, not to the struct module (IMO). It's easy to see that it *doesn't* follow the struct syntax, as it is possjible to create memoryview objects with other format codes in 3.3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 11:32:03 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 11 Aug 2012 09:32:03 +0000 Subject: [issue15622] memoryview.to_list() incorrect for 'c' format In-Reply-To: <1344671333.76.0.693259168971.issue15622@psf.upfronthosting.co.za> Message-ID: <1344677523.45.0.175496438254.issue15622@psf.upfronthosting.co.za> Martin v. L?wis added the comment: That the struct module hasn't been updated to support the PEP 3118 is already reported as issue 3132, please don't confuse the issues. This issue is about memoryview. One solution would be to revert the PEPs decision that 'c' is UCS-1. ---------- title: struct module 'c' specifier does not follow PEP-3118 -> memoryview.to_list() incorrect for 'c' format _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 11:39:31 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 11 Aug 2012 09:39:31 +0000 Subject: [issue15622] memoryview.to_list() incorrect for 'c' format In-Reply-To: <1344671333.76.0.693259168971.issue15622@psf.upfronthosting.co.za> Message-ID: <1344677971.39.0.932440468563.issue15622@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I don't know which behaviour is more desirable, but I would consider PEP 3118 a historical document more than a normative spec. Especially when it comes to struct format codes. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 11:42:46 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 11 Aug 2012 09:42:46 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344658560.61.0.165773551095.issue15573@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: Stefan's proposed definition is correct. Shapes define array types, format strings define entry types, then the actual memory contents define the value. It's not "Stefan's definition of equivalence", it's what a statically typed array *means*. The 3.2 way is completely broken, as it considers arrays containing completely different data as equal if the memory layout happens to be the same by coincidence. 3.3 is currently also broken, as it considers arrays that *do* contain the same values to be different. Stefan's patch fixes that by checking the shape and format first, and *then* checking the value. It's exactly the same as doing an instance check in an __eq__ method. The requirement for a canonical format is for sanity's sake: the general equivalence classes are too hard to figure out. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 11:43:45 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 11 Aug 2012 09:43:45 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1317341390.65.0.255779328054.issue13072@psf.upfronthosting.co.za> Message-ID: <1344678225.39.0.732042494412.issue13072@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Is there anything that still needs to be done on this issue? ISTM that the code is correct as it stands (i.e. Getting a buffer now only uses valid format codes) ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 11:44:07 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 11 Aug 2012 09:44:07 +0000 Subject: [issue15622] struct module 'c' specifier does not follow PEP-3118 In-Reply-To: <1344676696.4.0.195802686762.issue15622@psf.upfronthosting.co.za> Message-ID: <20120811094407.GA30058@sleipnir.bytereef.org> Stefan Krah added the comment: Martin v. L??wis wrote: > It's unfortunate that PEP 3118 deviates from the struct module, however, > memoryview is based onthe buffer interface,and its formatcodes ought to > conform to the PEP, not to the struct module (IMO). The struct module itself should conform to PEP-3118, see #3132. I think the struct module should be updated first. The proliferation of subtly different format codes is not manageable. For example, if you use NumPy, there are already differences between NumPy syntax and struct syntax. Also, one should always be able to unpack the tobytes() representation using the struct module and get the same result as from flatten(tolist()). > It's easy to see that it *doesn't* follow the struct syntax, as it is > possjible to create memoryview objects with other format codes in 3.3. memoryview has *always* allowed arbitrary format strings during construction. In 3.3, it keeps this property for backwards compatibility. It does follow struct syntax whenever it *uses* one of the format codes, like in tolist(). ---------- title: memoryview.to_list() incorrect for 'c' format -> struct module 'c' specifier does not follow PEP-3118 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 12:00:19 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 11 Aug 2012 10:00:19 +0000 Subject: [issue15622] struct module 'c' specifier does not follow PEP-3118 In-Reply-To: <1344671333.76.0.693259168971.issue15622@psf.upfronthosting.co.za> Message-ID: <1344679219.84.0.614471812059.issue15622@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 12:02:39 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 11 Aug 2012 10:02:39 +0000 Subject: [issue15239] Abandoned Tools/unicode/mkstringprep.py In-Reply-To: <1341164174.42.0.994750295138.issue15239@psf.upfronthosting.co.za> Message-ID: <1344679359.52.0.206915977533.issue15239@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 12:07:11 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 11 Aug 2012 10:07:11 +0000 Subject: [issue15622] memoryview.to_list() incorrect for 'c' format In-Reply-To: <1344677523.45.0.175496438254.issue15622@psf.upfronthosting.co.za> Message-ID: <20120811100657.GA30299@sleipnir.bytereef.org> Stefan Krah added the comment: Martin v. L??wis wrote: > That the struct module hasn't been updated to support the PEP 3118 is > already reported as issue 3132, please don't confuse the issues. > This issue is about memoryview. No, it isn't. It was always planned to use struct to do the unpacking for memoryview, see msg71338. On a meta note, I'd appreciate if you were less liberal with words like "confusing", especially if you are just beginning to work on an issue that other people have already spent a lot of time on. ---------- title: struct module 'c' specifier does not follow PEP-3118 -> memoryview.to_list() incorrect for 'c' format _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 12:08:27 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 11 Aug 2012 10:08:27 +0000 Subject: [issue15622] struct module 'c' specifier does not follow PEP-3118 In-Reply-To: <1344671333.76.0.693259168971.issue15622@psf.upfronthosting.co.za> Message-ID: <1344679707.12.0.420422766252.issue15622@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- dependencies: +implement PEP 3118 struct changes title: memoryview.to_list() incorrect for 'c' format -> struct module 'c' specifier does not follow PEP-3118 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 12:10:56 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 11 Aug 2012 10:10:56 +0000 Subject: [issue15612] Rewrite StringIO to use the _PyUnicodeWriter API In-Reply-To: <1344565830.56.0.384034899089.issue15612@psf.upfronthosting.co.za> Message-ID: <1344679856.22.0.182628916359.issue15612@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Victor, your benchmark is buggy (it writes one character at a time). You should apply the following patch: $ diff -u bench_stringio_orig.py bench_stringio.py --- bench_stringio_orig.py 2012-08-11 12:02:16.528321958 +0200 +++ bench_stringio.py 2012-08-11 12:05:53.939536902 +0200 @@ -41,8 +41,8 @@ ('bmp', '\u20ac' * k + '\n'), ('non-bmp', '\U0010ffff' * k + '\n'), ): - bench.bench_func('writer long lines %s' % charset, writer, n // k, text) - bench.bench_func('writer-reader long lines %s' % charset, writer_reader, n // k, text) + bench.bench_func('writer long lines %s' % charset, writer, n, [text]) + bench.bench_func('writer-reader long lines %s' % charset, writer_reader, n, [text]) for charset, text in ( ('ascii', 'a' * (n // 10) + '\n'), @@ -50,8 +50,8 @@ ('bmp', '\u20ac' * (n // 10) + '\n'), ('non-bmp', '\U0010ffff' * (n // 10) + '\n'), ): - bench.bench_func('writer very long lines %s' % charset, writer, 10, text) - bench.bench_func('writer-reader very long lines %s' % charset, writer_reader, 10, text) + bench.bench_func('writer very long lines %s' % charset, writer, 100, [text]) + bench.bench_func('writer-reader very long lines %s' % charset, writer_reader, 100, [text]) data = 'abc\n' * n bench.bench_func('reader ascii', reader, data) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 12:15:40 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 11 Aug 2012 10:15:40 +0000 Subject: [issue3132] implement PEP 3118 struct changes In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za> Message-ID: <1344680140.25.0.565173871221.issue3132@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 12:35:20 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 11 Aug 2012 10:35:20 +0000 Subject: [issue15622] struct module 'c' specifier does not follow PEP-3118 In-Reply-To: <1344671333.76.0.693259168971.issue15622@psf.upfronthosting.co.za> Message-ID: <1344681320.77.0.849753810099.issue15622@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Do you agree or not agree that memoryview.tolist should return a list of str objects for the c code? If you agree, can you please change the title back? If you disagree, please explain why, change the title back, and close the issue as rejected. If you agree, but think that struct should be changed first, create a new issue for the struct change, make that a dependency of this issue, and change the title back. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 14:24:19 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 11 Aug 2012 12:24:19 +0000 Subject: [issue15528] Better support for finalization with weakrefs In-Reply-To: <1343837927.06.0.561023898829.issue15528@psf.upfronthosting.co.za> Message-ID: <1344687859.41.0.628876282031.issue15528@psf.upfronthosting.co.za> Antoine Pitrou added the comment: In the latest patch, what are "broken" and "priority" for? Also, I would question why atexit is false by default. I would find it personally less surprising to be true. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 15:03:48 2012 From: report at bugs.python.org (patrick vrijlandt) Date: Sat, 11 Aug 2012 13:03:48 +0000 Subject: [issue15564] cgi.FieldStorage should not call read_multi on files In-Reply-To: <1344245506.28.0.499641288303.issue15564@psf.upfronthosting.co.za> Message-ID: <1344690228.12.0.243053985158.issue15564@psf.upfronthosting.co.za> patrick vrijlandt added the comment: I would not know how to set the MIME-type of a file during upload. This is apparently set by the browser based on the filename (extension). Even (or: especially) if this is a bug in all the current browsers, python should provide the tools to adapt to this situation. I could perhaps request the whole form to be "application/octet-stream", but the current "multipart/form-data" is appropriate for a form. You are right about renaming. The innocent test file "test2.txt" can be uploaded, but the same file renamed to "test2.mht" causes an exception. Below is a dump of the posted data (using Chrome in this case); attached a script (requiring bottle.py - www.bottlepy.org or PyPI) that demonstrates the problem. There is no doubt that parsing fails; an exception cannot be the result of successful parsing. The input may be wrong, but python should offer the flexibility to handle wrong input. Instead, are you sure it is appropriate to *automatically* dissect a file? It should be fairly easy to handle for the scripter if he really wants to dig deeper. Headers Origin: http://localhost:10080 Referer: http://localhost:10080/url-get Content-Length: 349 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cache-Control: max-age=0 Connection: keep-alive Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 6.0) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.75 Safari/537.1 Host: localhost:10080 Accept-Encoding: gzip,deflate,sdch Accept-Language: nl-NL,nl;q=0.8,en-US;q=0.6,en;q=0.4,en-GB;q=0.2 Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryBsBVBYDTxou89uBj Body ------WebKitFormBoundaryBsBVBYDTxou89uBj Content-Disposition: form-data; name="data"; filename="test2.mht" Content-Type: multipart/related # dit is een test Dit is een regel Dit is het einde. # ------WebKitFormBoundaryBsBVBYDTxou89uBj Content-Disposition: form-data; name="value" abc123 ------WebKitFormBoundaryBsBVBYDTxou89uBj-- ---------- Added file: http://bugs.python.org/file26764/cgibug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 15:38:30 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 11 Aug 2012 13:38:30 +0000 Subject: [issue15444] Incorrectly written contributor's names In-Reply-To: <1343161512.09.0.0619646494936.issue15444@psf.upfronthosting.co.za> Message-ID: <1344692310.14.0.0360382868446.issue15444@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The patch looks ok to me so, unless someone is opposed to using utf-8 in the doc files, I think it can be committed in 3.x. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 16:00:27 2012 From: report at bugs.python.org (Brett Cannon) Date: Sat, 11 Aug 2012 14:00:27 +0000 Subject: [issue15576] importlib: ExtensionFileLoader not used to load packages from __init__.so files In-Reply-To: <1344364550.12.0.263881849199.issue15576@psf.upfronthosting.co.za> Message-ID: <1344693627.61.0.280543145203.issue15576@psf.upfronthosting.co.za> Brett Cannon added the comment: So that test case is hard for me to follow since I don't know what a .srctree file is and the file seems to have some magical comments in it. If my assumptions are correct you are generating a C file that does a relative import in the extension module's init function? Has that actually worked in the past? The error you are seeing suggests that the module is not being inserted into sys.modules before executing the body which I have no control over since that's the purview of imp.load_dynamic(). If you skip the relative imports does the import work otherwise? ---------- resolution: fixed -> stage: committed/rejected -> test needed status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 16:04:19 2012 From: report at bugs.python.org (Brett Cannon) Date: Sat, 11 Aug 2012 14:04:19 +0000 Subject: [issue15576] importlib: ExtensionFileLoader not used to load packages from __init__.so files In-Reply-To: <1344364550.12.0.263881849199.issue15576@psf.upfronthosting.co.za> Message-ID: <1344693859.56.0.69628248845.issue15576@psf.upfronthosting.co.za> Brett Cannon added the comment: The reason I ask this is that if I simply move e.g. audioop.so to audioop/__init__.so everything works fine in terms of being able to import that module as a package. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 16:20:32 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 11 Aug 2012 14:20:32 +0000 Subject: [issue15622] struct module 'c' specifier does not follow PEP-3118 In-Reply-To: <1344671333.76.0.693259168971.issue15622@psf.upfronthosting.co.za> Message-ID: <1344694832.07.0.790215617024.issue15622@psf.upfronthosting.co.za> Nick Coghlan added the comment: Whatever the struct module produces for a format code is the same thing that memoryview.to_list() should produce. PEP 3118 contains way too many errors (as has been found out the hard way) to be considered a normative document. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 16:29:06 2012 From: report at bugs.python.org (Jordi Puigsegur) Date: Sat, 11 Aug 2012 14:29:06 +0000 Subject: [issue15616] logging.FileHandler not correctly created with PyYaml (unpickling problems?) In-Reply-To: <1344595757.56.0.0377955516485.issue15616@psf.upfronthosting.co.za> Message-ID: <1344695346.51.0.674730718914.issue15616@psf.upfronthosting.co.za> Jordi Puigsegur added the comment: It looks like the change from old to new style classes in python could have triggered this issue. I've created an issue in PyYaml (http://pyyaml.org/ticket/283). Thanks again! ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 16:34:34 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 11 Aug 2012 14:34:34 +0000 Subject: [issue15576] importlib: ExtensionFileLoader not used to load packages from __init__.so files In-Reply-To: <1344364550.12.0.263881849199.issue15576@psf.upfronthosting.co.za> Message-ID: <1344695674.18.0.266629655594.issue15576@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 16:35:28 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 11 Aug 2012 14:35:28 +0000 Subject: [issue15600] expose the finder details used by the FileFinder path hook In-Reply-To: <1344483800.66.0.152640034936.issue15600@psf.upfronthosting.co.za> Message-ID: <1344695728.03.0.0864337627837.issue15600@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 16:37:40 2012 From: report at bugs.python.org (Stefan Behnel) Date: Sat, 11 Aug 2012 14:37:40 +0000 Subject: [issue15576] importlib: ExtensionFileLoader not used to load packages from __init__.so files In-Reply-To: <1344364550.12.0.263881849199.issue15576@psf.upfronthosting.co.za> Message-ID: <1344695860.13.0.477047130187.issue15576@psf.upfronthosting.co.za> Stefan Behnel added the comment: Hmm, yes, sounds more like a separate issue than something to add to this ticket. It worked before (starting with Py2.5, which was the first Python version to support relative imports) and only stopped working in 3.3 now. The .srctree test file basically just unfolds into a file system hierarchy with each file named as in the preceding "magical" comment. The commands in the lines before the first comment line are then executed for the test (usually: build module with distutils, import it, do something with it). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 16:40:31 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 11 Aug 2012 14:40:31 +0000 Subject: [issue15622] struct module 'c' specifier does not follow PEP-3118 In-Reply-To: <1344671333.76.0.693259168971.issue15622@psf.upfronthosting.co.za> Message-ID: <1344696031.87.0.77808995805.issue15622@psf.upfronthosting.co.za> Nick Coghlan added the comment: The struct module documentation takes precedence over PEP 3118 when it comes to pre-existing format codes, as changing struct is not feasible due to backwards compatibility concerns, and we don't want two conflicting notations for binary format descriptions. PEP 3118 was intended only to define *additional* format characters, which may or may not yet be understood by the struct module. As 'c' is defined by the struct module as returning a bytes object of length one, this is the same interpretation used by memoryview. Thus the current behaviour of both memoryview and struct are considered correct, while it is PEP 3118 that is incorrect in this case: the 'c' entry should not have been in the table, as 'c' was already defined at least as long ago as 1.5.2 (returning an 8-bit string, which then became a bytes object in 3.x). The PEP was also written in a 2.x context (note the mention of "2.5" above the table of new format codes), where the idea of providing a separate code that implicitly performed x.decode("latin-1") to produce a unicode object instead of an 8-bit string object wouldn't necessarily come up. ---------- dependencies: -implement PEP 3118 struct changes resolution: -> invalid stage: -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 16:48:22 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Aug 2012 14:48:22 +0000 Subject: [issue15444] Incorrectly written contributor's names In-Reply-To: <1343161512.09.0.0619646494936.issue15444@psf.upfronthosting.co.za> Message-ID: <1344696502.71.0.736540816983.issue15444@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Non-ascii characters already used in a lot (43-50) of doc files. LC_ALL=C find Doc/ -type f -name '*.rst' -exec egrep --color "$(printf '[\x80-\xFF]+')" '{}' + All touched files already contains non-ascii characters (and Misc/HISTORY contains invalid UTF-8 sequence). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 16:56:59 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 11 Aug 2012 14:56:59 +0000 Subject: [issue3132] implement PEP 3118 struct changes In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za> Message-ID: <1344697018.99.0.234608946065.issue3132@psf.upfronthosting.co.za> Nick Coghlan added the comment: Following up here after rejecting #15622 as invalid The "unicode" codes in PEP 3118 need to be seriously rethought before any related changes are made in the struct module. 1. The 'c' and 's' codes are currently used for raw bytes data (represented as bytes objects at the Python layer). This means the 'c' code cannot be used as described in PEP 3118 in a world with strict binary/text separation. 2. Any format codes for UCS1, UCS2 and UCS4 are more usefully modelled on 's' than they are on 'c' (so that repeat counts create longer strings rather than lists of strings that each contain a single code point) 3. Given some of the other proposals in PEP 3118, it seems more useful to define an embedded text format as "S{}". UCS1 would then be "S{latin-1}", UCS2 would be approximated as "S{utf-16}" and UCS4 would be "S{utf-32}" and arbitrary encodings would also be supported. struct packing would implicitly encode from text to bytes while unpacking would implicitly decode bytes to text. As with 's' a length mismatch in the encoded form would mean an error. ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 16:57:20 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 11 Aug 2012 14:57:20 +0000 Subject: [issue15444] Incorrectly written contributor's names In-Reply-To: <1343161512.09.0.0619646494936.issue15444@psf.upfronthosting.co.za> Message-ID: <3WvRBQ6zmWzPpf@mail.python.org> Roundup Robot added the comment: New changeset 3654c711019a by Antoine Pitrou in branch '3.2': Issue #15444: Use proper spelling for non-ASCII contributor names. http://hg.python.org/cpython/rev/3654c711019a New changeset 867de88b69f0 by Antoine Pitrou in branch 'default': Issue #15444: Use proper spelling for non-ASCII contributor names. http://hg.python.org/cpython/rev/867de88b69f0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 16:59:00 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 11 Aug 2012 14:59:00 +0000 Subject: [issue15444] Incorrectly written contributor's names In-Reply-To: <1343161512.09.0.0619646494936.issue15444@psf.upfronthosting.co.za> Message-ID: <1344697140.77.0.806820987318.issue15444@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, then I've committed the patch. Closing the issue now, thank you. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 17:01:32 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 11 Aug 2012 15:01:32 +0000 Subject: [issue15615] More tests for JSON decoder to test Exceptions In-Reply-To: <1344593566.55.0.653447713109.issue15615@psf.upfronthosting.co.za> Message-ID: <1344697292.19.0.259483203754.issue15615@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Hi and thank you. The patch looks fine to me. Could you sign a contributor's agreement: http://www.python.org/psf/contrib/ ? ---------- nosy: +ezio.melotti, pitrou versions: +Python 2.7, Python 3.2, Python 3.3 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 17:02:05 2012 From: report at bugs.python.org (Stefan Behnel) Date: Sat, 11 Aug 2012 15:02:05 +0000 Subject: [issue15623] Init time relative imports no longer work from __init__.so modules Message-ID: <1344697325.25.0.880049566038.issue15623@psf.upfronthosting.co.za> New submission from Stefan Behnel: Since CPython 2.5, relative imports could be used from __init__.so package modules. This stopped working in CPython 3.3. This is a follow-up ticket to issue15576. This feature is exercised by Cython's initial_file_path test, which now gives this result: Traceback (most recent call last): File "", line 1, in File "__init__.py", line 8, in init my_test_package (my_test_package/__init__.c:1032) SystemError: Parent module 'my_test_package' not loaded, cannot perform relative import It is meant to check that Cython provides a fake __path__ for the package module for the init function (as long as issue13429 isn't resolved). With that, relative imports worked before. The test code is here, failing in line 21 (each section is a separate file), when it tries to do a relative import at the module level, i.e. at module init time. https://github.com/cython/cython/blob/master/tests/run/initial_file_path.srctree I'm running the test like this: python3 runtests.py --no-cpp --no-pyregr --no-unit --debug -vv initial_file_path I also tried printing sys.modules and the package really isn't registered there yet at the time of the import. ---------- components: Interpreter Core messages: 167967 nosy: scoder priority: normal severity: normal status: open title: Init time relative imports no longer work from __init__.so modules type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 17:02:43 2012 From: report at bugs.python.org (Stefan Behnel) Date: Sat, 11 Aug 2012 15:02:43 +0000 Subject: [issue15576] importlib: ExtensionFileLoader not used to load packages from __init__.so files In-Reply-To: <1344364550.12.0.263881849199.issue15576@psf.upfronthosting.co.za> Message-ID: <1344697363.82.0.810645512766.issue15576@psf.upfronthosting.co.za> Stefan Behnel added the comment: I've created issue15623, so that we can keep this one as fixed. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 17:03:26 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 11 Aug 2012 15:03:26 +0000 Subject: [issue15622] struct module 'c' specifier does not follow PEP-3118 In-Reply-To: <1344671333.76.0.693259168971.issue15622@psf.upfronthosting.co.za> Message-ID: <1344697406.72.0.406247543812.issue15622@psf.upfronthosting.co.za> Nick Coghlan added the comment: However, based on this issue, I have added some comments to #3132 (I think PEP 3118's simplistic approach to embedded text data is broken and a bad idea) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 17:03:45 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 11 Aug 2012 15:03:45 +0000 Subject: [issue15622] struct module 'c' specifier does not follow PEP-3118 In-Reply-To: <1344671333.76.0.693259168971.issue15622@psf.upfronthosting.co.za> Message-ID: <1344697425.33.0.976646886055.issue15622@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 17:04:14 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 11 Aug 2012 15:04:14 +0000 Subject: [issue15623] Init time relative imports no longer work from __init__.so modules In-Reply-To: <1344697325.25.0.880049566038.issue15623@psf.upfronthosting.co.za> Message-ID: <1344697454.16.0.847951009535.issue15623@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 17:06:19 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 11 Aug 2012 15:06:19 +0000 Subject: [issue15622] struct module 'c' specifier does not follow PEP-3118 In-Reply-To: <1344671333.76.0.693259168971.issue15622@psf.upfronthosting.co.za> Message-ID: <1344697579.85.0.71153356711.issue15622@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > Status was still open. Was that a tracker bug? ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 17:09:37 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 11 Aug 2012 15:09:37 +0000 Subject: [issue15617] FAIL: test_create_connection (test.test_socket.NetworkConnectionNoServer) In-Reply-To: <1344603652.0.0.278766609424.issue15617@psf.upfronthosting.co.za> Message-ID: <1344697777.29.0.605890326383.issue15617@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > I wonder how other systems respond to [...] > if all interfaces except for lo are down On Mageia Linux 1: >>> socket.getaddrinfo('localhost', 80, 0, socket.SOCK_STREAM, 0, socket.AI_ADDRCONFIG) Traceback (most recent call last): File "", line 1, in socket.gaierror: [Errno -5] No address associated with hostname ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 17:11:39 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 11 Aug 2012 15:11:39 +0000 Subject: [issue15599] test_circular_imports() of test_threaded_import fails on FreeBSD 9.0 In-Reply-To: <1344473974.14.0.584788696764.issue15599@psf.upfronthosting.co.za> Message-ID: <1344697899.47.0.329851760887.issue15599@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > No luck there: The tests pass unmodified (100 times with the -F option). You could try "-F -j16" or something similar. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 17:21:46 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 11 Aug 2012 15:21:46 +0000 Subject: [issue15622] struct module 'c' specifier does not follow PEP-3118 In-Reply-To: <1344671333.76.0.693259168971.issue15622@psf.upfronthosting.co.za> Message-ID: <1344698506.8.0.791863557327.issue15622@psf.upfronthosting.co.za> Nick Coghlan added the comment: Pretty sure it was just an error on my part. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 17:31:19 2012 From: report at bugs.python.org (STINNER Victor) Date: Sat, 11 Aug 2012 15:31:19 +0000 Subject: [issue15612] Rewrite StringIO to use the _PyUnicodeWriter API In-Reply-To: <1344565830.56.0.384034899089.issue15612@psf.upfronthosting.co.za> Message-ID: <1344699079.65.0.688214286935.issue15612@psf.upfronthosting.co.za> STINNER Victor added the comment: > Victor, your benchmark is buggy (it writes one character at a time). Oh, it's not what I wanted to test. I attach a new benchmark. Here are the results. PyAccu looks much more appropriate than _PyUnicodeWriter, because it is always faster, except to write 100.000 very long lines. Common platform: CPU model: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz CFLAGS: -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes Bits: int=32, long=64, long long=64, pointer=64 Python unicode implementation: PEP 393 Platform: Linux-3.4.4-4.fc16.x86_64-x86_64-with-fedora-16-Verne Platform of campaign pyaccu: SCM: hg revision=9804aec74d4a tag=tip branch=default date="2012-08-10 18:55 -0400" Date: 2012-08-11 16:53:46 Python version: 3.3.0b1 (default:9804aec74d4a, Aug 11 2012, 16:53:12) [GCC 4.6.3 20120306 (Red Hat 4.6.3-2)] Platform of campaign writer: SCM: hg revision=9804aec74d4a+ tag=tip branch=default date="2012-08-10 18:55 -0400" Date: 2012-08-11 16:50:40 Python version: 3.3.0b1 (default:9804aec74d4a+, Aug 11 2012, 16:33:18) [GCC 4.6.3 20120306 (Red Hat 4.6.3-2)] --------------------------------------+-------------+--------------- 10 lines | pyaccu | writer --------------------------------------+-------------+--------------- reader short line ascii | 1.53 us (*) | 1.46 us writer short line ascii | 4.85 us (*) | 4.48 us (-8%) writer-reader short line ascii | 6.45 us (*) | 5.71 us (-12%) reader short line latin1 | 1.57 us (*) | 1.45 us (-8%) writer short line latin1 | 4.92 us (*) | 4.56 us (-7%) writer-reader short line latin1 | 6.6 us (*) | 5.78 us (-13%) reader short line bmp | 1.64 us (*) | 1.54 us (-6%) writer short line bmp | 5.01 us (*) | 4.43 us (-12%) writer-reader short line bmp | 6.68 us (*) | 5.71 us (-14%) reader short line non-bmp | 1.61 us (*) | 1.59 us writer short line non-bmp | 5.1 us (*) | 4.55 us (-11%) writer-reader short line non-bmp | 6.74 us (*) | 5.66 us (-16%) reader long lines ascii | 103 us (*) | 33.4 us (-68%) writer long lines ascii | 998 ns (*) | 836 ns (-16%) writer-reader long lines ascii | 1.45 us (*) | 1.18 us (-19%) reader long lines latin1 | 105 us (*) | 34.2 us (-67%) writer long lines latin1 | 997 ns (*) | 831 ns (-17%) writer-reader long lines latin1 | 1.47 us (*) | 1.2 us (-18%) reader long lines bmp | 121 us (*) | 85.9 us (-29%) writer long lines bmp | 995 ns (*) | 861 ns (-13%) writer-reader long lines bmp | 1.43 us (*) | 1.13 us (-21%) reader long lines non-bmp | 97.1 us (*) | 99.7 us writer long lines non-bmp | 1 us (*) | 819 ns (-18%) writer-reader long lines non-bmp | 1.4 us (*) | 1.18 us (-16%) reader very long lines ascii | 1.42 us (*) | 1.45 us writer very long lines ascii | 3.04 us (*) | 2.88 us (-5%) writer-reader very long lines ascii | 4.59 us (*) | 4.12 us (-10%) reader very long lines latin1 | 1.57 us (*) | 1.47 us (-7%) writer very long lines latin1 | 3.04 us (*) | 2.73 us (-10%) writer-reader very long lines latin1 | 4.66 us (*) | 4.04 us (-13%) reader very long lines bmp | 1.55 us (*) | 1.55 us writer very long lines bmp | 3.03 us (*) | 2.91 us writer-reader very long lines bmp | 4.72 us (*) | 4.08 us (-14%) reader very long lines non-bmp | 1.55 us (*) | 1.49 us writer very long lines non-bmp | 3.09 us (*) | 2.93 us (-5%) writer-reader very long lines non-bmp | 4.59 us (*) | 4.06 us (-12%) --------------------------------------+-------------+--------------- Total | 525 us (*) | 342 us (-35%) --------------------------------------+-------------+--------------- --------------------------------------+-------------+--------------- 1000 lines | pyaccu | writer --------------------------------------+-------------+--------------- reader short line ascii | 68.2 us (*) | 66.1 us writer short line ascii | 308 us (*) | 307 us writer-reader short line ascii | 378 us (*) | 374 us reader short line latin1 | 72 us (*) | 68.5 us writer short line latin1 | 324 us (*) | 313 us writer-reader short line latin1 | 395 us (*) | 383 us reader short line bmp | 74.8 us (*) | 71.9 us writer short line bmp | 326 us (*) | 303 us (-7%) writer-reader short line bmp | 397 us (*) | 378 us reader short line non-bmp | 72.9 us (*) | 72.6 us writer short line non-bmp | 329 us (*) | 304 us (-8%) writer-reader short line non-bmp | 397 us (*) | 383 us reader long lines ascii | 104 us (*) | 33.8 us (-67%) writer long lines ascii | 1.99 us (*) | 2.52 us (+27%) writer-reader long lines ascii | 4.37 us (*) | 3.45 us (-21%) reader long lines latin1 | 104 us (*) | 33.3 us (-68%) writer long lines latin1 | 2.07 us (*) | 2.55 us (+23%) writer-reader long lines latin1 | 4.51 us (*) | 3.57 us (-21%) reader long lines bmp | 120 us (*) | 80.5 us (-33%) writer long lines bmp | 2.15 us (*) | 2.55 us (+18%) writer-reader long lines bmp | 4.71 us (*) | 3.86 us (-18%) reader long lines non-bmp | 90.6 us (*) | 97.6 us (+8%) writer long lines non-bmp | 2.18 us (*) | 2.68 us (+23%) writer-reader long lines non-bmp | 4.24 us (*) | 4.05 us reader very long lines ascii | 2.53 us (*) | 1.66 us (-34%) writer very long lines ascii | 3.07 us (*) | 3.46 us (+13%) writer-reader very long lines ascii | 6.18 us (*) | 4.89 us (-21%) reader very long lines latin1 | 2.57 us (*) | 1.75 us (-32%) writer very long lines latin1 | 3.16 us (*) | 3.46 us (+10%) writer-reader very long lines latin1 | 6.32 us (*) | 4.98 us (-21%) reader very long lines bmp | 2.7 us (*) | 2.34 us (-14%) writer very long lines bmp | 3.52 us (*) | 3.65 us writer-reader very long lines bmp | 6.73 us (*) | 5.7 us (-15%) reader very long lines non-bmp | 2.45 us (*) | 2.35 us writer very long lines non-bmp | 3.47 us (*) | 3.87 us (+12%) writer-reader very long lines non-bmp | 5.98 us (*) | 5.85 us --------------------------------------+-------------+--------------- Total | 3.63 ms (*) | 3.34 ms (-8%) --------------------------------------+-------------+--------------- --------------------------------------+-------------+--------------- 100000 lines | pyaccu | writer --------------------------------------+-------------+--------------- reader short line ascii | 6.74 ms (*) | 6.43 ms writer short line ascii | 30.7 ms (*) | 29.8 ms writer-reader short line ascii | 37.5 ms (*) | 36.6 ms reader short line latin1 | 7.08 ms (*) | 6.64 ms (-6%) writer short line latin1 | 31.3 ms (*) | 30.1 ms writer-reader short line latin1 | 38.8 ms (*) | 37.5 ms reader short line bmp | 7.46 ms (*) | 6.98 ms (-6%) writer short line bmp | 32 ms (*) | 29 ms (-9%) writer-reader short line bmp | 40.5 ms (*) | 35.9 ms (-11%) reader short line non-bmp | 7.36 ms (*) | 7.23 ms writer short line non-bmp | 33.3 ms (*) | 29.4 ms (-12%) writer-reader short line non-bmp | 40.5 ms (*) | 36.5 ms (-10%) reader long lines ascii | 103 us (*) | 32.6 us (-68%) writer long lines ascii | 59.4 us (*) | 66.5 us (+12%) writer-reader long lines ascii | 220 us (*) | 99.2 us (-55%) reader long lines latin1 | 105 us (*) | 32.2 us (-69%) writer long lines latin1 | 60.2 us (*) | 67.3 us (+12%) writer-reader long lines latin1 | 240 us (*) | 97.6 us (-59%) reader long lines bmp | 122 us (*) | 76.9 us (-37%) writer long lines bmp | 62.1 us (*) | 73.8 us (+19%) writer-reader long lines bmp | 242 us (*) | 151 us (-38%) reader long lines non-bmp | 95.7 us (*) | 92.1 us writer long lines non-bmp | 76.5 us (*) | 90.3 us (+18%) writer-reader long lines non-bmp | 198 us (*) | 173 us (-12%) reader very long lines ascii | 91.6 us (*) | 11.5 us (-87%) writer very long lines ascii | 7.15 us (*) | 11.9 us (+67%) writer-reader very long lines ascii | 145 us (*) | 20.1 us (-86%) reader very long lines latin1 | 110 us (*) | 12 us (-89%) writer very long lines latin1 | 7.52 us (*) | 12.1 us (+61%) writer-reader very long lines latin1 | 165 us (*) | 20.7 us (-87%) reader very long lines bmp | 91.1 us (*) | 46.7 us (-49%) writer very long lines bmp | 12.3 us (*) | 22.5 us (+82%) writer-reader very long lines bmp | 150 us (*) | 61.9 us (-59%) reader very long lines non-bmp | 66.8 us (*) | 66.6 us writer very long lines non-bmp | 22.4 us (*) | 38.4 us (+72%) writer-reader very long lines non-bmp | 108 us (*) | 87.7 us (-19%) --------------------------------------+-------------+--------------- Total | 316 ms (*) | 294 ms (-7%) --------------------------------------+-------------+--------------- -------------+-------------+-------------- Summary | pyaccu | writer -------------+-------------+-------------- 10 lines | 525 us (*) | 342 us (-35%) 1000 lines | 3.63 ms (*) | 3.34 ms (-8%) 100000 lines | 316 ms (*) | 294 ms (-7%) -------------+-------------+-------------- Total | 320 ms (*) | 297 ms (-7%) -------------+-------------+-------------- ---------- Added file: http://bugs.python.org/file26765/bench_stringio2.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 17:35:26 2012 From: report at bugs.python.org (STINNER Victor) Date: Sat, 11 Aug 2012 15:35:26 +0000 Subject: [issue15612] Rewrite StringIO to use the _PyUnicodeWriter API In-Reply-To: <1344565830.56.0.384034899089.issue15612@psf.upfronthosting.co.za> Message-ID: <1344699326.74.0.317801747136.issue15612@psf.upfronthosting.co.za> STINNER Victor added the comment: "PyAccu looks much more appropriate than _PyUnicodeWriter, because it is always faster, except to write 100.000 very long lines." Oh... I added colors to my tool, but there was a bug: I used the wrong colors... It's just the opposite. _PyUnicodeWriter is almost always faster, except to write more than 100.000 very long lines. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 17:47:26 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Sat, 11 Aug 2012 15:47:26 +0000 Subject: [issue15561] update subprocess docs to reference io.TextIOWrapper In-Reply-To: <1344196317.87.0.366111796882.issue15561@psf.upfronthosting.co.za> Message-ID: <1344700046.77.0.895657831033.issue15561@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Hmm. As I can see in subprocess.py TextIOWrapper is applied to stdin also in non-buffered (write_through=True) mode. So input will be converted to use '\n' as well. Can you reflect this fact in your patches? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 18:15:34 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 11 Aug 2012 16:15:34 +0000 Subject: [issue15557] Tests for webbrowser module In-Reply-To: <1344102778.31.0.864118033074.issue15557@psf.upfronthosting.co.za> Message-ID: <1344701734.78.0.376080339928.issue15557@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 18:19:36 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 11 Aug 2012 16:19:36 +0000 Subject: [issue15612] Rewrite StringIO to use the _PyUnicodeWriter API In-Reply-To: <1344565830.56.0.384034899089.issue15612@psf.upfronthosting.co.za> Message-ID: <1344701976.45.0.978427314848.issue15612@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > _PyUnicodeWriter is almost always faster Actually, PyAccu is consistently faster for the "writer" case, while _PyUnicodeWriter is faster for the "writer-reader" case. This is not because of PyAccu, but because of the way StringIO uses it: when e.g. readline() is called, the PyAccu result is converted into a PyUCS4* buffer, then each readline() result is converted again by finding the max char in the sub-buffer. So I would suggest using PyAccu, but converting its result to a _PyUnicodeWriter rather than a PyUCS4* buffer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 18:45:34 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Aug 2012 16:45:34 +0000 Subject: [issue15612] Rewrite StringIO to use the _PyUnicodeWriter API In-Reply-To: <1344565830.56.0.384034899089.issue15612@psf.upfronthosting.co.za> Message-ID: <1344703534.96.0.398310767275.issue15612@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See benchmark results in issue15381 (the patch is not applicable to StringIO). These numbers show that resize strategy can be much slower append/join strategy on Windows. ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 18:54:07 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 11 Aug 2012 16:54:07 +0000 Subject: [issue15617] FAIL: test_create_connection (test.test_socket.NetworkConnectionNoServer) In-Reply-To: <1344603652.0.0.278766609424.issue15617@psf.upfronthosting.co.za> Message-ID: <1344704047.36.0.564235777532.issue15617@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Antoine: thanks for the report. I fear that this rules out using AI_ADDRCONFIG: IETF has managed to break it. This is really silly. So I'm tempted to close this as "won't fix". Comments? Build slaves would be required that a regular lookup of localhost matches the configured loopback addresses (which I feel is a reasonable operational requirement anyway). Floris: another work around is to configure ::1 in your zone. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 19:09:52 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 11 Aug 2012 17:09:52 +0000 Subject: [issue15622] struct module 'c' specifier does not follow PEP-3118 In-Reply-To: <1344671333.76.0.693259168971.issue15622@psf.upfronthosting.co.za> Message-ID: <1344704992.29.0.485284372785.issue15622@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Nick: that's a reasonable view, thanks - in particular the point that PEP 3118 should not be considered normative. I still think that the c code in struct is fairly redundant (with B) as it stands, so I think it should get deprecated and removed - but that's a different issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 19:31:04 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 11 Aug 2012 17:31:04 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1344706264.81.0.317722985041.issue15573@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Nick: I still disagree. Would you agree that array.array constitutes a "statically typed array"? Yet py> array.array('b',b'foo') == array.array('B',b'foo') True py> array.array('i',[1,2,3]) == array.array('L', [1,2,3]) True So the array object (rightfully) performs comparison on abstract values, not on memory representation. In Python, a statically typed array still conceptually contains abstract values, not memory blocks (this is also what Stefan asserts for NumPy in msg167862). The static typing only restricts the values you can store in the container, and defines the internal representation on the C level (plus it typically implies a value storage, instead of a reference storage). With your and Stefan's proposed semantics, we would get the weird case that for two array.arrays a and b, it might happen that a == b and memoryview(a) != memoryview(b) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 19:41:55 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 11 Aug 2012 17:41:55 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1344706915.55.0.933627274278.issue15573@psf.upfronthosting.co.za> Martin v. L?wis added the comment: "it might *still* happen", I should say, since this problem is exactly what Victor says this issue intends to solve (for comparison of two 'u' arrays). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 19:43:49 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 11 Aug 2012 17:43:49 +0000 Subject: [issue15557] Tests for webbrowser module In-Reply-To: <1344102778.31.0.864118033074.issue15557@psf.upfronthosting.co.za> Message-ID: <1344707029.77.0.498607167937.issue15557@psf.upfronthosting.co.za> Chris Jerdonek added the comment: It seems like these tests can be made more DRY. For example, the line `args = popen.cmd_line` appears in every test. You could make an assert_args() helper method to address this. There also seems to be a lot of overlap between tests for each browser. A DRY approach would let one see more easily how the tests differ across browsers. Do you also need to include the test boilerplate at the bottom? See, for example-- http://hg.python.org/cpython/file/867de88b69f0/Lib/test/test_textwrap.py#l732 ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 20:13:07 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 11 Aug 2012 18:13:07 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344658560.61.0.165773551095.issue15573@psf.upfronthosting.co.za> Message-ID: <20120811181307.GA30972@sleipnir.bytereef.org> Stefan Krah added the comment: So we have two competing proposals: 1) Py_buffers are strongly typed arrays in the ML sense (e.g. array of float, array of int). This is probably what I'd prefer on the C level, imagine a function like function like PyBuffer_Compare(v, w). Backwards compatibility problem for users who were thinking in terms of value comparisons: >>> x = array.array('b', [127]) >>> y = array.array('B', [127]) >>> x == y True >>> memoryview(x) == memoryview(y) False 2) Compare by value, like NumPy arrays do: >>> x = numpy.array([1, 2, 3], dtype='i') >>> y = numpy.array([1, 2, 3], dtype='f') >>> x == y array([True, True, True], dtype=bool) I concede that this is probably what users want to see on the Python level. Backwards compatibility problem for users who were using complicated structs: >>> from _testbuffer import * >>> x = ndarray([(1,1), (2,2), (3,3)], shape=[3], format='hQ') >>> x == memoryview(x) False Reason: While _testbuffer.ndarray already implements tolist() in full generality, memoryview does not: >>> x.tolist() [(1, 1), (2, 2), (3, 3)] >>> memoryview(x).tolist() Traceback (most recent call last): File "", line 1, in NotImplementedError: memoryview: unsupported format hQ So while I'm beginning to like Martin's proposal, the implementation is certainly trickier and will always be quite slow for complicated format strings. It would be possible to keep a fast path for the primitive C types and use the code from _testbuffer.tolist() for the slow cases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 20:15:13 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 11 Aug 2012 18:15:13 +0000 Subject: [issue15527] Double parens in functions references In-Reply-To: <1343833557.96.0.948912415493.issue15527@psf.upfronthosting.co.za> Message-ID: <3WvWZm0pp3zPhs@mail.python.org> Roundup Robot added the comment: New changeset 5e025dc7d728 by Andrew Svetlov in branch 'default': Issue #15527: fix docs, remove double parens by changing markup. http://hg.python.org/cpython/rev/5e025dc7d728 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 20:18:27 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Sat, 11 Aug 2012 18:18:27 +0000 Subject: [issue15527] Double parens in functions references In-Reply-To: <1343833557.96.0.948912415493.issue15527@psf.upfronthosting.co.za> Message-ID: <1344709107.33.0.946471542071.issue15527@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Applied patch uses ``expr(n)`` as Georg prefer. Serhiy, please close the issue if you have not any upcoming patches. Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 20:22:38 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 11 Aug 2012 18:22:38 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1344709358.36.0.34786773806.issue15573@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Here is a patch doing the comparison on abstract values if the formats are different. ---------- Added file: http://bugs.python.org/file26766/abstractcmp.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 20:28:30 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Aug 2012 18:28:30 +0000 Subject: [issue15527] Double parens in functions references In-Reply-To: <1343833557.96.0.948912415493.issue15527@psf.upfronthosting.co.za> Message-ID: <1344709710.27.0.951330941067.issue15527@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Andrew. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 20:44:50 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 11 Aug 2012 18:44:50 +0000 Subject: [issue15599] test_circular_imports() of test_threaded_import fails on FreeBSD 9.0 In-Reply-To: <1344473974.14.0.584788696764.issue15599@psf.upfronthosting.co.za> Message-ID: <1344710690.74.0.109588828714.issue15599@psf.upfronthosting.co.za> Stefan Krah added the comment: With -F -j16 I get these failures both on FreeBSD and Linux, but not the original failure: ====================================================================== FAIL: test_parallel_meta_path (test.test_threaded_import.ThreadedImportTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/stefan/hg/cpython/Lib/test/test_threaded_import.py", line 131, in test_parallel_meta_path self.check_parallel_module_init() File "/home/stefan/hg/cpython/Lib/test/test_threaded_import.py", line 120, in check_parallel_module_init self.assertFalse(errors) AssertionError: [AttributeError("'module' object has no attribute 'randrange'",)] is not false ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 20:58:07 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 11 Aug 2012 18:58:07 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1344711487.74.0.819262981129.issue15573@psf.upfronthosting.co.za> Nick Coghlan added the comment: OK, I think I finally understand what Martin is getting at from a semantic point of view, and I think I can better explain the background of the issue and why Stefan's proposed solution is both necessary and correct. The ideal definition of equivalence for memory view objects would actually be: memoryview(x) == memoryview(y) if (and only if) memoryview(x).tolist() == memoryview(y).tolist() Now, in practice, this approach cannot be implemented, because there are too many format definitions (whether valid or invalid) that memoryview doesn't understand (and perhaps will never understand) and because it would be completely infeasible on large arrays with complex format definitions. Thus, we are forced to accept a *constraint* on memoryview's definition of equality: individual values are always compared via raw memory comparison, thus values stored using different *sizes* or *layouts* in memory will always compare as unequal, even if they would compare as equal in Python This is an *acceptable* constraint as, in practice, you don't perform mixed format arithmetic and it's not a problem if there's no automatic coercion between sizes and layouts. The Python 3.2 memoryview effectively uses memcmp() directly treating everything as a 1D array of bytes data, completely ignoring both shape *and* format data. Thus: >>> ab = array('b', [1, 2, 3]) >>> ai = array('i', [1, 2, 3]) >>> aL = array('L', [1, 2, 3]) >>> ab == ai True >>> ab == ai == aL True >>> memoryview(ab) == memoryview(ai) False >>> memoryview(ab) == memoryview(aL) False >>> memoryview(ai) == memoryview(aL) False This approach leads to some major false positives, such as a floating point value comparing equal to an integer that happens to share the same binary representation: >>> af = array('f', [1.1]) >>> ai = array('i', [1066192077]) >>> af == ai False >>> memoryview(af) == memoryview(ai) True The changes in 3.3 are aimed primarily at *eliminating those false positives* by taking into account the shape of the array and the format of the contained values. It is *not* about changing the fundamental constraint that memoryview operates at the level of raw memory, rather than Python objects, and thus cares about memory layout details that are irrelevant after passing through the Python abstraction layer. This contrasts with the more limited scope of the array.array module, which *does* take into account the Python level abstractions. Thus, there will always be a discrepancy between the two definitions of equality, as memoryview cares about memory layout details, where array.array does not. The problem at the moment is that Python 3.3 currently has *spurious* false negatives that aren't caused by that fundamental constraint that comparisons must occur based directly on memory contents. Instead, they're being caused by memoryview returning False for any equality comparison for a format it doesn't understand. That's unacceptable, and is what Stefan's patch is intended to fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 21:03:29 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 11 Aug 2012 19:03:29 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1344711809.23.0.0129208724087.issue15573@psf.upfronthosting.co.za> Nick Coghlan added the comment: Short version: 3.3 implemented new constraints on memoryview equality comparisons to eliminate cases that were incorrectly returning True when they should have returned False. However, the format constraints are currently too restrictive, so some memoryview comparisons that correctly returned True in 3.2 are now also returning False. This patch fixes *those* comparisons to once again return True. Moving back to deferred blocked status, since the spurious false negatives are a regression from 3.2. It's fine for beta2 to ship with this problem, but it needs to be fixed for rc1. ---------- priority: high -> deferred blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 21:08:16 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 11 Aug 2012 19:08:16 +0000 Subject: [issue15561] update subprocess docs to reference io.TextIOWrapper In-Reply-To: <1344196317.87.0.366111796882.issue15561@psf.upfronthosting.co.za> Message-ID: <1344712096.6.0.597512138703.issue15561@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > Can you reflect this fact in your patches? Sure. (Though for stdin '\n' is converted to os.linesep and no more.) Would you mind if I also updated the following part of the subprocess documentation to reference the part we are updating, so that the documentation is just in one place? "If universal_newlines is True, the file objects stdout and stderr are opened as text files, but lines may be terminated by any of '\n', the Unix end-of-line convention, '\r', the old Macintosh convention or '\r\n', the Windows convention. All of these external representations are seen as '\n' by the Python program." The part we're updating is in the "Frequently Used Arguments" section and so seems like the natural place for expanded details. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 21:09:31 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 11 Aug 2012 19:09:31 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1344712171.76.0.777997948725.issue15573@psf.upfronthosting.co.za> Nick Coghlan added the comment: I can see value in adopting the abstraction approach, but it's not part of this issue. That problem already existed when using memoryview in 3.2, we can wait until 3.4 to fix it. There's an actual, concrete regression in 3.3 that may break code, and comparing with memcmp() when the format strings match is enough to fix it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 21:12:47 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 11 Aug 2012 19:12:47 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1344712367.8.0.0360983325981.issue15573@psf.upfronthosting.co.za> Nick Coghlan added the comment: And, to be honest, I'd be quite happy for "congratulations, you have reached the threshold where you need NumPy rather than memoryview" to be the long term answer to getting "by value" comparison semantics. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 21:14:24 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 11 Aug 2012 19:14:24 +0000 Subject: [issue15624] clarify io.TextIOWrapper newline documentation Message-ID: <1344712464.43.0.600420981046.issue15624@psf.upfronthosting.co.za> New submission from Chris Jerdonek: The documentation of io.TextIOWrapper's newline argument is somewhat confusing and perhaps reversed from what was intended. (For example, the subprocess module uses the reverse terminology.) Either way, it can be improved somewhat. Currently, it says-- "* On input, if newline is None,... Lines in the input can end in '\n', '\r', or '\r\n', and these are translated into '\n' before being returned to the caller... * On output, if newline is None, any '\n' characters written are translated to the system default line separator, os.linesep..." (from http://docs.python.org/dev/library/io.html#io.TextIOWrapper ) It is somewhat confusing because "On input" does not mean "On input to the buffer," and "On output" does not mean "On output from the buffer." It is the reverse. A minimal change to address this would be something along the lines of-- "On input" -> "When reading input from the buffer" "On output" -> "When writing output to the buffer The same change could also be made to the open() documentation: http://docs.python.org/dev/library/functions.html#open I can prepare a patch for affected versions. ---------- assignee: docs at python components: Documentation keywords: easy messages: 167995 nosy: cjerdonek, docs at python priority: normal severity: normal status: open title: clarify io.TextIOWrapper newline documentation _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 21:15:27 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 11 Aug 2012 19:15:27 +0000 Subject: [issue15624] clarify io.TextIOWrapper newline documentation In-Reply-To: <1344712464.43.0.600420981046.issue15624@psf.upfronthosting.co.za> Message-ID: <1344712527.37.0.659079654672.issue15624@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Andrew, I'm adding you because this is the documentation that the subprocess module will point to after issue 15561. ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 21:16:33 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 11 Aug 2012 19:16:33 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1317341390.65.0.255779328054.issue13072@psf.upfronthosting.co.za> Message-ID: <1344712593.18.0.190830163257.issue13072@psf.upfronthosting.co.za> Nick Coghlan added the comment: There's still work to be done. The current status in 3.3 trunk is that: Wide build: >>> memoryview(array("u")).format 'w' Narrow build: >>> memoryview(array("u")).format 'u' Neither of these are valid struct formats, thus they don't play nicely with the assumptions of memoryview (or any other PEP 3118 consumer). Stefan's memoryview changes are needed because there are *valid* struct formats that memoryview doesn't understand (yet), but it's only coincidental that they will reduce the severity of this problem. Victor's latest patch switches the 'w' and 'u' for the appropriate integer sizes 'I' and 'H' which I think is an excellent approach. There are also the post-reversion documentation changes Georg requested to bring the docs back into line with PEP 393 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 21:17:39 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Sat, 11 Aug 2012 19:17:39 +0000 Subject: [issue15528] Better support for finalization with weakrefs In-Reply-To: <1343837927.06.0.561023898829.issue15528@psf.upfronthosting.co.za> Message-ID: <1344712659.51.0.430174179759.issue15528@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > In the latest patch, what are "broken" and "priority" for? They are for a subclass used by multiprocessing. But it is premature to worry about subclassing, so I will take them out. > Also, I would question why atexit is false by default. I would find it > personally less surprising to be true. OK. One thing I do worry about is having the loop in the exit function to run any finalizers created during the exit function. The current implementation will run these extra finalizers at the wrong time. Fixing this could probably be done by using a dirty flag and disabling gc while running the finalizers. I wonder if it would be better to not call finalizers created during the exit function. We cannot guarantee that every finalizer created during shutdown is run, so is a best effort attempt really worth the effort? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 21:27:40 2012 From: report at bugs.python.org (Steven Collins) Date: Sat, 11 Aug 2012 19:27:40 +0000 Subject: [issue15606] re.VERBOSE whitespace behavior not completely documented In-Reply-To: <1344534617.67.0.49137100671.issue15606@psf.upfronthosting.co.za> Message-ID: <1344713260.32.0.345872616023.issue15606@psf.upfronthosting.co.za> Steven Collins added the comment: Fair enough, but in that case I still think the current behavior should be documented. Attached is a possible patch. (This is my first interaction with the Python issue tracker, by the way; apologies if I ought to have set some field differently or left some other field alone.) ---------- assignee: -> docs at python components: +Documentation keywords: +patch nosy: +docs at python title: re.VERBOSE doesn't ignore certain whitespace -> re.VERBOSE whitespace behavior not completely documented type: behavior -> enhancement versions: +Python 3.3 -Python 2.7, Python 3.2 Added file: http://bugs.python.org/file26767/re_whitespace.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 21:34:27 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 11 Aug 2012 19:34:27 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344711809.23.0.0129208724087.issue15573@psf.upfronthosting.co.za> Message-ID: <5026B3C0.8040501@v.loewis.de> Martin v. L?wis added the comment: > However, the format constraints are currently too restrictive, so > some memoryview comparisons that correctly returned True in 3.2 are > now also returning False. This patch fixes *those* comparisons to > once again return True. No, it doesn't - at least not in all cases. If you compare 'b' and 'B' arrays with values in range(128), then 3.2 rightfully returned True, but will still return False under the patch. In any case, whatever the solution is (or even "whatever the problem is"), it needs to be clearly spelled out in the documentation, since it will be far from obvious. > Instead, they're being caused by memoryview returning False for any > equality comparison for a format it doesn't understand. That's > unacceptable, and is what Stefan's patch is intended to fix. I fail to see why this is unacceptable. If you don't understand the format code, you cannot know how to compare the values - you cannot even know how to compare the memory representation of the values. If the memory compares unequal, it may still be plausible that the values are actually equal (e.g. if this is a numerator-denominator representation of rationals). There are even cases where the memory comparison can compare as equal, yet the values should compare non-equal (e.g. IEEE NaNs, or relative pointers). I also think this is a *really* obscure problem: not many people use memoryview objects, very few desire to compare them for equality (most rather use them for efficient IO, and "poking" into structures), and of those, nearly nobody uses them with unsupported format codes - in particular not if "u" and "w" get implemented (since then standard Python will not have ways to create memoryview objects reasonably with unsupported codes). What specific example did you think of that regresses from 3.2? So I still fail to see why this problem can manage to block the release of 3.3 - but that's for the release manager to decide. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 21:37:59 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Sat, 11 Aug 2012 19:37:59 +0000 Subject: [issue15151] Documentation for Signature, Parameter and signature in inspect module In-Reply-To: <1340432030.73.0.594662136445.issue15151@psf.upfronthosting.co.za> Message-ID: <1344713879.13.0.723363671866.issue15151@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Slightly updated version ---------- Added file: http://bugs.python.org/file26768/inspect.pep362.5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 21:45:44 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 11 Aug 2012 19:45:44 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344712367.8.0.0360983325981.issue15573@psf.upfronthosting.co.za> Message-ID: <5026B662.5010808@v.loewis.de> Martin v. L?wis added the comment: > And, to be honest, I'd be quite happy for "congratulations, you have > reached the threshold where you need NumPy rather than memoryview" to > be the long term answer to getting "by value" comparison semantics. IMO, this threshold is already reached when you start comparing memoryview objects. PEP 3118 apparently introduced it to replace the buffer obejct, and specified that it should have __getitem__ and __setitem__ as magic methods; the PEP doesn't talk about comparison at all. So I wonder where the desire to support comparison for equality comes from (but I can accept that we have to deal with it as it is there now). IMO, it would be reasonable to declare to memory buffers as unequal if they denote different memory blocks in main memory (i.e. at different addresses). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 21:52:48 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 11 Aug 2012 19:52:48 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1344714768.57.0.382120950154.issue15573@psf.upfronthosting.co.za> Nick Coghlan added the comment: Hmm, you're right. OK, here's a simpler proposal for 3.3: 1. Always look at shape first. If they're different, then they're not equal 2. If both formats are known, compare by unpacked value 3. If either format is unknown, compare by memory contents (just like 3.2) The fallback case should then behave exactly like 3.2 (since 3.2 really couldn't handle anything other than 1D data and always ignored the format info). I'd be happier if the compare-by-value didn't make complete copies of the entire array though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 21:59:33 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 11 Aug 2012 19:59:33 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344714768.57.0.382120950154.issue15573@psf.upfronthosting.co.za> Message-ID: <1344715010.3350.15.camel@localhost.localdomain> Antoine Pitrou added the comment: Le samedi 11 ao?t 2012 ? 19:52 +0000, Nick Coghlan a ?crit : > I'd be happier if the compare-by-value didn't make complete copies of > the entire array though. Ditto. If a and b are bytes objects, comparing memoryview(a) and memoryview(b) should be as cheap as comparing a and b. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 22:07:01 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 11 Aug 2012 20:07:01 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1344712593.18.0.190830163257.issue13072@psf.upfronthosting.co.za> Message-ID: <5026BB63.6020806@v.loewis.de> Martin v. L?wis added the comment: > Wide build: >>>> memoryview(array("u")).format > 'w' > > Narrow build: >>>> memoryview(array("u")).format > 'u' > > Neither of these are valid struct formats, thus they don't play > nicely with the assumptions of memoryview (or any other PEP 3118 > consumer). Why do you say that? They have been added by PEP 3118 (and are just not implemented in the struct module yet). If you think that their mentioning in PEP 3118 is a mistake, and they should not get implemented in struct, we should a) get consensus on that interpretation of the PEP, and b) actually remove them from the PEP, since otherwise it is very confusing that they keep being mentioned. I believe that the addition of these codes was fully intended by the PEP author, and also part of its acceptance. If these codes are indeed meant to be in the struct module, this usage in the array module looks right to me - hence my proposal to close the issue (the documentation problem aside). I agree that it is then desirable that the memoryview object supports the codes. However, this is separate issue from this one (as the codes are not invalid, just unsupported). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 22:28:23 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 11 Aug 2012 20:28:23 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344715010.3350.15.camel@localhost.localdomain> Message-ID: <5026C062.9050206@v.loewis.de> Martin v. L?wis added the comment: Am 11.08.12 21:59, schrieb Antoine Pitrou: > Le samedi 11 ao?t 2012 ? 19:52 +0000, Nick Coghlan a ?crit : >> I'd be happier if the compare-by-value didn't make complete copies of >> the entire array though. > > Ditto. If a and b are bytes objects, comparing memoryview(a) and > memoryview(b) should be as cheap as comparing a and b. I agree with Antoine's requirement, generalizing it to "the simple cases should be efficient". I wonder why the procedure couldn't instead be 1. compare shapes 2. if the format strings are string-equal, compare the memory representation 3. else unpack values Then, comparing two 1D 'B' memoryviews would be a memcmp (i.e. it wouldn't do compare-by-value in this case). For unpacking, I don't see any way to have it efficient and still maintainable, since mixed-type comparisons are quite tedious to write in C, and really best done with type normalization and multiple dispatch in the way that unpacking will do it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 22:34:06 2012 From: report at bugs.python.org (Glenn Linderman) Date: Sat, 11 Aug 2012 20:34:06 +0000 Subject: [issue15564] cgi.FieldStorage should not call read_multi on files In-Reply-To: <1344245506.28.0.499641288303.issue15564@psf.upfronthosting.co.za> Message-ID: <1344717246.0.0.533437017519.issue15564@psf.upfronthosting.co.za> Glenn Linderman added the comment: I didn't call the current behaviour of browsers in assigning MIME types automatically based on file extension a bug; I would consider it more of a missing capability, an oversight due to the rareness of attempts to upload MHTML files. This is similar to the situation of email clients automatically choosing the Content-Disposition for attachments (which is just a recommendation) about whether to suggest they be displayed inline, or provided as attachments to be saved. Most automatically select a Content-Disposition based on their own capability to deal with an attachment of a particular MIME type, rather than the (unknown) capability of the email client of the ultimate recipient. I think in both cases, the default behavior works well enough for a large enough subset of cases, that there has been little demand for increased functionality, even though one can contrive reasonable sounding cases for that functionality. As a point of discussion, my perception is that MHTML files have two uses: to email an image of a web page (something typically done implicitly by bundled email/web-browser client software, and not generally explicit in the creation of a standalone MHTML file), and to archive a web page for local reference. Neither of these uses involves upload MHTML files to web sites, although saving a web page, and then attempting to email it to a friend as an attachment via a web mail client might encounter the same difficulty you are having. Another use I have heard discussed (but I've forgotten where, so have no references), is as a source for custom browsers to prepackage responses for particular WEB forms. In that case, I think it would be the custom browser's responsibility to supply the MHTML file content as a response to the form request, rather than to supply it as an uploaded file, expecting the server to dissect it... I think it is obvious that my personal, first reaction is that the parsing problem should be fixed... if the MIME type states it is multipart, it should dissected into its parts... and if that is not the desired behavior, then the MIME type should be different. Email standards, the source of MIME type specifications, certainly use and support nested multipart dissection, although various email software performs it in various manners and to various levels. Naturally, if the content syntax of the multipart file is incorrect, it should produce an exception, the same as if the multipart content a (buggy) browser produced from an HTML form were syntactically incorrect. Given a lack of capability of browser to allow specification of MIME type (this is .mht, but treat it as application/octet-stream rather than multipart/related), it does seem that web server toolkits such as cgi.FieldStorage might want to offer an option or hook to allow an application to disable the otherwise automatic parsing of multipart/* files. This is a rather murky area, indeed. Research into whether and how other web toolkits handle such a situation would be interesting in deciding how to proceed. While there is no need for Python to slavishly follow the lead of any other particular web toolkit, it would be interesting to know if any actually successfully parse such files, and it would be interesting to know if any ignore the MIME type for uploaded files, and it would be interesting to know if any support options for handling uploaded files with multipart/* MIME types. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 22:36:01 2012 From: report at bugs.python.org (Kushal Das) Date: Sat, 11 Aug 2012 20:36:01 +0000 Subject: [issue15615] More tests for JSON decoder to test Exceptions In-Reply-To: <1344593566.55.0.653447713109.issue15615@psf.upfronthosting.co.za> Message-ID: <1344717361.88.0.104890078255.issue15615@psf.upfronthosting.co.za> Kushal Das added the comment: Contributor's agreement signed and sent to the given email address. Thanks for the input. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 23:12:54 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Sat, 11 Aug 2012 21:12:54 +0000 Subject: [issue15593] urlparse.parse_qs documentation wrong re: urlencode In-Reply-To: <1344455271.07.0.337513141168.issue15593@psf.upfronthosting.co.za> Message-ID: <1344719574.31.0.647173728662.issue15593@psf.upfronthosting.co.za> Changes by Senthil Kumaran : ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 23:16:27 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 11 Aug 2012 21:16:27 +0000 Subject: [issue15625] Support u and w codes in memoryview Message-ID: <1344719787.86.0.485615026169.issue15625@psf.upfronthosting.co.za> New submission from Martin v. L?wis: Currently, the following test case fails: >>> import array >>> a=array.array('u', 'foo') >>> memoryview(a)==memoryview(a) False This is because the memoryview object doesn't support the u and w codes, as it should per PEP 3118. This patch fixes it. ---------- files: uwcodes.diff keywords: patch messages: 168009 nosy: loewis, ncoghlan, skrah priority: normal severity: normal status: open title: Support u and w codes in memoryview Added file: http://bugs.python.org/file26769/uwcodes.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 23:16:56 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 11 Aug 2012 21:16:56 +0000 Subject: [issue15625] Support u and w codes in memoryview In-Reply-To: <1344719787.86.0.485615026169.issue15625@psf.upfronthosting.co.za> Message-ID: <1344719816.93.0.115064500522.issue15625@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 11 23:46:11 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 11 Aug 2012 21:46:11 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1344721571.39.0.0129155211751.issue15573@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Here is a more formal definition of my last proposal, v and w are equal iff v.shape() == w.shape() and ((v.format == w.format and v.tobytes() == w.tobytes()) or v.tolist() == w.tolist()) if tolist raises an exception for unsupported codes, they are not equal As usual, the implementation can deviate from the spec as long as it behaves "as-if" it would use this exact algorithm (assuming unlimited memory). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 01:19:38 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 11 Aug 2012 23:19:38 +0000 Subject: [issue15611] devguide: add "core mentors" area to Experts Index In-Reply-To: <1344546895.77.0.0864519810759.issue15611@psf.upfronthosting.co.za> Message-ID: <1344727178.43.0.0495013655684.issue15611@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Here is an initial patch based on the core developers who responded on core-mentorship. In response to Ezio's comment (after thinking further), I think the goal would be to provide a list of people that new contributors should feel welcome to add to the nosy list in interest areas that are not otherwise covered (or perhaps on any issue they would like advice on?). Reasons for limiting this to new contributors and core mentors are (1) to prevent the core developers listed from being added to the nosy list for *every* issue that falls into an area not covered, and (2) in recognition that new contributors benefit from the mentorship and welcome that core mentors are especially interested in providing. I see that the "core mentorship" label does not fully capture this, but I'm open to other suggestions (e.g. choosing a different label, adding a footnote, or adding another section). Having this be part of the Experts Index simplifies things like populating the tracker pull-down. ---------- keywords: +patch nosy: +brett.cannon, r.david.murray Added file: http://bugs.python.org/file26770/issue-15611-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 01:35:18 2012 From: report at bugs.python.org (Brett Cannon) Date: Sat, 11 Aug 2012 23:35:18 +0000 Subject: [issue15623] Init time relative imports no longer work from __init__.so modules In-Reply-To: <1344697325.25.0.880049566038.issue15623@psf.upfronthosting.co.za> Message-ID: <1344728118.06.0.815710597304.issue15623@psf.upfronthosting.co.za> Brett Cannon added the comment: The trigger of that exception is importlib._bootstrap._sanity_check() (http://hg.python.org/cpython/file/5e025dc7d728/Lib/importlib/_bootstrap.py#l1466). It's called very early on to verify certain things, including that the parent package is already loaded when importing a submodule. It's that last bit that's failing. If you look at 3.2 vs. 3.3 for imp.load_dynamic() which does extension module loading for importlib, there is essentially no change, even as far as looking into Python/importdl.c:_PyImport_LoadDynamicModule() (http://hg.python.org/cpython/file/5e025dc7d728/Python/import.c#l1773 vs. http://hg.python.org/cpython/file/3654c711019a/Python/import.c#l3446). The problem is that the check for the parent module is also in Python/import.c from 3.2 so this isn't a new check. Is it possible that Cython is doing something differently now that it didn't do before? I know you said this worked in 3.2 and earlier, Stefan, but was that with the same version of Cython? Did the actual C call and setup for that call change? Otherwise I can't think of how anything specifically changed between 3.2 and 3.3 that would fundamentally change this. ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 02:12:56 2012 From: report at bugs.python.org (Ben Darnell) Date: Sun, 12 Aug 2012 00:12:56 +0000 Subject: [issue15626] unittest.main negates -bb option and programmatic warning configuration Message-ID: <1344730376.57.0.519562827761.issue15626@psf.upfronthosting.co.za> New submission from Ben Darnell: In python 3.2, unittest.main by default modifies the warning configuration if no -W options were given on the command line. This undoes the effect of -bb, turning BytesWarning back into a warning instead of an error. If both -bb and -Werror::BytesWarning are given, then unittest does not tamper with the warning configuration and byte operations raise errors as expected (but note that -Werror doesn't work in the current version of virtualenv due to https://github.com/pypa/virtualenv/issues/194 ). unittest.main should check for the -bb flag in addition to sys.warnoptions. Additionally, if warning filters were modified programmatically before calling unittest.main, unittest will still modify the configuration and potentially override the user's settings. This is a rarer case, but I've done it before to avoid the problem with -W in a virtualenv (https://github.com/facebook/tornado/blob/master/tornado/test/runtests.py). It would be good for there to be some way to tell unittest.main not to touch the warnings at all. main(warnings=False) currently works, but that's relying on an implementation detail (any non-None, non-truthy value works), so either this should be documented or an official way to do the same thing should be added. The attached test file demonstrates the problem: when run with -bb, an warning is logged, but the test passes. ---------- files: testbb.py messages: 168013 nosy: Ben.Darnell priority: normal severity: normal status: open title: unittest.main negates -bb option and programmatic warning configuration type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file26771/testbb.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 02:23:18 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 12 Aug 2012 00:23:18 +0000 Subject: [issue15031] Split .pyc parsing from module loading In-Reply-To: <1339096213.71.0.334524050625.issue15031@psf.upfronthosting.co.za> Message-ID: <1344730998.27.0.460212770946.issue15031@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 02:39:29 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 12 Aug 2012 00:39:29 +0000 Subject: [issue15031] Split .pyc parsing from module loading In-Reply-To: <1339096213.71.0.334524050625.issue15031@psf.upfronthosting.co.za> Message-ID: <1344731969.93.0.527995857685.issue15031@psf.upfronthosting.co.za> Brett Cannon added the comment: So the more I think about this, the more I'm willing to do this in Python 3.4. First, though, the docs would need to be updated in importlib to distinguish between bytecode and byte-compiled files. >From there, I think importlib.abc.SourceLoader.parse_byte_compiled_file(data) could exist. It would be a classmethod so people can call it directly if they really want. It would verify the magic number, and if that's good, return a dict that can be directly compared against what path_stats() returns plus the bytecode for the module. This should properly shield the format of bytecode from users while still providing an API people can rely on. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 02:44:36 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 12 Aug 2012 00:44:36 +0000 Subject: [issue15627] Add a method to importlib.abc.SourceLoader for converting source to a code object Message-ID: <1344732276.83.0.543554641885.issue15627@psf.upfronthosting.co.za> New submission from Brett Cannon: A classmethod called importlib.abc.SourceLoader.source_to_code(source_bytes, path) would return a code object. By default it would be equivalent to ``compile(source_bytes, source_path, 'exec', dont_inherit=True)``, but others could override this to e.g. convert the source to an AST, optimize the AST, and then call compile() to get the desired code object. ---------- components: Library (Lib) messages: 168015 nosy: brett.cannon, eric.snow priority: low severity: normal stage: test needed status: open title: Add a method to importlib.abc.SourceLoader for converting source to a code object versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 02:59:54 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 12 Aug 2012 00:59:54 +0000 Subject: [issue15626] unittest.main negates -bb option and programmatic warning configuration In-Reply-To: <1344730376.57.0.519562827761.issue15626@psf.upfronthosting.co.za> Message-ID: <1344733194.71.0.208161007013.issue15626@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 04:01:02 2012 From: report at bugs.python.org (Glenn Linderman) Date: Sun, 12 Aug 2012 02:01:02 +0000 Subject: [issue15564] cgi.FieldStorage should not call read_multi on files In-Reply-To: <1344245506.28.0.499641288303.issue15564@psf.upfronthosting.co.za> Message-ID: <1344736862.7.0.339587319534.issue15564@psf.upfronthosting.co.za> Glenn Linderman added the comment: I forgot to mention that the file you provided in your test doesn't look like a well-formed MHTML file, and so an exception would be expected in this case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 04:07:22 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 12 Aug 2012 02:07:22 +0000 Subject: [issue15628] Add import ABC hierarchy to docs for importlib Message-ID: <1344737242.66.0.0570077478746.issue15628@psf.upfronthosting.co.za> New submission from Andrew Svetlov: It would be useful to show import ABC hierarchy in the docs. See attached patch. ---------- files: import_abc.diff keywords: patch messages: 168017 nosy: asvetlov priority: normal severity: normal status: open title: Add import ABC hierarchy to docs for importlib versions: Python 3.3 Added file: http://bugs.python.org/file26772/import_abc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 04:08:45 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 12 Aug 2012 02:08:45 +0000 Subject: [issue15628] Add import ABC hierarchy to docs for importlib In-Reply-To: <1344737242.66.0.0570077478746.issue15628@psf.upfronthosting.co.za> Message-ID: <1344737325.58.0.268944408855.issue15628@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Brett, what do you think about? ---------- assignee: -> docs at python components: +Documentation keywords: +easy nosy: +brett.cannon, docs at python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 06:35:33 2012 From: report at bugs.python.org (Stefan Behnel) Date: Sun, 12 Aug 2012 04:35:33 +0000 Subject: [issue15623] Init time relative imports no longer work from __init__.so modules In-Reply-To: <1344697325.25.0.880049566038.issue15623@psf.upfronthosting.co.za> Message-ID: <1344746133.72.0.793481565829.issue15623@psf.upfronthosting.co.za> Stefan Behnel added the comment: We are continuously testing Cython against all CPython versions starting from 2.4, so I can assure you that it's still working for all other versions. Here's our CI server: https://sage.math.washington.edu:8091/hudson/job/cython-devel-tests/618/ I just tried it and it definitely works for me in 3.2 and prints the right module names. I attached the unfolded test directory. The only changes I applied were to change the setup.py script so that you can build it without Cython, and to replace the absolute paths stored in the C files by relative paths (which happily continue to work). Just run "python3.3 setup.py build_ext -i" and then "PYTHON=python3.3 ./test.sh". Note that the output for "FILE" will be the original Python source file. Cython sets this at init time because CPython fails to provide the correct import file path at that point. The value is actually written down verbatimly in the C sources. It prints sys.modules at module init time, so you can see that it contains "my_test_package" in Py<3.3 but does not contain it in Py3.3. The code for the relative import in __init__.c starts in line 1097. It actually calls "__import__()" internally. ---------- Added file: http://bugs.python.org/file26773/test.tgz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 06:36:23 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 12 Aug 2012 04:36:23 +0000 Subject: [issue15557] Tests for webbrowser module In-Reply-To: <1344102778.31.0.864118033074.issue15557@psf.upfronthosting.co.za> Message-ID: <1344746183.08.0.159682713118.issue15557@psf.upfronthosting.co.za> R. David Murray added the comment: Regrtest has evolved. For new test files (ie: 3.3 and later) the preferred (at least by me :) idiom now is just: if __name__ == '__main__': unittest.main() Everything else is now automatic, using the unittest machinery. For an example, see test_smptd. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 06:49:10 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 12 Aug 2012 04:49:10 +0000 Subject: [issue15564] cgi.FieldStorage should not call read_multi on files In-Reply-To: <1344245506.28.0.499641288303.issue15564@psf.upfronthosting.co.za> Message-ID: <1344746950.76.0.792121049338.issue15564@psf.upfronthosting.co.za> R. David Murray added the comment: I'd like to weigh in on this, but I need time to do research on the question first. It may be a bit before I get that time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 06:56:07 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 12 Aug 2012 04:56:07 +0000 Subject: [issue15626] unittest.main negates -bb option and programmatic warning configuration In-Reply-To: <1344730376.57.0.519562827761.issue15626@psf.upfronthosting.co.za> Message-ID: <1344747367.12.0.0725389781292.issue15626@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 07:17:47 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 12 Aug 2012 05:17:47 +0000 Subject: [issue15619] set.pop() documentation is confusing In-Reply-To: <1344618037.56.0.180857991175.issue15619@psf.upfronthosting.co.za> Message-ID: <1344748667.23.0.269682059661.issue15619@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I concur with Georg and Eli. The word "arbitrary" was chosen intentionally. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 08:19:00 2012 From: report at bugs.python.org (Eric Snow) Date: Sun, 12 Aug 2012 06:19:00 +0000 Subject: [issue15623] Init time relative imports no longer work from __init__.so modules In-Reply-To: <1344697325.25.0.880049566038.issue15623@psf.upfronthosting.co.za> Message-ID: <1344752340.9.0.434230490536.issue15623@psf.upfronthosting.co.za> Eric Snow added the comment: I was able to reproduce the error using a fresh build from tip (34d5ec8a1019): /tmp/test$ PYTHON=/opt/python3.3/bin/python3 ./test.sh ['__main__', '_bisect', '_codecs', '_collections', '_frozen_importlib', '_functools', '_heapq', '_imp', '_io', '_locale', '_sre', '_sysconfigdata', '_thread', '_warnings', '_weakref', '_weakrefset', 'abc', 'bisect', 'builtins', 'codecs', 'collections', 'collections.abc', 'copyreg', 'encodings', 'encodings.aliases', 'encodings.latin_1', 'encodings.utf_8', 'errno', 'functools', 'genericpath', 'heapq', 'io', 'itertools', 'keyword', 'locale', 'marshal', 'operator', 'os', 'os.path', 'posix', 'posixpath', 're', 'reprlib', 'signal', 'site', 'sre_compile', 'sre_constants', 'sre_parse', 'stat', 'sys', 'sysconfig', 'weakref', 'zipimport'] Traceback (most recent call last): File "", line 1, in File "__init__.py", line 11, in init my_test_package (my_test_package/__init__.c:1106) SystemError: Parent module 'my_test_package' not loaded, cannot perform relative import ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 08:21:48 2012 From: report at bugs.python.org (Eric Snow) Date: Sun, 12 Aug 2012 06:21:48 +0000 Subject: [issue15623] Init time relative imports no longer work from __init__.so modules In-Reply-To: <1344697325.25.0.880049566038.issue15623@psf.upfronthosting.co.za> Message-ID: <1344752508.07.0.792070740285.issue15623@psf.upfronthosting.co.za> Eric Snow added the comment: The files, post-run: $ find /tmp/test/ /tmp/test/ /tmp/test/my_test_package /tmp/test/my_test_package/__init__.cpython-33dm.so /tmp/test/my_test_package/a.cpython-33dm.so /tmp/test/my_test_package/a.c /tmp/test/my_test_package/a.py /tmp/test/my_test_package/__init__.py /tmp/test/my_test_package/__init__.c /tmp/test/test.tgz /tmp/test/build /tmp/test/build/temp.linux-x86_64-3.3-pydebug /tmp/test/build/temp.linux-x86_64-3.3-pydebug/my_test_package /tmp/test/build/temp.linux-x86_64-3.3-pydebug/my_test_package/a.o /tmp/test/build/temp.linux-x86_64-3.3-pydebug/my_test_package/__init__.o /tmp/test/test.sh /tmp/test/setup.py ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 08:31:08 2012 From: report at bugs.python.org (Eric Snow) Date: Sun, 12 Aug 2012 06:31:08 +0000 Subject: [issue15623] Init time relative imports no longer work from __init__.so modules In-Reply-To: <1344697325.25.0.880049566038.issue15623@psf.upfronthosting.co.za> Message-ID: <1344753068.94.0.987795846648.issue15623@psf.upfronthosting.co.za> Eric Snow added the comment: Traceback when run verbosely: Traceback (most recent call last): File "", line 1, in File "", line 1529, in _find_and_load File "", line 1496, in _find_and_load_unlocked File "", line 583, in _check_name_wrapper File "", line 498, in set_package_wrapper File "", line 511, in set_loader_wrapper File "", line 1109, in load_module File "", line 310, in _call_with_frames_removed File "__init__.py", line 11, in init my_test_package (my_test_package/__init__.c:1106) SystemError: Parent module 'my_test_package' not loaded, cannot perform relative import ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 09:11:32 2012 From: report at bugs.python.org (Eric Snow) Date: Sun, 12 Aug 2012 07:11:32 +0000 Subject: [issue15623] Init time relative imports no longer work from __init__.so modules In-Reply-To: <1344697325.25.0.880049566038.issue15623@psf.upfronthosting.co.za> Message-ID: <1344755492.98.0.873369571601.issue15623@psf.upfronthosting.co.za> Eric Snow added the comment: in ___init__.c:963+, prior to executing the module proper (Python2 and PyPy handling removed): /*--- Module creation code ---*/ __pyx_m = PyModule_Create(&__pyx_moduledef); if (!__pyx_m) {...}; __pyx_b = PyImport_AddModule(__Pyx_NAMESTR(__Pyx_BUILTIN_MODULE_NAME)); if (!__pyx_b) {...}; if (__Pyx_SetAttrString(__pyx_m, "__builtins__", __pyx_b) < 0) {...}; /*--- Initialize various global constants etc. ---*/ if (unlikely(__Pyx_InitGlobals() < 0)) {...} if (__pyx_module_is_main_my_test_package) { if (__Pyx_SetAttrString(__pyx_m, "__name__", __pyx_n_s____main__) < 0) {...}; } if (__Pyx_SetAttrString(__pyx_m, "__file__", __pyx_kp_u_6) < 0) {...}; __pyx_t_1 = Py_BuildValue("[O]", __pyx_kp_u_7); if (unlikely(!__pyx_t_1)) {...} __Pyx_GOTREF(__pyx_t_1); if (__Pyx_SetAttrString(__pyx_m, "__path__", __pyx_t_1) < 0) {...}; __Pyx_DECREF(__pyx_t_1); __pyx_t_1 = 0; /*--- Builtin init code ---*/ if (unlikely(__Pyx_InitCachedBuiltins() < 0)) {...} /*--- Constants init code ---*/ if (unlikely(__Pyx_InitCachedConstants() < 0)) {...} ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 09:35:15 2012 From: report at bugs.python.org (Stefan Behnel) Date: Sun, 12 Aug 2012 07:35:15 +0000 Subject: [issue15623] Init time relative imports no longer work from __init__.so modules In-Reply-To: <1344697325.25.0.880049566038.issue15623@psf.upfronthosting.co.za> Message-ID: <1344756915.62.0.620352710233.issue15623@psf.upfronthosting.co.za> Stefan Behnel added the comment: That's the module init code, yes, including the setting of __file__ and __path__ that I mentioned (due to issue13429). Setting at least one of the two is required in previous CPython versions to make relative imports work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 11:37:43 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 12 Aug 2012 09:37:43 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344721571.39.0.0129155211751.issue15573@psf.upfronthosting.co.za> Message-ID: <20120812093743.GA32417@sleipnir.bytereef.org> Stefan Krah added the comment: Martin v. L??wis wrote: > Here is a more formal definition of my last proposal, > > v and w are equal iff > v.shape() == w.shape() and > ((v.format == w.format and v.tobytes() == w.tobytes()) or > v.tolist() == w.tolist()) > if tolist raises an exception for unsupported codes, they are not equal This wouldn't solve the NaN problem though: >>> nd = ndarray([(1,2)], shape=[1], format='dd', flags=ND_WRITABLE) >>> nd[0] = (float('nan'), float('nan')) >>> m = memoryview(nd) >>> m == nd True What's the policy on importing modules in the Object/* hierarchy? Can we import _struct? The current unpack_cmp() function for identical single native format codes is very fast. The only thing that would be needed to make it general is to replace default: return -1; with default: return unpack_cmp_struct(); The code is already there in _testbuffer.c. _testbuffer.c itself has 100% code coverage (including all error conditions with a special patch). This means that all tests are already present in test_buffer.py. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 11:42:28 2012 From: report at bugs.python.org (Georg Brandl) Date: Sun, 12 Aug 2012 09:42:28 +0000 Subject: [issue15623] Init time relative imports no longer work from __init__.so modules In-Reply-To: <1344697325.25.0.880049566038.issue15623@psf.upfronthosting.co.za> Message-ID: <1344764548.91.0.120056572487.issue15623@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- priority: normal -> deferred blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 11:47:00 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 12 Aug 2012 09:47:00 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <20120812093743.GA32417@sleipnir.bytereef.org> Message-ID: <20120812094702.GA32502@sleipnir.bytereef.org> Stefan Krah added the comment: To be specific, after a quick look the only function from _testbuffer.c that would be needed is unpack_single(). This really does not look very complex. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 11:55:38 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 12 Aug 2012 09:55:38 +0000 Subject: [issue15589] Bus error on Debian sparc In-Reply-To: <1344417411.0.0.396332340112.issue15589@psf.upfronthosting.co.za> Message-ID: <1344765338.92.0.585648907251.issue15589@psf.upfronthosting.co.za> Stefan Krah added the comment: Closing since the remaining issue is almost certainly a platform bug. ---------- keywords: -3.2regression, patch resolution: -> wont fix stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 12:37:56 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 12 Aug 2012 10:37:56 +0000 Subject: [issue15626] unittest.main negates -bb option and programmatic warning configuration In-Reply-To: <1344730376.57.0.519562827761.issue15626@psf.upfronthosting.co.za> Message-ID: <1344767876.28.0.58517656376.issue15626@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +michael.foord versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 12:44:00 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 12 Aug 2012 10:44:00 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1344768240.12.0.618879773058.issue15573@psf.upfronthosting.co.za> Nick Coghlan added the comment: We do import modules in the Object/* code if we really need to (Grep for "PyImport_Import" in the Objects dir) It seems to me like this case is rapidly reaching (or has even gone well past) the point where that's the sensible thing to do. A couple of key issues of concern are: - the number of modules implicitly imported at startup - the risk of attempting to import a module before the import system (and the interpreter in general) is fully initialised A simple trick for alleviating both concerns is to call PyImport_Import directly in the code path that needs it. It will be pretty quick if it gets a hit in the sys.modules cache, and most of the builtin objects aren't *used* until well after the interpreter is fully initialised (and, in the case of memoryview equality comparisons, often won't be used at all). The main alternative is to invert the dependency: move the desired functionality into a private API function and have the standard library extension module access it that way. This can end up being harder to maintain, though, and certainly isn't appropriate in this case (since "_struct.unpack_from" needs the full struct machinery to do the job). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 12:59:12 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 12 Aug 2012 10:59:12 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344768240.12.0.618879773058.issue15573@psf.upfronthosting.co.za> Message-ID: <20120812105913.GA599@sleipnir.bytereef.org> Stefan Krah added the comment: Thanks, Nick. I'll work on a struct module patch then. At this point for me this is the only satisfying solution. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 14:21:22 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 12 Aug 2012 12:21:22 +0000 Subject: [issue10848] Move test.regrtest from getopt to argparse In-Reply-To: <1294353259.48.0.852026284896.issue10848@psf.upfronthosting.co.za> Message-ID: <1344774082.04.0.15176066976.issue10848@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I just discovered that issue 15302, which has a patch awaiting review from a month ago as well as some discussion, is a duplicate of this issue. Would it be possible to leave that issue open (retitling either or both issues if necessary to avoid overlap)? The discussion here seems broader in certain ways (e.g. discussing the behavior of certain options, pre-requisites for end-to-end testing of regrtest, adding a --more-help option, etc). The patch in issue 15302 is narrower in that it handles testing via dependency injection so that main() can remain largely unaffected. I could propose such a retitling. > What about putting the addition option details in the epilog? By the way, David, I did use epilog in my patch there (without having seen this thread). :) ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 14:21:46 2012 From: report at bugs.python.org (STINNER Victor) Date: Sun, 12 Aug 2012 12:21:46 +0000 Subject: [issue7652] Merge C version of decimal into py3k. In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za> Message-ID: <1344774106.36.0.0260476829665.issue7652@psf.upfronthosting.co.za> STINNER Victor added the comment: Is there some remaining work on this issue? Or can it be closed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 14:36:37 2012 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 12 Aug 2012 12:36:37 +0000 Subject: [issue15627] Add a method to importlib.abc.SourceLoader for converting source to a code object In-Reply-To: <1344732276.83.0.543554641885.issue15627@psf.upfronthosting.co.za> Message-ID: <1344774997.33.0.419473857611.issue15627@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 14:48:16 2012 From: report at bugs.python.org (Berker Peksag) Date: Sun, 12 Aug 2012 12:48:16 +0000 Subject: [issue10486] http.server doesn't set all CGI environment variables In-Reply-To: <1290325295.78.0.545647251788.issue10486@psf.upfronthosting.co.za> Message-ID: <1344775696.68.0.257773363109.issue10486@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- versions: +Python 3.3 -Python 2.6, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 14:52:29 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 12 Aug 2012 12:52:29 +0000 Subject: [issue7652] Merge C version of decimal into py3k. In-Reply-To: <1344774106.36.0.0260476829665.issue7652@psf.upfronthosting.co.za> Message-ID: <20120812125229.GA1184@sleipnir.bytereef.org> Stefan Krah added the comment: I'm almost done with my (second) self-review of mpdecimal.c. The only functions missing are all Karatsuba functions and mpd_qpowmod(). If there are any takers, I would be very happy. For the Karatsuba functions you'll probably need Roman Maeder's paper, which I could send to anyone interested. All I can promise is that it's a beautiful formulation of the algorithm. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 14:53:43 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Sun, 12 Aug 2012 12:53:43 +0000 Subject: [issue15605] Explain sphinx documentation building in devguide In-Reply-To: <1344533769.31.0.609415214451.issue15605@psf.upfronthosting.co.za> Message-ID: <1344776023.31.0.531079862591.issue15605@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 15:54:20 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 12 Aug 2012 13:54:20 +0000 Subject: [issue15629] Run doctests in Doc/*.rst as part of regrtest Message-ID: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za> New submission from Chris Jerdonek: This issue is to start running (at least some of) the doctests in the Doc/ folder's *.rst files as part of regrtest. We will need a whitelist mechanism to tell regrtest which files to process since currently many doctests are not runnable (e.g. some kind of "doctest-safe" marker that can go in a file as suggested by Nick). See also the discussion thread started here: http://mail.python.org/pipermail/python-dev/2012-August/121304.html ---------- assignee: docs at python components: Documentation messages: 168036 nosy: cjerdonek, docs at python priority: normal severity: normal status: open title: Run doctests in Doc/*.rst as part of regrtest type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 16:00:08 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Sun, 12 Aug 2012 14:00:08 +0000 Subject: [issue15629] Run doctests in Doc/*.rst as part of regrtest In-Reply-To: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za> Message-ID: <1344780008.33.0.441983446438.issue15629@psf.upfronthosting.co.za> Richard Oudkerk added the comment: Might it be simpler to run doctest over the rst file from the relevant unittest? (Perhaps with help from test.support.) ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 16:04:02 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 12 Aug 2012 14:04:02 +0000 Subject: [issue15629] Run doctests in Doc/*.rst as part of regrtest In-Reply-To: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za> Message-ID: <1344780242.45.0.913812867436.issue15629@psf.upfronthosting.co.za> Chris Jerdonek added the comment: One option for whitelisting files would be to subclass doctest.DocTestParser and pass an instance as the parser argument to doctest.DocFileSuite: http://docs.python.org/dev/library/doctest.html#doctest.DocFileSuite The custom parser could look for the per-file marker before falling back to the usual parsing logic. This would give us the functionality we need without having to make changes to doctest. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 16:13:33 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 12 Aug 2012 14:13:33 +0000 Subject: [issue15629] Run doctests in Doc/*.rst as part of regrtest In-Reply-To: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za> Message-ID: <1344780813.18.0.630652368038.issue15629@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > Might it be simpler to run doctest over the rst file from the relevant unittest? (Perhaps with help from test.support.) If I understand correctly, do you mean for example that Lib/test/test_textwrap.py could be responsible for loading the doctests in Doc/library/textwrap.rst? One problem with this approach is that the *.rst files are not in one-to-one correspondence with unittest files in Lib/test, etc. For example, there are folders of *.rst files that may not correspond to any unit test files (e.g. the tutorial folder). It also introduces more coupling because the unit tests would now have to know about the existence of the Doc/*.rst files (though this could be a nice addition as it would let you run the doctests for a module along with its unit tests if you wanted to run tests only for a particular module). Or did you mean something else? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 16:26:09 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 12 Aug 2012 14:26:09 +0000 Subject: [issue15629] Run doctests in Doc/*.rst as part of regrtest In-Reply-To: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za> Message-ID: <1344781569.69.0.155099367756.issue15629@psf.upfronthosting.co.za> Ezio Melotti added the comment: I'm not sure running these tests as part of regrtest is a good idea. Fixing and/or marking the doctests is a good idea, and having a `make doctest` that reports no error is a desirable goal. When `make doctest` works we could think about adding a regrtest option to run the doctests too, and if these tests don't take too much extra time to run we might even consider to run them by default (or at least when -uall is specified). Having an option to run individual doctests would be nice too, and would encourage developers to test their doctests. You should also see if there are more doctest-safe or more doctest-unsafe tests, and mark the ones in the smallest group. ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 16:34:30 2012 From: report at bugs.python.org (Anton Barkovsky) Date: Sun, 12 Aug 2012 14:34:30 +0000 Subject: [issue15557] Tests for webbrowser module In-Reply-To: <1344102778.31.0.864118033074.issue15557@psf.upfronthosting.co.za> Message-ID: <1344782070.83.0.262155222901.issue15557@psf.upfronthosting.co.za> Anton Barkovsky added the comment: Thanks for the review, I've updated the patch. ---------- Added file: http://bugs.python.org/file26774/test_webbrowser_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 16:35:22 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 12 Aug 2012 14:35:22 +0000 Subject: [issue15629] Run doctests in Doc/*.rst as part of regrtest In-Reply-To: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za> Message-ID: <1344782122.97.0.55534910852.issue15629@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > I'm not sure running these tests as part of regrtest is a good idea. Can you provide reasons? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 16:35:34 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 12 Aug 2012 14:35:34 +0000 Subject: [issue15629] Run doctests in Doc/*.rst as part of regrtest In-Reply-To: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za> Message-ID: <1344782134.47.0.273788617967.issue15629@psf.upfronthosting.co.za> Ezio Melotti added the comment: > If I understand correctly, do you mean for example that > Lib/test/test_textwrap.py could be responsible for loading > the doctests in Doc/library/textwrap.rst? One advantage of this is that I could explicitly add a test in test_textwrap.py that loads the doctests in textwrap.rst and runs them. This would allow me to decide if those tests should be run or not, and which ones are runnable. If I know that textwrap.rst has no runnable tests I won't add the test, so by simply running test_textwrap I would be running all the tests I want/need to run. OTOH this has disadvantages too. If the tests are loaded explicitly it means that every test file that wants to load the doctests should be modified. Even if foo.rst has no runnable doctests and no test to load them is added to test_foo.py, a `make doctest` might still include the file unless we mark it in some way (either by a module-wide directive, or by marking all the individual snippets of code). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 16:44:50 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 12 Aug 2012 14:44:50 +0000 Subject: [issue15629] Run doctests in Doc/*.rst as part of regrtest In-Reply-To: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za> Message-ID: <1344782690.13.0.227386426217.issue15629@psf.upfronthosting.co.za> Ezio Melotti added the comment: > Can you provide reasons? Regrtest takes already a few minutes to run, adding these tests will make it even slower and the tradeoff might not be worthwhile (I'm assuming that most of the doctests are basic examples that are already well tested, and the occasional typos can be found by simply run `make doctest` every once in a while). The tests currently have many failures and output, so adding them now will make the regrtest output more confusing. Integrating this with regrtest requires some work, for example you would have to count successes/failures, add skips for certain tests and resources to control what tests should be run (there's currently a turtle going around on my screen when I run `make doctest`). This will make regrtest even more complex. People might not care to run these doctests if they are not touching the docs, and if they are, they might prefer to check only the specific doc file they changed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 17:05:17 2012 From: report at bugs.python.org (Georg Brandl) Date: Sun, 12 Aug 2012 15:05:17 +0000 Subject: [issue15629] Run doctests in Doc/*.rst as part of regrtest In-Reply-To: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za> Message-ID: <1344783917.06.0.509652908849.issue15629@psf.upfronthosting.co.za> Georg Brandl added the comment: One possibility to avoid tons and tons of failures that have to be fixed is to convert working doctests to the explicit syntax .. doctest:: blah and set doctest_test_doctest_blocks to False in the Sphinx conf.py. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 17:20:02 2012 From: report at bugs.python.org (Floris Bruynooghe) Date: Sun, 12 Aug 2012 15:20:02 +0000 Subject: [issue15617] FAIL: test_create_connection (test.test_socket.NetworkConnectionNoServer) In-Reply-To: <1344704047.36.0.564235777532.issue15617@psf.upfronthosting.co.za> Message-ID: Floris Bruynooghe added the comment: I have no issue with changing the buildhost's zone configuration if that's the right thing to do. Just one more option. Is widening the expected errno in the test a valid thing to do? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 17:28:38 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Sun, 12 Aug 2012 15:28:38 +0000 Subject: [issue15629] Run doctests in Doc/*.rst as part of regrtest In-Reply-To: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za> Message-ID: <1344785318.8.0.178920715365.issue15629@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > the occasional typos can be found by simply run `make doctest` every once > in a while). But doesn't "make doctest" attempt to run the doctests using Python 2.x (because Sphinx does not support Python 3.x). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 17:35:06 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Sun, 12 Aug 2012 15:35:06 +0000 Subject: [issue15629] Run doctests in Doc/*.rst as part of regrtest In-Reply-To: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za> Message-ID: <1344785706.67.0.0912356561998.issue15629@psf.upfronthosting.co.za> Richard Oudkerk added the comment: An example from the output of "make doctest" which fails because Python 2.x is being used: ********************************************************************** File "library/multiprocessing.rst", line 453, in default Failed example: print(p, p.is_alive()) Expected: False Got: (, False) ********************************************************************** ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 17:38:48 2012 From: report at bugs.python.org (Daniel Ellis) Date: Sun, 12 Aug 2012 15:38:48 +0000 Subject: [issue15630] Missing "continue" example for "for" loop tutorial Message-ID: <1344785928.67.0.868408879756.issue15630@psf.upfronthosting.co.za> New submission from Daniel Ellis: Found by Jesse Bikman: On this page, http://docs.python.org/tutorial/controlflow.html there is no example in the code of a "continue" statement (section 4.4). It is explained, but not actually used in code. ---------- assignee: docs at python components: Documentation messages: 168049 nosy: Daniel.Ellis, docs at python priority: normal severity: normal status: open title: Missing "continue" example for "for" loop tutorial _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 18:07:36 2012 From: report at bugs.python.org (Georg Brandl) Date: Sun, 12 Aug 2012 16:07:36 +0000 Subject: [issue15629] Run doctests in Doc/*.rst as part of regrtest In-Reply-To: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za> Message-ID: <1344787656.29.0.0751298664134.issue15629@psf.upfronthosting.co.za> Georg Brandl added the comment: Yeah, once we switch around to using the build Python for this... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 18:15:28 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 12 Aug 2012 16:15:28 +0000 Subject: [issue15629] Run doctests in Doc/*.rst as part of regrtest In-Reply-To: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za> Message-ID: <1344788128.11.0.158205466055.issue15629@psf.upfronthosting.co.za> ?ric Araujo added the comment: Using Python 3 to run Sphinx is tracked in #10224. I thought there was already an issue to make the doctests runnable but can't find it, maybe it was only a discussion on a mailing list a year or two ago. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 18:30:19 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 12 Aug 2012 16:30:19 +0000 Subject: [issue15557] Tests for webbrowser module In-Reply-To: <1344102778.31.0.864118033074.issue15557@psf.upfronthosting.co.za> Message-ID: <1344789019.95.0.45058736195.issue15557@psf.upfronthosting.co.za> Chris Jerdonek added the comment: It still seems like things could be made more DRY. Also, the pattern of having assert_unix_browser() execute various function blocks depending on whether various arguments are not None doesn't seem as clean or scalable as it should be (e.g. if the number of assert statements were to grow). What about defining helper methods like check_open(), check_open_new_tab(), and check_open_new(), and then having the various test_() methods call each of them as appropriate? For example-- + browser.open_new('http://www.example.com/') + args = popen.cmd_line + self.assertEqual(args, ['test', '-raise', '-remote', + 'openURL(http://www.example.com/,new-window)']) could become a call to check_open_new(). The helper methods could default to the most common string arguments so that you will only need to define and pass the string arguments when the browser uses strings that are different from the defaults. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 18:39:49 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 12 Aug 2012 16:39:49 +0000 Subject: [issue15623] Init time relative imports no longer work from __init__.so modules In-Reply-To: <1344697325.25.0.880049566038.issue15623@psf.upfronthosting.co.za> Message-ID: <1344789589.81.0.711869059227.issue15623@psf.upfronthosting.co.za> Brett Cannon added the comment: I don't have time to delve into C debugging right now, but the question is what changed between 3.2 and 3.3 in terms of when an extension module is inserted into sys.modules since that is the issue ATM. Probably some time in gdb starting in the module's init code and following it to when it is inserted into sys.modules should answer the question (hopefully). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 18:44:25 2012 From: report at bugs.python.org (Daniel Ellis) Date: Sun, 12 Aug 2012 16:44:25 +0000 Subject: [issue15630] Missing "continue" example for "for" loop tutorial In-Reply-To: <1344785928.67.0.868408879756.issue15630@psf.upfronthosting.co.za> Message-ID: <1344789865.75.0.0653863389628.issue15630@psf.upfronthosting.co.za> Daniel Ellis added the comment: Added basic example for "continue". ---------- keywords: +patch Added file: http://bugs.python.org/file26775/for_continue_doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 19:03:24 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 12 Aug 2012 17:03:24 +0000 Subject: [issue15630] Missing "continue" example for "for" loop tutorial In-Reply-To: <1344785928.67.0.868408879756.issue15630@psf.upfronthosting.co.za> Message-ID: <1344791004.91.0.478214197005.issue15630@psf.upfronthosting.co.za> Raymond Hettinger added the comment: This looks good. Please remove the "... " prompt from the example so that the code is cut-and-pasteable by people who want to experiment with the example. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 19:08:13 2012 From: report at bugs.python.org (Daniel Ellis) Date: Sun, 12 Aug 2012 17:08:13 +0000 Subject: [issue15630] Missing "continue" example for "for" loop tutorial In-Reply-To: <1344785928.67.0.868408879756.issue15630@psf.upfronthosting.co.za> Message-ID: <1344791293.09.0.554631326281.issue15630@psf.upfronthosting.co.za> Daniel Ellis added the comment: Oh, I was keeping with the format of the other examples in the tutorial. Should I remove the prompts from all of them? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 19:19:26 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 12 Aug 2012 17:19:26 +0000 Subject: [issue15630] Missing "continue" example for "for" loop tutorial In-Reply-To: <1344785928.67.0.868408879756.issue15630@psf.upfronthosting.co.za> Message-ID: <1344791966.4.0.232307227575.issue15630@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > Please remove the "... " prompt from the example so that the code is cut-and-pasteable by people who want to experiment with the example. That is the usual format for docstring examples. See, for example-- http://docs.python.org/dev/library/doctest.html#how-are-docstring-examples-recognized ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 19:25:49 2012 From: report at bugs.python.org (Eric Snow) Date: Sun, 12 Aug 2012 17:25:49 +0000 Subject: [issue15623] Init time relative imports no longer work from __init__.so modules In-Reply-To: <1344697325.25.0.880049566038.issue15623@psf.upfronthosting.co.za> Message-ID: <1344792349.62.0.357934623531.issue15623@psf.upfronthosting.co.za> Eric Snow added the comment: This smells like a case of where sys.modules got replaced by another mapping, but import.c continues using interp->modules. I won't be able to investigate until tomorrow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 19:41:46 2012 From: report at bugs.python.org (Georg Brandl) Date: Sun, 12 Aug 2012 17:41:46 +0000 Subject: [issue15623] Init time relative imports no longer work from __init__.so modules In-Reply-To: <1344697325.25.0.880049566038.issue15623@psf.upfronthosting.co.za> Message-ID: <1344793306.75.0.385535755094.issue15623@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 19:58:24 2012 From: report at bugs.python.org (ita1024) Date: Sun, 12 Aug 2012 17:58:24 +0000 Subject: [issue15631] Python 3.3 beta 1 installation issue lib/lib64 folders Message-ID: <1344794304.26.0.478120841355.issue15631@psf.upfronthosting.co.za> New submission from ita1024: On opensuse 12.1, python 3.3 installs its extensions in /usr/local/lib64/python3.3/lib-dynload/, but the .py files are in /usr/local/lib/python3.3/. When launching python 3.3 one gets: Could not find platform dependent libraries Consider setting $PYTHONHOME to [:] Python 3.3.0b1 (default, Aug 11 2012, 10:45:34) [GCC 4.6.2] on linux Type "help", "copyright", "credits" or "license" for more information. Traceback (most recent call last): File "/etc/pythonstart", line 5, in import atexit File "", line 1294, in _find_and_load File "", line 1258, in _find_and_load_unlocked ImportError: No module named 'atexit' The same thing happens when installing with a --prefix. Moving the directory lib64/python3.3/lib-dynload to lib/python3.3/lib-dynload fixes the problem. ---------- components: Build messages: 168059 nosy: ita1024 priority: normal severity: normal status: open title: Python 3.3 beta 1 installation issue lib/lib64 folders versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 20:16:20 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 12 Aug 2012 18:16:20 +0000 Subject: [issue15627] Add a method to importlib.abc.SourceLoader for converting source to a code object In-Reply-To: <1344732276.83.0.543554641885.issue15627@psf.upfronthosting.co.za> Message-ID: <1344795380.12.0.447222445249.issue15627@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 20:16:49 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 12 Aug 2012 18:16:49 +0000 Subject: [issue15628] Add import ABC hierarchy to docs for importlib In-Reply-To: <1344737242.66.0.0570077478746.issue15628@psf.upfronthosting.co.za> Message-ID: <1344795409.03.0.698668604917.issue15628@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 20:22:39 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 12 Aug 2012 18:22:39 +0000 Subject: [issue15631] Python 3.3 beta 1 installation issue lib/lib64 folders In-Reply-To: <1344794304.26.0.478120841355.issue15631@psf.upfronthosting.co.za> Message-ID: <1344795759.2.0.765310695819.issue15631@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 21:09:41 2012 From: report at bugs.python.org (Anton Barkovsky) Date: Sun, 12 Aug 2012 19:09:41 +0000 Subject: [issue15557] Tests for webbrowser module In-Reply-To: <1344102778.31.0.864118033074.issue15557@psf.upfronthosting.co.za> Message-ID: <1344798581.93.0.568716617264.issue15557@psf.upfronthosting.co.za> Anton Barkovsky added the comment: Updated, added separate helper methods and 'test' and 'http://www.example.com/' are no longer hardcoded. > The helper methods could default to the most common string arguments so that you will only need to define and pass the string arguments when the browser uses strings that are different from the defaults. I don't see a good reason to provide defaults. If some browsers have same arguments it's just a coincidence, the arguments are not likely to ever change, and I don't like when a test case is scattered all over the module in the form of defaults. ---------- Added file: http://bugs.python.org/file26776/test_webbrowser_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 21:15:43 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 Aug 2012 19:15:43 +0000 Subject: [issue15630] Missing "continue" example for "for" loop tutorial In-Reply-To: <1344785928.67.0.868408879756.issue15630@psf.upfronthosting.co.za> Message-ID: <3Ww8t56169zPm3@mail.python.org> Roundup Robot added the comment: New changeset a4d5ac78a76b by Senthil Kumaran in branch '2.7': Issue #15630: Add an example for "continue" statement in the tutorial. Patch by http://hg.python.org/cpython/rev/a4d5ac78a76b New changeset e855e6c26dfb by Senthil Kumaran in branch '3.2': Issue #15630: Add an example for "continue" statement in the tutorial. Patch by http://hg.python.org/cpython/rev/e855e6c26dfb New changeset dd41c287cf7c by Senthil Kumaran in branch 'default': merge from 3.2 http://hg.python.org/cpython/rev/dd41c287cf7c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 21:16:41 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 12 Aug 2012 19:16:41 +0000 Subject: [issue15630] Missing "continue" example for "for" loop tutorial In-Reply-To: <1344785928.67.0.868408879756.issue15630@psf.upfronthosting.co.za> Message-ID: <1344799001.04.0.290809172371.issue15630@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Thanks for the patch, Daniel. Fixed in all versions. ---------- nosy: +orsenthil resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 21:31:46 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 12 Aug 2012 19:31:46 +0000 Subject: [issue15632] regrtest.py: spurious leaks with -R option Message-ID: <1344799906.56.0.0975538971998.issue15632@psf.upfronthosting.co.za> New submission from Stefan Krah: With the -R option, test_buffer.py needs an additional warm-up for the unicode_latin1 cache. Patch attached. ---------- components: Tests files: warm_latin1_cache.diff keywords: patch messages: 168063 nosy: skrah priority: normal severity: normal stage: patch review status: open title: regrtest.py: spurious leaks with -R option type: behavior versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file26777/warm_latin1_cache.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 21:52:08 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 12 Aug 2012 19:52:08 +0000 Subject: [issue15631] Python 3.3 beta 1 installation issue lib/lib64 folders In-Reply-To: <1344794304.26.0.478120841355.issue15631@psf.upfronthosting.co.za> Message-ID: <1344801128.38.0.722483707471.issue15631@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 21:56:24 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 12 Aug 2012 19:56:24 +0000 Subject: [issue15557] Tests for webbrowser module In-Reply-To: <1344102778.31.0.864118033074.issue15557@psf.upfronthosting.co.za> Message-ID: <1344801384.9.0.0538765677427.issue15557@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Thanks, Anton. It is looking a lot better now. I still have comments, but because my comments have not been on the substance of the patch and because I am not a core developer, I will defer to others at this point. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 23:23:37 2012 From: report at bugs.python.org (Meador Inge) Date: Sun, 12 Aug 2012 21:23:37 +0000 Subject: [issue15632] regrtest.py: spurious leaks with -R option In-Reply-To: <1344799906.56.0.0975538971998.issue15632@psf.upfronthosting.co.za> Message-ID: <1344806617.6.0.415838787712.issue15632@psf.upfronthosting.co.za> Meador Inge added the comment: I know the title says spurious, but is there a way to reproduce this at all? Can I run a certain suite N times or something? How did you find the problem? ---------- nosy: +meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 23:33:44 2012 From: report at bugs.python.org (Meador Inge) Date: Sun, 12 Aug 2012 21:33:44 +0000 Subject: [issue15627] Add a method to importlib.abc.SourceLoader for converting source to a code object In-Reply-To: <1344732276.83.0.543554641885.issue15627@psf.upfronthosting.co.za> Message-ID: <1344807224.79.0.362829552434.issue15627@psf.upfronthosting.co.za> Changes by Meador Inge : ---------- nosy: +meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 12 23:34:29 2012 From: report at bugs.python.org (Meador Inge) Date: Sun, 12 Aug 2012 21:34:29 +0000 Subject: [issue15623] Init time relative imports no longer work from __init__.so modules In-Reply-To: <1344697325.25.0.880049566038.issue15623@psf.upfronthosting.co.za> Message-ID: <1344807269.54.0.618573096314.issue15623@psf.upfronthosting.co.za> Changes by Meador Inge : ---------- nosy: +meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 00:36:27 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 12 Aug 2012 22:36:27 +0000 Subject: [issue15632] regrtest.py: spurious leaks with -R option In-Reply-To: <1344799906.56.0.0975538971998.issue15632@psf.upfronthosting.co.za> Message-ID: <1344810987.5.0.762502688865.issue15632@psf.upfronthosting.co.za> Stefan Krah added the comment: I'm attaching a test case. You're right, in test_buffer it's hard to reproduce but I've encountered the "leak" several times in the past months. Today I realized that the "leak" always occurred with format code 'c'. There's this passage in test_buffer: x = randrange(*fmtdict[mode][char]) if char == 'c': x = bytes(chr(x), 'latin1') After some head scratching I looked into regrtest.py and found the warm_char_cache() function. The whole thing makes sense: In each repetition of the refleak mode new characters can be added to the unicode_latin1 cache. So, you should be able to reproduce the issue: $ ./python -m test -uall -R 2:2 test_pseudo_leak [1/1] test_pseudo_leak beginning 4 repetitions 1234 .... test_pseudo_leak leaked [8, 8] references, sum=16 1 test failed: test_pseudo_leak [151225 refs] ---------- Added file: http://bugs.python.org/file26778/test_pseudo_leak.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 01:49:38 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 12 Aug 2012 23:49:38 +0000 Subject: [issue15629] Run doctests in Doc/*.rst as part of regrtest In-Reply-To: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za> Message-ID: <1344815378.73.0.881562459978.issue15629@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 02:58:39 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 13 Aug 2012 00:58:39 +0000 Subject: [issue15629] Run doctests in Doc/*.rst as part of regrtest In-Reply-To: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za> Message-ID: <1344819519.47.0.999764124861.issue15629@psf.upfronthosting.co.za> R. David Murray added the comment: The point of running the doctests in the docs to to make sure the *docs* are correct, not to make sure Python is correct. So IMO adding them to regrtest is much more trouble than the tiny benefit it would produce for test coverage. On the other hand, having 'make doctest' run when '-uall' is specified would be cool, if the tests can thus be run by the buildbots. But I think should be 'make doctest', and not regrtest using doctest to process .rst files. The reason is that Sphinx has extra facilities that allow docttests to work without having to have "boilerplate" code in places where doing so would disrupt the narrative flow. I could be mis-remembering (and Georg will correct me if I am misremembering again :), but I don't think those work when doctest is used directly against the .rst file. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 03:31:03 2012 From: report at bugs.python.org (Nikolaus Rath) Date: Mon, 13 Aug 2012 01:31:03 +0000 Subject: [issue15633] httplib.response is not closed after all data has been read Message-ID: <1344821463.76.0.139090148106.issue15633@psf.upfronthosting.co.za> New submission from Nikolaus Rath: Occasionally, the isclosed() method of HTTPResponse instances returns False, even though a preceding read() call returned '' (or something else that evalues to False). This is a problem, because then the corresponding HTTPConnection can still be used to send another request, but an attempt to retrieve its response result it in ResponseNotReady() exception. I have not found anything special about the requests for which this happens. I also looked at the httplib code and found no way for this to happen, but obviously I am missing something. Maybe someone more familiar with the codebase can tell what's happening there. The problem happens to rarely to be able to run packet capture, but I can provide attributes of the relevant httplib instances if desired. ---------- components: Library (Lib) messages: 168068 nosy: Nikratio priority: normal severity: normal status: open title: httplib.response is not closed after all data has been read type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 04:26:41 2012 From: report at bugs.python.org (Glenn Linderman) Date: Mon, 13 Aug 2012 02:26:41 +0000 Subject: [issue15629] Run doctests in Doc/*.rst as part of regrtest In-Reply-To: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za> Message-ID: <1344824801.65.0.584050534154.issue15629@psf.upfronthosting.co.za> Glenn Linderman added the comment: Another idea would be to make a notation that looks exactly* like doctests for documentation purposes, but that doctest would not run. Then, non-runnable doctests could be skipped, and runnable ones could be run. This would help keep the runnable code in the documentation validated, but would be on a test-by-test basis, rather than file by file. ---------- nosy: +v+python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 09:51:59 2012 From: report at bugs.python.org (Simon Sapin) Date: Mon, 13 Aug 2012 07:51:59 +0000 Subject: [issue13742] Add a key parameter (like sorted) to heapq.merge In-Reply-To: <1326105342.42.0.0197399269422.issue13742@psf.upfronthosting.co.za> Message-ID: <1344844319.67.0.307876682061.issue13742@psf.upfronthosting.co.za> Simon Sapin added the comment: I just remembered about this. I suppose it is too late for 3.3? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 10:04:28 2012 From: report at bugs.python.org (Juan Javier) Date: Mon, 13 Aug 2012 08:04:28 +0000 Subject: [issue15634] synchronized decorator for the threading module Message-ID: <1344845068.87.0.536585589553.issue15634@psf.upfronthosting.co.za> New submission from Juan Javier: I think it will be useful to have a decorator like this one on the threading module: def synchronized(func): """A decorator to make a function execution synchronized. Examples: @synchronized def foo(): pass class Foo: def __init__(self): self.__syncdata = None @property def syncdata(self): return self.__syncdata @syncdata.setter @synchronized def syncdata(self, value): self.__syncdata = value """ if not hasattr(func, "__lock"): func.__lock = threading.Lock() def _synchronized(*args, **kwds): with func.__lock: func(*args, **kwds) _synchronized.__doc__ = func.__doc__ return _synchronized What do you think? ---------- components: Library (Lib) messages: 168071 nosy: jjdominguezm priority: normal severity: normal status: open title: synchronized decorator for the threading module type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 11:25:31 2012 From: report at bugs.python.org (Florent Xicluna) Date: Mon, 13 Aug 2012 09:25:31 +0000 Subject: [issue15635] memory leak with generators Message-ID: <1344849931.31.0.449386115809.issue15635@psf.upfronthosting.co.za> New submission from Florent Xicluna: Hello, I noticed a large memory consumption in my application. I tracked it down to be a problem with garbage collection of generator locals. The issue was noticed in 2.6 first. Then I reproduced it in 2.7. The test case finds some leak in 3.3 too, it seems. ---------- components: Interpreter Core files: testiterbug.py messages: 168072 nosy: flox priority: normal severity: normal status: open title: memory leak with generators type: resource usage versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file26779/testiterbug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 11:40:13 2012 From: report at bugs.python.org (patrick vrijlandt) Date: Mon, 13 Aug 2012 09:40:13 +0000 Subject: [issue15564] cgi.FieldStorage should not call read_multi on files In-Reply-To: <1344245506.28.0.499641288303.issue15564@psf.upfronthosting.co.za> Message-ID: <1344850813.37.0.616127923048.issue15564@psf.upfronthosting.co.za> patrick vrijlandt added the comment: I must admit my usage case is a hack, but the summary is: view a page on one computer, process it on another computer; like sending the page to a friend, with friend -> self and send -> upload. I found one other victim in python (https://groups.google.com/d/topic/web2py/ixeUUWryZh0/discussion) but only an occasional reference to other languages; most posts relate to security issues with mht files. My previous example only served to show that the mime-type is a necessary condition for the problem to occur; you are right that this input would be expected to throw an exception. So I went on and created a complete testcase/example (attached). The PatchedFieldStorage class parses the mht file correctly into parts. However, the names of the parts are in "content-location" headers inside the mht file and get lost. Also the code is ugly. Trying to better re-use existing code like in ExperimentalFieldStorage was not succesful so far: The MIME-prologue is parsed as one of the parts, and the outerboundary is not respected, losing a dataelement "next to" the file. The print() calls show that the next line may be valuable (like a header) or not so much (like a boundary), but so far the class has no provision for look-ahead I think. email.message_from_binary_file correctly parses my mht-files; so a completely different approach might be to more rely on that package for parsing MIME encoded data. ---------- Added file: http://bugs.python.org/file26780/test_cgi4.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 11:43:58 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 13 Aug 2012 09:43:58 +0000 Subject: [issue15624] clarify io.TextIOWrapper newline documentation In-Reply-To: <1344712464.43.0.600420981046.issue15624@psf.upfronthosting.co.za> Message-ID: <1344851038.08.0.502151505573.issue15624@psf.upfronthosting.co.za> Andrew Svetlov added the comment: For me input means ?reading from? and output ? ?writing to?. Nevertheless I'm ok with you suggestion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 11:57:15 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 13 Aug 2012 09:57:15 +0000 Subject: [issue15624] clarify newline documentation for open and io.TextIOWrapper. In-Reply-To: <1344712464.43.0.600420981046.issue15624@psf.upfronthosting.co.za> Message-ID: <1344851835.96.0.966778114507.issue15624@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- title: clarify io.TextIOWrapper newline documentation -> clarify newline documentation for open and io.TextIOWrapper. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 12:00:05 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 13 Aug 2012 10:00:05 +0000 Subject: [issue15624] clarify newline documentation for open and io.TextIOWrapper. In-Reply-To: <1344712464.43.0.600420981046.issue15624@psf.upfronthosting.co.za> Message-ID: <3WwXVX4FVszPjy@mail.python.org> Roundup Robot added the comment: New changeset 5b629e9fde61 by Andrew Svetlov in branch '3.2': Issue #15624: clarify newline documentation for open and io.TextIOWrapper http://hg.python.org/cpython/rev/5b629e9fde61 New changeset 9e098890ea2c by Andrew Svetlov in branch 'default': Issue #15624: clarify newline documentation for open and io.TextIOWrapper http://hg.python.org/cpython/rev/9e098890ea2c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 12:00:57 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 13 Aug 2012 10:00:57 +0000 Subject: [issue15624] clarify newline documentation for open and io.TextIOWrapper. In-Reply-To: <1344712464.43.0.600420981046.issue15624@psf.upfronthosting.co.za> Message-ID: <1344852057.41.0.342248363532.issue15624@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Close as fixed. Thanks. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 12:10:25 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 13 Aug 2012 10:10:25 +0000 Subject: [issue8800] add threading.RWLock In-Reply-To: <1274694942.46.0.488506239249.issue8800@psf.upfronthosting.co.za> Message-ID: <1344852625.9.0.0664916857489.issue8800@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: I should add that on Windows, the new SRW that is part of Vista and Windows 7, uses locking, that is it favors neither readers or writers. It appears that nowadays the complex semantics of RWLocks have not really proven worthwile. See http://msdn.microsoft.com/en-us/magazine/cc163405.aspx Perhaps this proposed patch is overly complex. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 12:11:40 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 13 Aug 2012 10:11:40 +0000 Subject: [issue15629] Run doctests in Doc/*.rst as part of regrtest In-Reply-To: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za> Message-ID: <1344852700.17.0.912507802212.issue15629@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 12:19:54 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Mon, 13 Aug 2012 10:19:54 +0000 Subject: [issue13498] os.makedirs exist_ok documentation is incorrect, as is some of the behavior In-Reply-To: <1322574123.12.0.756700598965.issue13498@psf.upfronthosting.co.za> Message-ID: <1344853194.47.0.215076877949.issue13498@psf.upfronthosting.co.za> Hynek Schlawack added the comment: Silence means consent, so I will supply a patch as soon as 3.4 is open. Meanwhile, I reworded the docs for os.makedirs, the patch is attached. Please have a look at it so we can get it in for 3.3. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file26781/os-makedirs.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 13:29:27 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 13 Aug 2012 11:29:27 +0000 Subject: [issue15624] clarify newline documentation for open and io.TextIOWrapper. In-Reply-To: <1344712464.43.0.600420981046.issue15624@psf.upfronthosting.co.za> Message-ID: <1344857367.2.0.976125149927.issue15624@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Thanks a lot, Andrew. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 13:47:10 2012 From: report at bugs.python.org (Andrew Scheller) Date: Mon, 13 Aug 2012 11:47:10 +0000 Subject: [issue15636] base64.decodebytes is only available in Python3.1+ Message-ID: <1344858430.17.0.615853795219.issue15636@psf.upfronthosting.co.za> New submission from Andrew Scheller: According to the documentation ( http://docs.python.org/py3k/library/base64.html#base64.decodebytes ) both the decodebytes and the deprecated decodestring methods are available in the base64 module in Python3.x However in Python3.0 (I'm testing with version 3.0.1 built from source) the base64 module only has the decodestring method, it doesn't have decodebytes. IMHO the documentation should be updated to reflect this. It looks like decodebytes was added to Python3.1 by http://bugs.python.org/issue3613 ---------- assignee: docs at python components: Documentation messages: 168080 nosy: docs at python, lurchman priority: normal severity: normal status: open title: base64.decodebytes is only available in Python3.1+ type: enhancement versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 14:04:59 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 13 Aug 2012 12:04:59 +0000 Subject: [issue15561] update subprocess docs to reference io.TextIOWrapper In-Reply-To: <1344196317.87.0.366111796882.issue15561@psf.upfronthosting.co.za> Message-ID: <1344859499.22.0.790395433734.issue15561@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Do you mean to mention stdin as well as stdout/stderr? It will be nice. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 14:07:10 2012 From: report at bugs.python.org (Florent Xicluna) Date: Mon, 13 Aug 2012 12:07:10 +0000 Subject: [issue15635] memory leak with generators In-Reply-To: <1344849931.31.0.449386115809.issue15635@psf.upfronthosting.co.za> Message-ID: <1344859630.61.0.524134776719.issue15635@psf.upfronthosting.co.za> Florent Xicluna added the comment: Though, I cannot reproduce on Debian Squeeze (2.6.6 deb or 2.7 from source) or Ubuntu (2.7.2+ or 3.2). Someone on OS X might confirm the same issue. This is python 2.7.3 installed from source (using perlbrew) and GCC 4.2.1. The output of the script is: $ python testiterbug.py 2.7.3 (default, May 20 2012, 19:54:58) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] [row for row in iterit(16777216)] Memory usage: 9.3 MB [row for row in iterit(8388608)] Memory usage: 266.6 MB ---------- nosy: +hynek, ned.deily, ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 14:08:43 2012 From: report at bugs.python.org (Florent Xicluna) Date: Mon, 13 Aug 2012 12:08:43 +0000 Subject: [issue15635] memory leak with generators In-Reply-To: <1344849931.31.0.449386115809.issue15635@psf.upfronthosting.co.za> Message-ID: <1344859723.81.0.271175764787.issue15635@psf.upfronthosting.co.za> Florent Xicluna added the comment: I don't mean perlbrew, but homebrew (an OS X package manager to install from source). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 14:13:05 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 13 Aug 2012 12:13:05 +0000 Subject: [issue15555] Default newlines of io.TextIOWrapper In-Reply-To: <1344095998.81.0.573935781933.issue15555@psf.upfronthosting.co.za> Message-ID: <1344859985.21.0.551049388001.issue15555@psf.upfronthosting.co.za> Andrew Svetlov added the comment: It doesn't. _io can be fixed to directly support os.linesep, but I doubt if anybody really need it. ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 14:15:12 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 13 Aug 2012 12:15:12 +0000 Subject: [issue15561] update subprocess docs to reference io.TextIOWrapper In-Reply-To: <1344196317.87.0.366111796882.issue15561@psf.upfronthosting.co.za> Message-ID: <1344860112.65.0.643574835569.issue15561@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Yes, that too. :) I am working on it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 14:19:14 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 13 Aug 2012 12:19:14 +0000 Subject: [issue15555] Default newlines of io.TextIOWrapper In-Reply-To: <1344095998.81.0.573935781933.issue15555@psf.upfronthosting.co.za> Message-ID: <1344860354.67.0.206184423362.issue15555@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I think it can be useful for testing reasons (e.g. testing that os.linesep is respected by certain code). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 14:20:15 2012 From: report at bugs.python.org (Alberto Milone) Date: Mon, 13 Aug 2012 12:20:15 +0000 Subject: [issue15637] Segfault reading null VMA (works fine in python 2.x) Message-ID: <1344860415.33.0.2201769173.issue15637@psf.upfronthosting.co.za> New submission from Alberto Milone: The attached test case works fine in Python 2.7 but causes Pyhton 3.2 to segfault. ---------- components: ctypes files: randr_test messages: 168087 nosy: albertomilone priority: normal severity: normal status: open title: Segfault reading null VMA (works fine in python 2.x) type: crash versions: Python 3.2 Added file: http://bugs.python.org/file26782/randr_test _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 14:22:34 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 13 Aug 2012 12:22:34 +0000 Subject: [issue15635] memory leak with generators In-Reply-To: <1344849931.31.0.449386115809.issue15635@psf.upfronthosting.co.za> Message-ID: <1344860554.47.0.183292984731.issue15635@psf.upfronthosting.co.za> Ronald Oussoren added the comment: I can reproduce this on an OSX 10.8 system, both using python 2.7 and python 3.3. The growth is significantly less using python 3.3. What's odd is that the growth does not occur when both test_iter calls use 1<<24 as the argument (or larger values). If I'd had to guess I'd say that the free implementation doesn't return a buffer to the system for smaller blocks and does do it for larger buffers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 14:23:54 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 13 Aug 2012 12:23:54 +0000 Subject: [issue15635] memory leak with generators In-Reply-To: <1344849931.31.0.449386115809.issue15635@psf.upfronthosting.co.za> Message-ID: <1344860634.81.0.627815692204.issue15635@psf.upfronthosting.co.za> Ronald Oussoren added the comment: BTW. I don't think this is a memory leak, the amount of memory used doesn't increase when there are more calls to test_iter(1<<23). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 14:29:11 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 13 Aug 2012 12:29:11 +0000 Subject: [issue15509] webbrowser.open sometimes passes zero-length argument to the browser. In-Reply-To: <1343687718.2.0.882765777761.issue15509@psf.upfronthosting.co.za> Message-ID: <1344860951.57.0.152114147032.issue15509@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Better to fix producer of empty lines than filter those ones. Keep in mind: there are several places there args list generated, probably you fix not all error sources. ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 14:31:27 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 13 Aug 2012 12:31:27 +0000 Subject: [issue15629] Run doctests in Doc/*.rst as part of regrtest In-Reply-To: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za> Message-ID: <1344861087.0.0.077139111939.issue15629@psf.upfronthosting.co.za> R. David Murray added the comment: That's exactly what Georg's suggestion is about. Sphinx does have a way to mark doctest snippets as "run this", "don't run this". I believe that requires using 'make doctest' as the runner, but I already think that is the way to go, as I said before. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 14:36:42 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 13 Aug 2012 12:36:42 +0000 Subject: [issue15638] incorrect version info for TextIOWrapper write_through docs Message-ID: <1344861402.45.0.422601843379.issue15638@psf.upfronthosting.co.za> New submission from Chris Jerdonek: The io.TextIOWrapper documentation says that the write_through argument was added in version 3.3: "Changed in version 3.3: The write_through argument has been added." http://docs.python.org/dev/library/io.html#io.TextIOWrapper However, it seems to be present in 3.2. Also, the 3.2 documentation does not mention the write_through argument. ---------- assignee: docs at python components: Documentation keywords: easy messages: 168092 nosy: asvetlov, cjerdonek, docs at python priority: normal severity: normal stage: needs patch status: open title: incorrect version info for TextIOWrapper write_through docs versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 14:40:20 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 13 Aug 2012 12:40:20 +0000 Subject: [issue13498] os.makedirs exist_ok documentation is incorrect, as is some of the behavior In-Reply-To: <1322574123.12.0.756700598965.issue13498@psf.upfronthosting.co.za> Message-ID: <1344861620.56.0.495491077768.issue13498@psf.upfronthosting.co.za> R. David Murray added the comment: Silence doesn't mean consent, but it does mean you can go ahead and see if anyone complains :) I think your proposal is fine, but I'd prefer making the sentinels just "IGNORE" and "FAIL". The module namespace means the names themselves don't have to be fully qualified. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 14:40:36 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 13 Aug 2012 12:40:36 +0000 Subject: [issue15561] update subprocess docs to reference io.TextIOWrapper In-Reply-To: <1344196317.87.0.366111796882.issue15561@psf.upfronthosting.co.za> Message-ID: <1344861636.11.0.531427110928.issue15561@psf.upfronthosting.co.za> Chris Jerdonek added the comment: For 3.2 to mention write_through, issue 15638 should probably be fixed first. I can create a patch for that first. ---------- dependencies: +incorrect version info for TextIOWrapper write_through docs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 14:42:52 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 13 Aug 2012 12:42:52 +0000 Subject: [issue15633] httplib.response is not closed after all data has been read In-Reply-To: <1344821463.76.0.139090148106.issue15633@psf.upfronthosting.co.za> Message-ID: <1344861772.74.0.483637342644.issue15633@psf.upfronthosting.co.za> R. David Murray added the comment: Without a reproducible test case I doubt we are going to be able to solve this, but yes please provide what information you can for the record, in case someone else runs in to it in a more reproducible situation. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 14:45:00 2012 From: report at bugs.python.org (Xavier Morel) Date: Mon, 13 Aug 2012 12:45:00 +0000 Subject: [issue15639] csv.Error description is incorrectly broad Message-ID: <1344861900.41.0.500081964818.issue15639@psf.upfronthosting.co.za> New submission from Xavier Morel: In both Python 2.7 and Python 3.x, csv.Error is documented as: Raised by any of the functions when an error is detected. As far as I can tell from using the module and looking at the code, this is completely incorrect. There is actually a single instance of csv.Error being used: the instantiation of csv.Dialect (which converts TypeError raised from _csv._Dialect() into csv.Error, a comment notes that this is "for compatibility with py 2.3"). And the only way to hit that code paths seems to be subclassing `Dialect` and putting incorrect values in the various attributes (providing them to `csv.reader` raises a TypeError). I believe the documentation to csv.Error should be changed to: 1. Mark it as effectively deprecated 2. Indicate that the only situation in which it it may be raised is when initializing a subclass of csv.Dialect ---------- assignee: docs at python components: Documentation messages: 168096 nosy: docs at python, xmorel priority: normal severity: normal status: open title: csv.Error description is incorrectly broad versions: Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 14:50:40 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 13 Aug 2012 12:50:40 +0000 Subject: [issue15592] subprocess.communicate() breaks on no input with universal newlines true In-Reply-To: <1344443880.03.0.234384317121.issue15592@psf.upfronthosting.co.za> Message-ID: <1344862240.02.0.0885954905912.issue15592@psf.upfronthosting.co.za> Andrew Svetlov added the comment: _communicate_with_select has the same problem as _communicate_with_poll. I don't understand why input has encoded if universal_newlines and passed unchanged otherwise. >From my perspective input should be encoded (converted to bytes) if it is str regardless of universal_newlines value. ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 14:51:51 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 13 Aug 2012 12:51:51 +0000 Subject: [issue12623] "universal newlines" subprocess support broken with select- and poll-based communicate() In-Reply-To: <1311451893.22.0.0169745025507.issue12623@psf.upfronthosting.co.za> Message-ID: <1344862311.41.0.465887593967.issue12623@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 14:52:10 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 13 Aug 2012 12:52:10 +0000 Subject: [issue15634] synchronized decorator for the threading module In-Reply-To: <1344845068.87.0.536585589553.issue15634@psf.upfronthosting.co.za> Message-ID: <1344862330.52.0.276495473924.issue15634@psf.upfronthosting.co.za> R. David Murray added the comment: Writing such a decorator is pretty trivial to do. On the other hand, I've done it often enough that I could be convinced it is useful to add. I think it would be better to have a decorator generator that takes a lock as its argument, however, since an application might well want to use the same lock for sections that it doesn't make sense to decorate, or use an RLock instead of a lock. If no lock is passed, a default Lock could be created. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 14:54:21 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 13 Aug 2012 12:54:21 +0000 Subject: [issue15634] synchronized decorator for the threading module In-Reply-To: <1344845068.87.0.536585589553.issue15634@psf.upfronthosting.co.za> Message-ID: <1344862461.62.0.536676832012.issue15634@psf.upfronthosting.co.za> R. David Murray added the comment: Oh, I misread your code. The code I'm working on uses the lock to serialize several different functions, and your decorator wouldn't work for that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 14:54:31 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 13 Aug 2012 12:54:31 +0000 Subject: [issue15595] subprocess.Popen(universal_newlines=True) does not work for certain locales In-Reply-To: <1344461775.23.0.274836365722.issue15595@psf.upfronthosting.co.za> Message-ID: <1344862471.58.0.279436888731.issue15595@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 14:56:48 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 13 Aug 2012 12:56:48 +0000 Subject: [issue15635] memory leak with generators In-Reply-To: <1344849931.31.0.449386115809.issue15635@psf.upfronthosting.co.za> Message-ID: <1344862608.8.0.489155299523.issue15635@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 14:56:58 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 13 Aug 2012 12:56:58 +0000 Subject: [issue15604] PyObject_IsTrue failure checks In-Reply-To: <1344525855.66.0.08938802791.issue15604@psf.upfronthosting.co.za> Message-ID: <1344862618.85.0.530301290212.issue15604@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 15:00:29 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 13 Aug 2012 13:00:29 +0000 Subject: [issue15557] Tests for webbrowser module In-Reply-To: <1344102778.31.0.864118033074.issue15557@psf.upfronthosting.co.za> Message-ID: <1344862829.92.0.824421123641.issue15557@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 15:00:36 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 13 Aug 2012 13:00:36 +0000 Subject: [issue15634] synchronized decorator for the threading module In-Reply-To: <1344845068.87.0.536585589553.issue15634@psf.upfronthosting.co.za> Message-ID: <1344862836.26.0.533227685097.issue15634@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I'm not sure how useful that is in practice. Often you want to use the same lock accross several functions or methods. Also, I think it would be more accurate to call this "serialized" than "synchronized". ---------- nosy: +jyasskin, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 15:01:10 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 13 Aug 2012 13:01:10 +0000 Subject: [issue15638] incorrect version info for TextIOWrapper write_through docs In-Reply-To: <1344861402.45.0.422601843379.issue15638@psf.upfronthosting.co.za> Message-ID: <1344862870.22.0.0799288486124.issue15638@psf.upfronthosting.co.za> R. David Murray added the comment: If I remember correctly it existed in one of the versions (python vs C) but not in both. Or, it existed but wasn't actually respected by one of the versions. ---------- nosy: +pitrou, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 15:10:12 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 13 Aug 2012 13:10:12 +0000 Subject: [issue15571] Python version of TextIOWrapper ignores "write_through" arg In-Reply-To: <1344317257.52.0.527557434634.issue15571@psf.upfronthosting.co.za> Message-ID: <3Wwcjv0ZzvzPfw@mail.python.org> Roundup Robot added the comment: New changeset ba055ccd99ef by Andrew Svetlov in branch 'default': Issue #15571: comment the fact what python impl of TextIOWrapper always works in write_throuth mode http://hg.python.org/cpython/rev/ba055ccd99ef ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 15:12:05 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 13 Aug 2012 13:12:05 +0000 Subject: [issue15638] incorrect version info for TextIOWrapper write_through docs In-Reply-To: <1344861402.45.0.422601843379.issue15638@psf.upfronthosting.co.za> Message-ID: <1344863525.86.0.740559564976.issue15638@psf.upfronthosting.co.za> Chris Jerdonek added the comment: The C version seems to have it in 3.2 as well: http://hg.python.org/cpython/file/5b629e9fde61/Modules/_io/textio.c#l818 Is it possible you were thinking of issue 15571 (not "used" in Python version but still respected)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 15:12:25 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 13 Aug 2012 13:12:25 +0000 Subject: [issue15571] Python version of TextIOWrapper ignores "write_through" arg In-Reply-To: <1344317257.52.0.527557434634.issue15571@psf.upfronthosting.co.za> Message-ID: <1344863545.85.0.118509971118.issue15571@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Patch applied ---------- nosy: +asvetlov resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 15:14:23 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 13 Aug 2012 13:14:23 +0000 Subject: [issue15638] incorrect version info for TextIOWrapper write_through docs In-Reply-To: <1344861402.45.0.422601843379.issue15638@psf.upfronthosting.co.za> Message-ID: <1344863663.35.0.217671665625.issue15638@psf.upfronthosting.co.za> Antoine Pitrou added the comment: See 9144014028f3. It was part of a bugfix in the 3.2 branch, therefore it wasn't exposed as a public API. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 15:15:26 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 13 Aug 2012 13:15:26 +0000 Subject: [issue15638] incorrect version info for TextIOWrapper write_through docs In-Reply-To: <1344861402.45.0.422601843379.issue15638@psf.upfronthosting.co.za> Message-ID: <1344863726.57.0.0162434432628.issue15638@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- resolution: -> rejected stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 15:18:19 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 13 Aug 2012 13:18:19 +0000 Subject: [issue15561] update subprocess docs to reference io.TextIOWrapper In-Reply-To: <1344196317.87.0.366111796882.issue15561@psf.upfronthosting.co.za> Message-ID: <1344863899.27.0.401156213677.issue15561@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > As I can see in subprocess.py TextIOWrapper is applied to stdin also in non-buffered (write_through=True) mode. In 3.2, I will not mention the write_through argument based on Antoine's response to issue 15638. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 15:19:48 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 13 Aug 2012 13:19:48 +0000 Subject: [issue15638] incorrect version info for TextIOWrapper write_through docs In-Reply-To: <1344861402.45.0.422601843379.issue15638@psf.upfronthosting.co.za> Message-ID: <1344863988.95.0.617531053232.issue15638@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Ah, thank you. I see. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 15:54:55 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 13 Aug 2012 13:54:55 +0000 Subject: [issue10224] Build 3.x documentation using python3.x In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za> Message-ID: <1344866095.45.0.450459301928.issue10224@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 16:09:54 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 13 Aug 2012 14:09:54 +0000 Subject: [issue15635] memory leak with generators In-Reply-To: <1344849931.31.0.449386115809.issue15635@psf.upfronthosting.co.za> Message-ID: <1344866994.09.0.943951305654.issue15635@psf.upfronthosting.co.za> Ronald Oussoren added the comment: I've added calls to vmmap to the script (using os.system) to check my guesss. The relevant bit after the call to test_iter(1<<24): REGION TYPE VIRTUAL =========== ======= MALLOC 405.9M see MALLOC ZONE table below MALLOC guard page 32K MALLOC metadata 376K STACK GUARD 56.0M Stack 8192K VM_ALLOCATE 4K __DATA 1720K __LINKEDIT 53.4M __TEXT 12.1M __UNICODE 544K shared memory 8K =========== ======= TOTAL 538.1M VIRTUAL ALLOCATION BYTES MALLOC ZONE SIZE COUNT ALLOCATED % FULL =========== ======= ========= ========= ====== DefaultMallocZone_0x100436000 404.9M 414059 390.6M 96% DispatchContinuations_0x1007dc000 1024K 17 1056 0% =========== ======= ========= ========= ====== TOTAL 405.9M 414076 390.6M 96% Memory usage: 14.3 MB And after the call to test_iter(1<<13) REGION TYPE VIRTUAL =========== ======= MALLOC 208.9M see MALLOC ZONE table below MALLOC freed, no zone 456.0M MALLOC guard page 32K MALLOC metadata 392K STACK GUARD 56.0M Stack 8192K VM_ALLOCATE 4K __DATA 1720K __LINKEDIT 53.4M __TEXT 12.1M __UNICODE 544K shared memory 8K =========== ======= TOTAL 797.1M VIRTUAL ALLOCATION BYTES MALLOC ZONE SIZE COUNT ALLOCATED % FULL =========== ======= ========= ========= ====== DefaultMallocZone_0x100436000 207.9M 209467 197.0M 94% DispatchContinuations_0x1007dc000 1024K 17 1056 0% =========== ======= ========= ========= ====== TOTAL 208.9M 209484 197.0M 94% Memory usage: 462.6 MB The total amount of "memory usage" is grown by about 450 MBytes (according to psutils). This is explained by the change in MALLOC memory, before: MALLOC 405.9M see MALLOC ZONE table below MALLOC guard page 32K MALLOC metadata 376K Total: about 406 MByte After: MALLOC 208.9M see MALLOC ZONE table below MALLOC freed, no zone 456.0M MALLOC guard page 32K MALLOC metadata 392K Total: about 665 MByte. The difference is about 260 MBytes, which is significant but less than the difference according to psutil. But: the psutil difference as calculated by the script is the difference in RSS, not VSIZE (which vmmap shows). If I change the _mem function to use the VSIZE the before and after values are: Memory usage: 2390.4 MB Memory usage: 2846.4 MB Difference: about 456 MByte, which is still higher than the output of vmmap. Note that the same behavior can be seen by a much simpler script: print "Large" x = list(range(1<<24)) print _mem() del x print _mem() print print "Small" x = list(range(1<<23)) print _mem() del x print _mem() (where _mem is the same function as in testiterbug.py). The output is: Large Memory usage: 527.3 MB Memory usage: 19.3 MB Small Memory usage: 330.6 MB Memory usage: 147.6 MB With this script is see the same pattern with vmmap: with the "small" list a large amount of memory is in regions of type (MALLOC freed, no zone). All of this clearly points towards malloc not releasing allocated memory to the system. This is perfectly fine and not a bug in either Python or the system. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 16:10:41 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 13 Aug 2012 14:10:41 +0000 Subject: [issue15151] Documentation for Signature, Parameter and signature in inspect module In-Reply-To: <1340432030.73.0.594662136445.issue15151@psf.upfronthosting.co.za> Message-ID: <3Wwf3h2PCFzPlW@mail.python.org> Roundup Robot added the comment: New changeset 814462492fbd by Andrew Svetlov in branch 'default': Issue #15151: PEP 362 ? document signature and related classes for inspect.py http://hg.python.org/cpython/rev/814462492fbd ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 16:14:33 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 13 Aug 2012 14:14:33 +0000 Subject: [issue15151] Documentation for Signature, Parameter and signature in inspect module In-Reply-To: <1340432030.73.0.594662136445.issue15151@psf.upfronthosting.co.za> Message-ID: <1344867273.58.0.76639567547.issue15151@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Closing the issue. Feel free to reopen if you have some corrections. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 16:14:54 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 13 Aug 2012 14:14:54 +0000 Subject: [issue15151] Documentation for Signature, Parameter and signature in inspect module In-Reply-To: <1340432030.73.0.594662136445.issue15151@psf.upfronthosting.co.za> Message-ID: <1344867294.75.0.484303053782.issue15151@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 16:30:04 2012 From: report at bugs.python.org (Meador Inge) Date: Mon, 13 Aug 2012 14:30:04 +0000 Subject: [issue15623] Init time relative imports no longer work from __init__.so modules In-Reply-To: <1344697325.25.0.880049566038.issue15623@psf.upfronthosting.co.za> Message-ID: <1344868204.57.0.737328292822.issue15623@psf.upfronthosting.co.za> Meador Inge added the comment: I debugged this a bit by comparing the behavior of 3.3 against 3.2. For both cases I used the following code and debugged it in Python via pdb*: import importlib importlib.__import__('my_test_package') ISTM that the difference in behavior is a result of what loader gets chosen for the initial `import 'my_test_package'`. With 3.2 a importlib._bootstrap._SourceFileLoader loader gets created against 'my_test_package/__init__.py'. This works fine because _SourceFileLoader fixes up sys.modules when it loads. With 3.3 a _frozen_importlib.ExtensionFileLoader loader gets created against 'my_test_package/__init__.so'. This doesn't work because ExtensionFileLoader does *not* fixup sys.module when it loads. I hope that helps some. * Which was a real pain for 3.3 since you are debugging the frozen importlib. You get line numbers at least, but it would be really nice if you could tell pdb a source file to use when you are dealing with bytecode only objects and\or you could disassemble the bytecode from pdb. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 16:31:54 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 13 Aug 2012 14:31:54 +0000 Subject: [issue15592] subprocess.communicate() breaks on no input with universal newlines true In-Reply-To: <1344443880.03.0.234384317121.issue15592@psf.upfronthosting.co.za> Message-ID: <1344868314.82.0.53202688016.issue15592@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > From my perspective input should be encoded (converted to bytes) if it is str regardless of universal_newlines value. I don't know the reason, but the limitation is documented: "The optional input argument should be data to be sent to the child process, or None, if no data should be sent to the child. The type of input must be bytes or, if universal_newlines was True, a string." http://docs.python.org/dev/library/subprocess.html#subprocess.Popen.communicate Maybe "explicit better than implicit"? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 16:49:38 2012 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 13 Aug 2012 14:49:38 +0000 Subject: [issue15151] Documentation for Signature, Parameter and signature in inspect module In-Reply-To: <1340432030.73.0.594662136445.issue15151@psf.upfronthosting.co.za> Message-ID: <1344869377.99.0.326802771375.issue15151@psf.upfronthosting.co.za> Yury Selivanov added the comment: Thank you, Andrew. One thing: can you please change: > Print all keyword-only arguments without default values: to > Example: print all keyword-only arguments without default values: ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 16:52:03 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Mon, 13 Aug 2012 14:52:03 +0000 Subject: [issue13498] os.makedirs exist_ok documentation is incorrect, as is some of the behavior In-Reply-To: <1344861620.56.0.495491077768.issue13498@psf.upfronthosting.co.za> Message-ID: <5029148C.8090704@ox.cx> Hynek Schlawack added the comment: > Silence doesn't mean consent, but it does mean you can go ahead and see if anyone complains :) Well that's what I meant. :) > I think your proposal is fine, but I'd prefer making the sentinels just "IGNORE" and "FAIL". The module namespace means the names themselves don't have to be fully qualified. I thought about that but found them pretty...generic. Anyway, that's 3.4-fodder. Could you have a look at the doc fix please? It applies against 3.2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 17:13:45 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 13 Aug 2012 15:13:45 +0000 Subject: [issue13498] os.makedirs exist_ok documentation is incorrect, as is some of the behavior In-Reply-To: <1322574123.12.0.756700598965.issue13498@psf.upfronthosting.co.za> Message-ID: <1344870825.67.0.423527056442.issue13498@psf.upfronthosting.co.za> R. David Murray added the comment: English-wise I would drop the "Also". You say "differs from the one supplied", but given the rest of the text I would expect that it is really "differs from the supplied mode masked with the current umask, on systems where the mode is respected", which is a mouthful :(. Perhaps it would flow better if the discussion of exists_ok came after the discussion of mode (that is, as the last thing in the paragraph). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 17:20:11 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 13 Aug 2012 15:20:11 +0000 Subject: [issue13742] Add a key parameter (like sorted) to heapq.merge In-Reply-To: <1326105342.42.0.0197399269422.issue13742@psf.upfronthosting.co.za> Message-ID: <1344871211.54.0.942241477418.issue13742@psf.upfronthosting.co.za> ?ric Araujo added the comment: Yes, 3.3 is already in beta. ---------- keywords: +needs review stage: -> patch review versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 17:24:57 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 13 Aug 2012 15:24:57 +0000 Subject: [issue15151] Documentation for Signature, Parameter and signature in inspect module In-Reply-To: <1340432030.73.0.594662136445.issue15151@psf.upfronthosting.co.za> Message-ID: <1344871497.18.0.70249213011.issue15151@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Done in 843e0da7e91f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 17:29:16 2012 From: report at bugs.python.org (Eric Snow) Date: Mon, 13 Aug 2012 15:29:16 +0000 Subject: [issue15623] Init time relative imports no longer work from __init__.so modules In-Reply-To: <1344697325.25.0.880049566038.issue15623@psf.upfronthosting.co.za> Message-ID: <1344871756.03.0.383666125159.issue15623@psf.upfronthosting.co.za> Eric Snow added the comment: That's helpful, Meador. With regards to the following, there's more to the story: > With 3.3 a _frozen_importlib.ExtensionFileLoader loader gets created > against 'my_test_package/__init__.so'. This doesn't work because > ExtensionFileLoader does *not* fixup sys.module when it loads. In the example Stefan provided, look at my_test_package/__init__.c:921. You'll find PyInit_my_test_package(). The module creation code from msg168026 comes from that function. There PyImport_AddModule gets called, which adds the module to interp->modules. I haven't had time to run this through gdb to see what's happening sys.modules in this case. In general, I'm not familiar enough with extension modules to know if they are actually responsible for adding themselves to sys.modules. I do see a number of places in Python/import.c and friends that touch sys.modules. If importlib is in charge of adding it, though, I'd think that ExtensionFileLoader.load_module would need the module_for_loader decorator. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 17:33:31 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 13 Aug 2012 15:33:31 +0000 Subject: [issue15561] update subprocess docs to reference io.TextIOWrapper In-Reply-To: <1344196317.87.0.366111796882.issue15561@psf.upfronthosting.co.za> Message-ID: <1344872011.74.0.716612084565.issue15561@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Andrew, here is the new patch for 3.2. 3.3 will come shortly after. ---------- Added file: http://bugs.python.org/file26783/issue-15561-3-branch-32.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 17:36:56 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 13 Aug 2012 15:36:56 +0000 Subject: [issue15635] memory leak with generators In-Reply-To: <1344849931.31.0.449386115809.issue15635@psf.upfronthosting.co.za> Message-ID: <1344872216.35.0.629355104592.issue15635@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > The test case finds some leak in 3.3 too, it seems. 3.3 should be much better since it uses mmap() and munmap() to manage the object allocator's arenas (unless this is disabled under OS X for some reason, that is). Here under Linux: $ python3.3 testiterbug.py 3.3.0b1 (default:1d811e1097ed, Jul 29 2012, 20:20:37) [GCC 4.5.2] [row for row in iterit(16777216)] Memory usage: 7.8 MB [row for row in iterit(8388608)] Memory usage: 7.8 MB ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 17:39:06 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 13 Aug 2012 15:39:06 +0000 Subject: [issue15561] update subprocess docs to reference io.TextIOWrapper In-Reply-To: <1344196317.87.0.366111796882.issue15561@psf.upfronthosting.co.za> Message-ID: <1344872346.16.0.554103698207.issue15561@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Here is the patch for the default/3.3 branch, which for convenience is a diff for the branch *after the 3.2 patch has been forward-ported to 3.3*. I did not think it was necessary to mention write_through specifically since it seems more like an implementation detail (though stdin as a whole is now documented). ---------- Added file: http://bugs.python.org/file26784/issue-15561-3-branch-default-delta.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 18:00:21 2012 From: report at bugs.python.org (Daniel Ellis) Date: Mon, 13 Aug 2012 16:00:21 +0000 Subject: [issue15586] Provide some examples for usage of ElementTree methods/attributes In-Reply-To: <1344407679.24.0.102359835139.issue15586@psf.upfronthosting.co.za> Message-ID: <1344873621.63.0.933247541963.issue15586@psf.upfronthosting.co.za> Daniel Ellis added the comment: I've updated 2.7 with the examples and made changes where backward compatibility was an issue. ---------- Added file: http://bugs.python.org/file26785/2.7_branch_etree_doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 18:01:08 2012 From: report at bugs.python.org (Daniel Ellis) Date: Mon, 13 Aug 2012 16:01:08 +0000 Subject: [issue15586] Provide some examples for usage of ElementTree methods/attributes In-Reply-To: <1344407679.24.0.102359835139.issue15586@psf.upfronthosting.co.za> Message-ID: <1344873668.06.0.359446561068.issue15586@psf.upfronthosting.co.za> Daniel Ellis added the comment: Fixed typo I made in examples in default branch. ---------- Added file: http://bugs.python.org/file26786/default_branch_etree_doc_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 18:10:53 2012 From: report at bugs.python.org (Florent Xicluna) Date: Mon, 13 Aug 2012 16:10:53 +0000 Subject: [issue15635] memory leak with generators In-Reply-To: <1344849931.31.0.449386115809.issue15635@psf.upfronthosting.co.za> Message-ID: <1344874253.04.0.318855235524.issue15635@psf.upfronthosting.co.za> Florent Xicluna added the comment: > All of this clearly points towards malloc not releasing allocated memory to the system. > This is perfectly fine and not a bug in either Python or the system. So it means there's no reliable way to measure the memory consumption of the program. Sorry for the wrong report, if this is confirmed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 18:39:32 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 13 Aug 2012 16:39:32 +0000 Subject: [issue15635] memory leak with generators In-Reply-To: <1344874253.04.0.318855235524.issue15635@psf.upfronthosting.co.za> Message-ID: <1344875802.3407.3.camel@localhost.localdomain> Antoine Pitrou added the comment: > > All of this clearly points towards malloc not releasing allocated memory to the system. > > This is perfectly fine and not a bug in either Python or the system. > > So it means there's no reliable way to measure the memory consumption of the program. What it means is that "memory consumption" itself is a bit ill-defined. "ps", "top" and friends will tell you the amount of memory (physical or virtual) currently assigned by the OS to the process. It doesn't tell you whether the memory is "actually" in use by the program. Note that, in Python 3.3, sys._debugmallocstats() gives you fined-grained information about the object allocator. This excludes any blocks bigger than 512 bytes, though, since those are requested directly using malloc() and free(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 18:46:42 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 13 Aug 2012 16:46:42 +0000 Subject: [issue15637] Segfault reading null VMA (works fine in python 2.x) In-Reply-To: <1344860415.33.0.2201769173.issue15637@psf.upfronthosting.co.za> Message-ID: <1344876402.14.0.676300614336.issue15637@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I can reproduce, but it's not obvious to me what the test does or why it should succeed rather than fail. For the record, here is the gdb traceback: #0 0x00007ffff53c6dc8 in XQueryExtension () from /usr/lib64/libX11.so.6 #1 0x00007ffff53ba4d4 in XInitExtension () from /usr/lib64/libX11.so.6 #2 0x00007ffff4959672 in XextAddDisplay () from /usr/lib64/libXext.so.6 #3 0x00007ffff4b5ea96 in ?? () from /usr/lib64/libXrandr.so.2 #4 0x00007ffff4b5ee36 in XRRQueryVersion () from /usr/lib64/libXrandr.so.2 #5 0x00007ffff59274ec in ffi_call_unix64 () at /home/antoine/cpython/default/Modules/_ctypes/libffi/src/x86/unix64.S:75 #6 0x00007ffff5926f5e in ffi_call (cif=0x7fffffffbd30, fn=0x7ffff4b5ee10 , rvalue= 0x7fffffffbe10, avalue=0x7fffffffbde0) at /home/antoine/cpython/default/Modules/_ctypes/libffi/src/x86/ffi64.c:492 #7 0x00007ffff590ed27 in _call_function_pointer (flags=4353, pProc=0x7ffff4b5ee10 , avalues=0x7fffffffbde0, atypes=0x7fffffffbdb0, restype=0x7ffff5b587e8, resmem=0x7fffffffbe10, argcount=3) at /home/antoine/cpython/default/Modules/_ctypes/callproc.c:800 #8 0x00007ffff590f90c in _ctypes_callproc (pProc=0x7ffff4b5ee10 , argtuple= (0, , ), flags=4353, argtypes= 0x0, restype=<_ctypes.PyCSimpleType at remote 0xa171c0>, checker=0x0) at /home/antoine/cpython/default/Modules/_ctypes/callproc.c:1143 #9 0x00007ffff5908dec in PyCFuncPtr_call (self=0x7ffff5b4de60, inargs= (0, , ), kwds=0x0) at /home/antoine/cpython/default/Modules/_ctypes/_ctypes.c:3804 #10 0x0000000000593e7b in PyObject_Call (func= <_FuncPtr(__name__='XRRQueryVersion') at remote 0x7ffff5b4de60>, arg= (0, , ), kw=0x0) at Objects/abstract.c:2083 [...] ---------- nosy: +amaury.forgeotdarc, belopolsky, meador.inge, pitrou versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 19:03:28 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 13 Aug 2012 17:03:28 +0000 Subject: [issue15592] subprocess.communicate() breaks on no input with universal newlines true In-Reply-To: <1344443880.03.0.234384317121.issue15592@psf.upfronthosting.co.za> Message-ID: <1344877408.38.0.449181167477.issue15592@psf.upfronthosting.co.za> Chris Jerdonek added the comment: This issue may be the bug referenced here: # BUG: can't give a non-empty stdin because it breaks both the # select- and poll-based communicate() implementations. (stdout, stderr) = p.communicate() http://hg.python.org/cpython/file/843e0da7e91f/Lib/test/test_subprocess.py#l618 The reason is that the above test would fail if stdin were not None since the input to communicate is None. I am preparing a test and patch for this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 19:05:15 2012 From: report at bugs.python.org (Mike Hoy) Date: Mon, 13 Aug 2012 17:05:15 +0000 Subject: [issue12436] Missing items in installation/setup instructions In-Reply-To: <1309305395.29.0.101516779086.issue12436@psf.upfronthosting.co.za> Message-ID: <1344877515.08.0.129737014432.issue12436@psf.upfronthosting.co.za> Mike Hoy added the comment: >Thanks, I will take all contributions and suggestions and propose one patch. I am able to start working on this issue again, Eric. If you want to give me the status of your patch I can either help you finish it up or I can make one this week. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 19:18:42 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 13 Aug 2012 17:18:42 +0000 Subject: [issue15623] Init time relative imports no longer work from __init__.so modules In-Reply-To: <1344697325.25.0.880049566038.issue15623@psf.upfronthosting.co.za> Message-ID: <1344878322.5.0.462547572529.issue15623@psf.upfronthosting.co.za> Brett Cannon added the comment: So imp.load_dynamic() does add a module to sys.modules (I'm using Python 3.2 here because that's what I have access to, but I verified this yesterday at home):: Python 3.2.3 (default, May 3 2012, 15:51:42) [GCC 4.6.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import imp >>> import sys >>> 'resource' in sys.modules False >>> mod = imp.load_dynamic('resource', '/usr/lib/python3.2/lib-dynload/resource.cpython-32mu.so') >>> mod >>> 'resource' in sys.modules True IOW it is not needed for ExtensionFileLoader to add the module explicitly to sys.modules. As for Meador's notice that __init__.py was being imported, I believe Stefan is saying it should work without that file. So deleting __init__.py and only having __init__.so in Python 3.2 should work. If not then this has been a false alarm. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 19:31:16 2012 From: report at bugs.python.org (Meador Inge) Date: Mon, 13 Aug 2012 17:31:16 +0000 Subject: [issue15623] Init time relative imports no longer work from __init__.so modules In-Reply-To: <1344878322.5.0.462547572529.issue15623@psf.upfronthosting.co.za> Message-ID: Meador Inge added the comment: On Mon, Aug 13, 2012 at 12:18 PM, Brett Cannon wrote: > So deleting __init__.py and only having __init__.so in Python 3.2 should work. It doesn't work: quicksilver:bugs meadori$ python.exe --version Python 3.2.3+ quicksilver:bugs meadori$ PYTHON=python.exe ./test.sh ['__main__', '_abcoll', '_bisect', '_codecs', '_collections', '_functools', '_heapq', '_io', '_locale', '_sre', '_thread', '_weakref', '_weakrefset', 'abc', 'bisect', 'builtins', 'codecs', 'collections', 'copyreg', 'encodings', 'encodings.aliases', 'encodings.latin_1', 'encodings.utf_8', 'errno', 'functools', 'genericpath', 'heapq', 'io', 'itertools', 'keyword', 'linecache', 'locale', 'my_test_package', 'operator', 'os', 'os.path', 'posix', 'posixpath', 're', 'reprlib', 'signal', 'site', 'sre_compile', 'sre_constants', 'sre_parse', 'stat', 'sys', 'sysconfig', 'token', 'tokenize', 'traceback', 'weakref', 'zipimport'] FILE: my_test_package/__init__.py PATH: ['my_test_package'] Real package file used: my_test_package/__init__.so [36494 refs] quicksilver:bugs meadori$ rm my_test_package/__init__.py quicksilver:bugs meadori$ PYTHON=python.exe ./test.sh Traceback (most recent call last): File "", line 1, in ImportError: No module named my_test_package [36287 refs] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 19:54:36 2012 From: report at bugs.python.org (Alberto Milone) Date: Mon, 13 Aug 2012 17:54:36 +0000 Subject: [issue15637] Segfault reading null VMA (works fine in python 2.x) In-Reply-To: <1344860415.33.0.2201769173.issue15637@psf.upfronthosting.co.za> Message-ID: <1344880476.55.0.776003328898.issue15637@psf.upfronthosting.co.za> Alberto Milone added the comment: it should just be possible to retrieve major and minor which we pass by reference to XRRQueryVersion. Without this pretty much any other call fails. Also, it works without problems with python 2.7. ---------- versions: -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 19:59:38 2012 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 13 Aug 2012 17:59:38 +0000 Subject: [issue15623] Init time relative imports no longer work from __init__.so modules In-Reply-To: <1344697325.25.0.880049566038.issue15623@psf.upfronthosting.co.za> Message-ID: <1344880778.62.0.77765058341.issue15623@psf.upfronthosting.co.za> Stefan Behnel added the comment: Interesting. I didn't know that. The .py file is always installed automatically next to the .so file by distutils. Here's what strace gives me: Python 2.7: stat("my_test_package", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0 stat("my_test_package/__init__.py", {st_mode=S_IFREG|0664, st_size=557, ...}) = 0 stat("my_test_package/__init__", 0x7fffdc9dd320) = -1 ENOENT (No such file or directory) open("my_test_package/__init__.so", O_RDONLY) = 3 open("my_test_package/__init__.so", O_RDONLY|O_CLOEXEC) = 4 Python 3.2: stat("my_test_package", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0 stat("my_test_package/__init__.py", {st_mode=S_IFREG|0664, st_size=557, ...}) = 0 stat("my_test_package/__init__", 0x7fff9d99d700) = -1 ENOENT (No such file or directory) stat("my_test_package/__init__.cpython-32mu.so", {st_mode=S_IFREG|0775, st_size=82517, ...}) = 0 open("my_test_package/__init__.cpython-32mu.so", O_RDONLY) = 3 open("my_test_package/__init__.cpython-32mu.so", O_RDONLY|O_CLOEXEC) = 4 Python 3.3: stat("./my_test_package", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0 stat("./my_test_package/__init__.cpython-33dm.so", {st_mode=S_IFREG|0775, st_size=36119, ...}) = 0 open("./my_test_package/__init__.cpython-33dm.so", O_RDONLY|O_CLOEXEC) = 3 That's the difference then. Ok, I think we'll have to emulate this for older CPython versions as well for the case that the .py file is not there. So it's likely best to let Cython register the package in sys.modules at init time, right after calling AddModule(). Still - can this be implemented in CPython for 3.3? Or 3.4, given that it might appear like a new feature? There shouldn't be all that much to change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 21:01:13 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 13 Aug 2012 19:01:13 +0000 Subject: [issue15623] Init time relative imports no longer work from __init__.so modules In-Reply-To: <1344697325.25.0.880049566038.issue15623@psf.upfronthosting.co.za> Message-ID: <1344884473.49.0.627698828408.issue15623@psf.upfronthosting.co.za> Brett Cannon added the comment: My guess is import.c is noticing the __init__.py, creating the module for the package, and then somehow it cascades into importing __init__.so which essentially does a reload on the module object that is already in sys.modules and thus doesn't cause the parent module check to fail. The problem with that is those semantics suck as that assumes cascading semantics which would cross the finder/loader barrier. So we can't keep the *exact* semantics in Python 3.3. But I do see three possible solutions to fixing this. One is testing if having ExtensionFileLoader insert a practically empty module into sys.modules *before* calling imp.load_dynamic(). This would actually be easy to test by using importlib.util.module_for_loader on ExtensionFileLoader.load_module(). This might be a slight change in semantics (and assumes imp.load_dynamic() will do a reload as appropriate instead of blindly creating a new module), but then if anyone is going to notice it will be Cython so if it works in this case and Cython doesn't fail further it is probably safe. The second option is to tweak the extension module initialization process to make sure the module being initialized is inserted into sys.modules early enough and still cleaned up properly. The question, though, is what is it doing now as the module is not passed in directly into the PyInit function but by PyModule_Create instead and I don't know who handles cleanup of the module if something fails and the PyInit returns NULL. Third is having Cython tweak itself for 3.3 to just directly inject the module object into sys.modules before it does any relative imports. It's the least graceful solution and puts the onus on Cython for a change in semantics, but I don't see why that would break anything. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 21:11:27 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 13 Aug 2012 19:11:27 +0000 Subject: [issue15561] update subprocess docs to reference io.TextIOWrapper In-Reply-To: <1344196317.87.0.366111796882.issue15561@psf.upfronthosting.co.za> Message-ID: <3Wwmkj4kxjzPpc@mail.python.org> Roundup Robot added the comment: New changeset 381aaf79c254 by Andrew Svetlov in branch '3.2': Issue #15561: Update subprocess docs to reference io.TextIOWrapper. http://hg.python.org/cpython/rev/381aaf79c254 New changeset 0cd9423770fa by Andrew Svetlov in branch 'default': Issue #15561: Update subprocess docs to reference io.TextIOWrapper. http://hg.python.org/cpython/rev/0cd9423770fa ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 21:16:03 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 13 Aug 2012 19:16:03 +0000 Subject: [issue15561] update subprocess docs to reference io.TextIOWrapper In-Reply-To: <1344196317.87.0.366111796882.issue15561@psf.upfronthosting.co.za> Message-ID: <1344885363.25.0.168363673188.issue15561@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Fixed. BTW I prefer to use ?stream? as alias to file object it subprocess context. ?file? can clash with ?the real file in filesystem? for documentation reader. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 21:19:59 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 13 Aug 2012 19:19:59 +0000 Subject: [issue15561] update subprocess docs to reference io.TextIOWrapper In-Reply-To: <1344196317.87.0.366111796882.issue15561@psf.upfronthosting.co.za> Message-ID: <1344885599.49.0.647167333551.issue15561@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > Fixed. BTW I prefer to use ?stream? as alias to file object Thanks a lot, Andrew. Yes, I agree and actually contemplated doing that myself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 21:27:42 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 13 Aug 2012 19:27:42 +0000 Subject: [issue15497] correct characters in TextWrapper.replace_whitespace docs In-Reply-To: <1343621441.45.0.427004155003.issue15497@psf.upfronthosting.co.za> Message-ID: <1344886062.77.0.605274394586.issue15497@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- nosy: +asvetlov versions: +Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 21:32:56 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 13 Aug 2012 19:32:56 +0000 Subject: [issue15437] Merge Doc/ACKS.txt names into Misc/ACKS In-Reply-To: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za> Message-ID: <1344886376.75.0.347536674727.issue15437@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 21:33:53 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 13 Aug 2012 19:33:53 +0000 Subject: [issue14167] document return statement in finally blocks In-Reply-To: <1330614429.57.0.59180427723.issue14167@psf.upfronthosting.co.za> Message-ID: <1344886433.95.0.2354379989.issue14167@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 21:36:57 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 13 Aug 2012 19:36:57 +0000 Subject: [issue15627] Add a method to importlib.abc.SourceLoader for converting source to a code object In-Reply-To: <1344732276.83.0.543554641885.issue15627@psf.upfronthosting.co.za> Message-ID: <1344886617.62.0.0351327560402.issue15627@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 21:37:07 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 13 Aug 2012 19:37:07 +0000 Subject: [issue15031] Split .pyc parsing from module loading In-Reply-To: <1339096213.71.0.334524050625.issue15031@psf.upfronthosting.co.za> Message-ID: <1344886627.8.0.683096300623.issue15031@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 21:38:13 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 13 Aug 2012 19:38:13 +0000 Subject: [issue15628] Add import ABC hierarchy to docs for importlib In-Reply-To: <1344737242.66.0.0570077478746.issue15628@psf.upfronthosting.co.za> Message-ID: <1344886693.6.0.932196796483.issue15628@psf.upfronthosting.co.za> Brett Cannon added the comment: http://hg.python.org/cpython/rev/1c8a6df94602 seems to be commit this. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 21:47:18 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 13 Aug 2012 19:47:18 +0000 Subject: [issue15640] Document deprecate importlib.abc.Finder Message-ID: <1344887238.09.0.248857343378.issue15640@psf.upfronthosting.co.za> New submission from Brett Cannon: importlib.abc.Finder is no longer the proper level of abstraction for either meta path finders or path entry finders, so direct inheritance should be discouraged by documenting deprecation for the class (actual deprecation will need to be avoided as the constructor gets involved and having that error out if someone sets warnings to errors would be bad). Should probably also document as deprecated importlib.abc.PathEntryFinder.find_module(). Also need to remember to update the inheritance hierarchy now added to the docs with a note next to the class about the deprecation (along with PyLoader and PyPycLoader). ---------- assignee: brett.cannon components: Documentation messages: 168138 nosy: barry, brett.cannon, eric.snow, ncoghlan priority: normal severity: normal stage: needs patch status: open title: Document deprecate importlib.abc.Finder versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 21:47:27 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 13 Aug 2012 19:47:27 +0000 Subject: [issue15640] Document importlib.abc.Finder as deprecated In-Reply-To: <1344887238.09.0.248857343378.issue15640@psf.upfronthosting.co.za> Message-ID: <1344887247.78.0.648620988769.issue15640@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- title: Document deprecate importlib.abc.Finder -> Document importlib.abc.Finder as deprecated _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 21:55:46 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 13 Aug 2012 19:55:46 +0000 Subject: [issue15592] subprocess.communicate() breaks on no input with universal newlines true In-Reply-To: <1344443880.03.0.234384317121.issue15592@psf.upfronthosting.co.za> Message-ID: <1344887746.2.0.0183493941939.issue15592@psf.upfronthosting.co.za> Andrew Svetlov added the comment: I like to accept both str and bytes if universal_newlines is False and raise explicit exception for bytes if universal_newlines is True. Looks like universal_newlines for bytes doesn't make sense, also we prefer to use str everywhere. Bytes should be used if it is really byte-stream or if unicode cannot be passed by some limitations of underlying OS etc. There are couple dark corners: 1. What to do if stdin doesn't have `encoding` attribute? Convert to bytes using filesystemencoding? Raise explicit exception? Adding `encode` parameter for .communicate doesn't looks elegant. 2. How .communicate works on Windows? I see completely different implementation of this method for win32. I need some time to investigate before publish proposal to python-dev list. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 22:00:35 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 13 Aug 2012 20:00:35 +0000 Subject: [issue15641] Clean up importlib for Python 3.4 Message-ID: <1344888035.57.0.935580041455.issue15641@psf.upfronthosting.co.za> New submission from Brett Cannon: importlib.abc.PyLoader and importlib.abc.PyPycLoader were both deprecated in 3.2 and slated for removal in Python 3.4. There is also some os2 stuff in importlib._bootstrap which can go as PEP 11 has os2 support slated for removal in Python 3.4. ---------- assignee: brett.cannon messages: 168140 nosy: brett.cannon, eric.snow, ncoghlan priority: low severity: normal stage: needs patch status: open title: Clean up importlib for Python 3.4 versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 22:09:44 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 13 Aug 2012 20:09:44 +0000 Subject: [issue15592] subprocess.communicate() breaks on no input with universal newlines true In-Reply-To: <1344443880.03.0.234384317121.issue15592@psf.upfronthosting.co.za> Message-ID: <1344888584.03.0.732322798588.issue15592@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Attaching a failing test case. Also, to confirm, this issue does not seem to affect 3.2. ---------- keywords: +patch Added file: http://bugs.python.org/file26787/failing-test-case-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 22:09:58 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 13 Aug 2012 20:09:58 +0000 Subject: [issue15592] subprocess.communicate() breaks on no input with universal newlines true In-Reply-To: <1344443880.03.0.234384317121.issue15592@psf.upfronthosting.co.za> Message-ID: <1344888598.85.0.89344238098.issue15592@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- stage: test needed -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 22:26:49 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 13 Aug 2012 20:26:49 +0000 Subject: [issue15497] correct characters in TextWrapper.replace_whitespace docs In-Reply-To: <1343621441.45.0.427004155003.issue15497@psf.upfronthosting.co.za> Message-ID: <3WwpPg1B0kzPrd@mail.python.org> Roundup Robot added the comment: New changeset 90a8a462d2f7 by Andrew Svetlov in branch '3.2': Issue #15497: Correct characters in TextWrapper.replace_whitespace docs. http://hg.python.org/cpython/rev/90a8a462d2f7 New changeset edcbf3edf701 by Andrew Svetlov in branch 'default': Issue #15497: Correct characters in TextWrapper.replace_whitespace docs. http://hg.python.org/cpython/rev/edcbf3edf701 New changeset 3bddc965e2ea by Andrew Svetlov in branch '2.7': Issue #15497: Correct characters in TextWrapper.replace_whitespace docs. http://hg.python.org/cpython/rev/3bddc965e2ea ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 22:27:36 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 13 Aug 2012 20:27:36 +0000 Subject: [issue15497] correct characters in TextWrapper.replace_whitespace docs In-Reply-To: <1343621441.45.0.427004155003.issue15497@psf.upfronthosting.co.za> Message-ID: <1344889656.93.0.547307025444.issue15497@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Done. Thanks, Chris. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 22:35:03 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 13 Aug 2012 20:35:03 +0000 Subject: [issue14649] doctest.DocTestSuite error misleading when module has no docstrings In-Reply-To: <1335192861.9.0.305748973415.issue14649@psf.upfronthosting.co.za> Message-ID: <1344890103.6.0.76331815557.issue14649@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 22:48:40 2012 From: report at bugs.python.org (Alexandre Vassalotti) Date: Mon, 13 Aug 2012 20:48:40 +0000 Subject: [issue15642] Integrate pickle protocol version 4 GSoC work by Stefan Mihaila Message-ID: <1344890920.23.0.695633734046.issue15642@psf.upfronthosting.co.za> New submission from Alexandre Vassalotti: Stefan Mihaila has been working on the implementation of PEP 3154, plus some other enhancements. His work is pretty complete and ready to be reviewed. I will do my best to finish a thorough review of his changes by the end of next week. ---------- assignee: alexandre.vassalotti components: Library (Lib) hgrepos: 145 keywords: gsoc, patch messages: 168144 nosy: alexandre.vassalotti, mstefanro, pitrou priority: normal severity: normal stage: patch review status: open title: Integrate pickle protocol version 4 GSoC work by Stefan Mihaila type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 23:10:56 2012 From: report at bugs.python.org (Georg Brandl) Date: Mon, 13 Aug 2012 21:10:56 +0000 Subject: [issue15631] Python 3.3 beta 1 installation issue lib/lib64 folders In-Reply-To: <1344794304.26.0.478120841355.issue15631@psf.upfronthosting.co.za> Message-ID: <1344892256.98.0.778392904463.issue15631@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- nosy: +doko _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 23:22:49 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 13 Aug 2012 21:22:49 +0000 Subject: [issue15592] subprocess.communicate() breaks on no input with universal newlines true In-Reply-To: <1344443880.03.0.234384317121.issue15592@psf.upfronthosting.co.za> Message-ID: <1344892969.03.0.269594566647.issue15592@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Attaching patch. ---------- stage: needs patch -> patch review Added file: http://bugs.python.org/file26788/issue-15592-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 23:29:51 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 13 Aug 2012 21:29:51 +0000 Subject: [issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za> Message-ID: <1344893391.42.0.403631717369.issue11549@psf.upfronthosting.co.za> Terry J. Reedy added the comment: In msg132312 Nick asked "where do we stand in regards to backwards compatibility of the AST?" The current ast module chapter, second sentence, says ""The abstract syntax itself might change with each Python release;" this module helps to find out programmatically what the current grammar looks like." where 'current grammar' is copied in 30.2.2. Abstract Grammar. I do not know when that was written, but it clearly implies the the grammark, which defines node classes, is x.y version specific. I think this is the correct policy just so we can make changes, hopefully improvements, such as the one proposed here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 23:30:35 2012 From: report at bugs.python.org (Nikolaus Rath) Date: Mon, 13 Aug 2012 21:30:35 +0000 Subject: [issue15633] httplib.response is not closed after all data has been read In-Reply-To: <1344821463.76.0.139090148106.issue15633@psf.upfronthosting.co.za> Message-ID: <1344893435.72.0.38392154168.issue15633@psf.upfronthosting.co.za> Nikolaus Rath added the comment: The problem seems to occur regularly, just with large intervals in between. Is there any specific information that might help here? I am not quite sure what to save when the problem happens the next time. Can the response object be pickled? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 23:50:51 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 13 Aug 2012 21:50:51 +0000 Subject: [issue15496] harden directory removal for tests on Windows In-Reply-To: <1343614495.69.0.283818579392.issue15496@psf.upfronthosting.co.za> Message-ID: <1344894651.72.0.176329965541.issue15496@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Brian, Tim, do you think this should be committed? ---------- versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 23:52:09 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 13 Aug 2012 21:52:09 +0000 Subject: [issue8800] add threading.RWLock In-Reply-To: <1274694942.46.0.488506239249.issue8800@psf.upfronthosting.co.za> Message-ID: <1344894729.67.0.723234162809.issue8800@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Perhaps this proposed patch is overly complex. I don't know. Do you think relaxing the semantics would make the implementation significantly faster? (interesting link, btw) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 23:54:25 2012 From: report at bugs.python.org (Brian Curtin) Date: Mon, 13 Aug 2012 21:54:25 +0000 Subject: [issue15496] harden directory removal for tests on Windows In-Reply-To: <1343614495.69.0.283818579392.issue15496@psf.upfronthosting.co.za> Message-ID: <1344894865.57.0.241600911559.issue15496@psf.upfronthosting.co.za> Brian Curtin added the comment: The latest patch to test.support looks reasonable. Go for it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 13 23:58:20 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 13 Aug 2012 21:58:20 +0000 Subject: [issue15633] httplib.response is not closed after all data has been read In-Reply-To: <1344821463.76.0.139090148106.issue15633@psf.upfronthosting.co.za> Message-ID: <1344895100.04.0.776543294618.issue15633@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 00:02:58 2012 From: report at bugs.python.org (Tim Golden) Date: Mon, 13 Aug 2012 22:02:58 +0000 Subject: [issue15496] harden directory removal for tests on Windows In-Reply-To: <1344894865.57.0.241600911559.issue15496@psf.upfronthosting.co.za> Message-ID: <5029798D.2050009@timgolden.me.uk> Tim Golden added the comment: Fine with me ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 00:06:27 2012 From: report at bugs.python.org (Matthias Klose) Date: Mon, 13 Aug 2012 22:06:27 +0000 Subject: [issue15631] Python 3.3 beta 1 installation issue lib/lib64 folders In-Reply-To: <1344794304.26.0.478120841355.issue15631@psf.upfronthosting.co.za> Message-ID: <1344895587.28.0.779953962592.issue15631@psf.upfronthosting.co.za> Matthias Klose added the comment: please could you attach the configure options, generated _sysconfigdata.py and a log of the install step? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 00:06:39 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 13 Aug 2012 22:06:39 +0000 Subject: [issue15633] httplib.response is not closed after all data has been read In-Reply-To: <1344821463.76.0.139090148106.issue15633@psf.upfronthosting.co.za> Message-ID: <1344895599.14.0.396785847864.issue15633@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Do you call read() or read()? Please inspect at least the "fp", "length", "chunked" and "chunk_left" attributes. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 00:13:14 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 13 Aug 2012 22:13:14 +0000 Subject: [issue15496] harden directory removal for tests on Windows In-Reply-To: <1343614495.69.0.283818579392.issue15496@psf.upfronthosting.co.za> Message-ID: <3WwrmS5g8MzPt5@mail.python.org> Roundup Robot added the comment: New changeset fcad4566910b by Brian Curtin in branch '3.2': Fix #15496. Add directory removal helpers to make Windows tests more reliable. Patch by Jeremy Kloth http://hg.python.org/cpython/rev/fcad4566910b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 00:13:15 2012 From: report at bugs.python.org (Matthias Klose) Date: Mon, 13 Aug 2012 22:13:15 +0000 Subject: [issue15631] Python 3.3 beta 1 installation issue lib/lib64 folders In-Reply-To: <1344794304.26.0.478120841355.issue15631@psf.upfronthosting.co.za> Message-ID: <1344895995.92.0.875221898731.issue15631@psf.upfronthosting.co.za> Matthias Klose added the comment: > File "/etc/pythonstart", line 5, in and this seems to be a patched/distro installation. Do you see this with an unpatched one as well? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 00:15:35 2012 From: report at bugs.python.org (Floris Bruynooghe) Date: Mon, 13 Aug 2012 22:15:35 +0000 Subject: [issue15643] Support OpenCSW in setup.py Message-ID: <1344896135.95.0.0625174180507.issue15643@psf.upfronthosting.co.za> New submission from Floris Bruynooghe: This patch proposes to add out of the box support for building against OpenCSW libraries on Solaris. It makes building all the extension modules a lot simpler since the CSW repositories provide almost all required libaries. The order of preference is /usr/local, then /opt/csw which should prefer libaries manually installed by the admin. ---------- components: Build files: csw_setup.py.diff keywords: patch messages: 168156 nosy: flub priority: normal severity: normal status: open title: Support OpenCSW in setup.py type: behavior versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file26789/csw_setup.py.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 00:27:16 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 13 Aug 2012 22:27:16 +0000 Subject: [issue15496] harden directory removal for tests on Windows In-Reply-To: <1343614495.69.0.283818579392.issue15496@psf.upfronthosting.co.za> Message-ID: <3Wws4g3ZFczPt2@mail.python.org> Roundup Robot added the comment: New changeset c863dadc65eb by Brian Curtin in branch '2.7': Fix #15496. Add directory removal helpers to make Windows tests more reliable. Patch by Jeremy Kloth http://hg.python.org/cpython/rev/c863dadc65eb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 00:28:00 2012 From: report at bugs.python.org (Brian Curtin) Date: Mon, 13 Aug 2012 22:28:00 +0000 Subject: [issue15496] harden directory removal for tests on Windows In-Reply-To: <1343614495.69.0.283818579392.issue15496@psf.upfronthosting.co.za> Message-ID: <1344896880.51.0.175767057474.issue15496@psf.upfronthosting.co.za> Changes by Brian Curtin : ---------- assignee: -> brian.curtin components: +Windows resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 00:30:33 2012 From: report at bugs.python.org (ita1024) Date: Mon, 13 Aug 2012 22:30:33 +0000 Subject: [issue15631] Python 3.3 beta 1 installation issue lib/lib64 folders In-Reply-To: <1344794304.26.0.478120841355.issue15631@psf.upfronthosting.co.za> Message-ID: <1344897033.78.0.180491513932.issue15631@psf.upfronthosting.co.za> ita1024 added the comment: I have not modified anything related to python on my opensuse install, i have only grabbed the latest tarball, compiled and installed. Here is the result with python 3.3.0 beta 2 ./configure make (sudo make install) > log I am observing the same outputs: $ /usr/local/bin/python3.3 Could not find platform dependent libraries Consider setting $PYTHONHOME to [:] Python 3.3.0b2 (default, Aug 14 2012, 00:25:40) [GCC 4.6.2] on linux Type "help", "copyright", "credits" or "license" for more information. Traceback (most recent call last): File "/etc/pythonstart", line 5, in import atexit ImportError: No module named 'atexit' >>> import atexit Traceback (most recent call last): File "", line 1, in ImportError: No module named 'atexit' >>> The file /etc/pythonstart contains: """ # startup script for python to enable saving of interpreter history and # enabling name completion # import needed modules import atexit import os import readline import rlcompleter # where is history saved historyPath = os.path.expanduser("~/.pyhistory") # handler for saving history def save_history(historyPath=historyPath): import readline readline.write_history_file(historyPath) # read history, if it exists if os.path.exists(historyPath): readline.set_history_length(10000) readline.read_history_file(historyPath) # register saving handler atexit.register(save_history) # enable completion readline.parse_and_bind('tab: complete') # cleanup del os, atexit, readline, rlcompleter, save_history, historyPath """ I will attach _sysconfigdata.py next (only one attachment) ---------- Added file: http://bugs.python.org/file26790/install_log.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 00:31:24 2012 From: report at bugs.python.org (ita1024) Date: Mon, 13 Aug 2012 22:31:24 +0000 Subject: [issue15631] Python 3.3 beta 1 installation issue lib/lib64 folders In-Reply-To: <1344794304.26.0.478120841355.issue15631@psf.upfronthosting.co.za> Message-ID: <1344897084.33.0.202901925332.issue15631@psf.upfronthosting.co.za> ita1024 added the comment: Here is the generated Lib/_sysconfigdata.py file ---------- Added file: http://bugs.python.org/file26791/_sysconfigdata.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 01:48:49 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 13 Aug 2012 23:48:49 +0000 Subject: [issue15269] Document dircmp.left and dircmp.right In-Reply-To: <1341635280.22.0.709109531165.issue15269@psf.upfronthosting.co.za> Message-ID: <1344901729.16.0.050287585922.issue15269@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 02:01:25 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 14 Aug 2012 00:01:25 +0000 Subject: [issue15364] sysconfig confused by relative paths In-Reply-To: <1342432899.52.0.53646689099.issue15364@psf.upfronthosting.co.za> Message-ID: <1344902485.5.0.72611558133.issue15364@psf.upfronthosting.co.za> Changes by Richard Oudkerk : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 02:01:58 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 14 Aug 2012 00:01:58 +0000 Subject: [issue15322] sysconfig.get_config_var('srcdir') returns unexpected value In-Reply-To: <1341972508.31.0.0905523614322.issue15322@psf.upfronthosting.co.za> Message-ID: <1344902518.62.0.138583915464.issue15322@psf.upfronthosting.co.za> Richard Oudkerk added the comment: I think #15364 is a duplicate of this. It should be fixed now. Can you check again. ---------- nosy: +sbt resolution: -> duplicate stage: -> committed/rejected status: open -> pending superseder: -> sysconfig confused by relative paths type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 02:11:07 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 14 Aug 2012 00:11:07 +0000 Subject: [issue15322] sysconfig.get_config_var('srcdir') returns unexpected value In-Reply-To: <1341972508.31.0.0905523614322.issue15322@psf.upfronthosting.co.za> Message-ID: <1344903067.64.0.939799379711.issue15322@psf.upfronthosting.co.za> Chris Jerdonek added the comment: It seems to be fixed now. Thanks. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 02:13:48 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 14 Aug 2012 00:13:48 +0000 Subject: [issue15322] sysconfig.get_config_var('srcdir') returns unexpected value In-Reply-To: <1341972508.31.0.0905523614322.issue15322@psf.upfronthosting.co.za> Message-ID: <1344903228.57.0.0301964032752.issue15322@psf.upfronthosting.co.za> Changes by Richard Oudkerk : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 03:02:21 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 14 Aug 2012 01:02:21 +0000 Subject: [issue15543] central documentation for 'universal newlines' In-Reply-To: <1343953234.25.0.0555174882779.issue15543@psf.upfronthosting.co.za> Message-ID: <1344906141.72.0.635720898191.issue15543@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Updating patch to latest again. ---------- nosy: +asvetlov Added file: http://bugs.python.org/file26792/issue-15543-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 03:13:07 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 14 Aug 2012 01:13:07 +0000 Subject: [issue12623] "universal newlines" subprocess support broken with select- and poll-based communicate() In-Reply-To: <1311451893.22.0.0169745025507.issue12623@psf.upfronthosting.co.za> Message-ID: <1344906787.14.0.242713751336.issue12623@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 03:35:12 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 14 Aug 2012 01:35:12 +0000 Subject: [issue9161] add_option in optparse no longer accepts unicode string In-Reply-To: <1278308192.07.0.362660691035.issue9161@psf.upfronthosting.co.za> Message-ID: <1344908112.07.0.827758571439.issue9161@psf.upfronthosting.co.za> R. David Murray added the comment: @Michael: Thanks for working on this. I don't see a patch attached to the issue, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 03:56:04 2012 From: report at bugs.python.org (Michael Johnson) Date: Tue, 14 Aug 2012 01:56:04 +0000 Subject: [issue9161] add_option in optparse no longer accepts unicode string In-Reply-To: <1278308192.07.0.362660691035.issue9161@psf.upfronthosting.co.za> Message-ID: <1344909364.75.0.698125976784.issue9161@psf.upfronthosting.co.za> Michael Johnson added the comment: Huh, let me try that again! I'm not sure how the attachment got dropped. ---------- keywords: +patch Added file: http://bugs.python.org/file26793/issue9161_test.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 04:02:31 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 14 Aug 2012 02:02:31 +0000 Subject: [issue15543] central documentation for 'universal newlines' In-Reply-To: <1343953234.25.0.0555174882779.issue15543@psf.upfronthosting.co.za> Message-ID: <1344909751.41.0.801518829594.issue15543@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks for working on this. I see nothing wrong with using 'universal newlines mode' as the term, which would simplify the markup. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 04:04:54 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Aug 2012 02:04:54 +0000 Subject: [issue9161] add_option in optparse no longer accepts unicode string In-Reply-To: <1278308192.07.0.362660691035.issue9161@psf.upfronthosting.co.za> Message-ID: <3Wwxvk142KzPwN@mail.python.org> Roundup Robot added the comment: New changeset 4c86a860e3d2 by R David Murray in branch '2.7': #9161: add test for the bug fixed by r82581. http://hg.python.org/cpython/rev/4c86a860e3d2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 04:05:22 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 14 Aug 2012 02:05:22 +0000 Subject: [issue9161] add_option in optparse no longer accepts unicode string In-Reply-To: <1278308192.07.0.362660691035.issue9161@psf.upfronthosting.co.za> Message-ID: <1344909922.43.0.162076416276.issue9161@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks! ---------- resolution: -> fixed stage: test needed -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 04:41:10 2012 From: report at bugs.python.org (Alexandre Vassalotti) Date: Tue, 14 Aug 2012 02:41:10 +0000 Subject: [issue15642] Integrate pickle protocol version 4 GSoC work by Stefan Mihaila In-Reply-To: <1344890920.23.0.695633734046.issue15642@psf.upfronthosting.co.za> Message-ID: <1344912070.97.0.269303874237.issue15642@psf.upfronthosting.co.za> Changes by Alexandre Vassalotti : Added file: http://bugs.python.org/file26794/pickle4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 04:42:07 2012 From: report at bugs.python.org (Alexandre Vassalotti) Date: Tue, 14 Aug 2012 02:42:07 +0000 Subject: [issue15642] Integrate pickle protocol version 4 GSoC work by Stefan Mihaila In-Reply-To: <1344890920.23.0.695633734046.issue15642@psf.upfronthosting.co.za> Message-ID: <1344912127.41.0.83304291081.issue15642@psf.upfronthosting.co.za> Changes by Alexandre Vassalotti : Removed file: http://bugs.python.org/file26794/pickle4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 04:42:43 2012 From: report at bugs.python.org (Alexandre Vassalotti) Date: Tue, 14 Aug 2012 02:42:43 +0000 Subject: [issue15642] Integrate pickle protocol version 4 GSoC work by Stefan Mihaila In-Reply-To: <1344890920.23.0.695633734046.issue15642@psf.upfronthosting.co.za> Message-ID: <1344912163.39.0.486448014821.issue15642@psf.upfronthosting.co.za> Changes by Alexandre Vassalotti : Added file: http://bugs.python.org/file26795/pickle4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 04:42:52 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 14 Aug 2012 02:42:52 +0000 Subject: [issue15543] central documentation for 'universal newlines' In-Reply-To: <1343953234.25.0.0555174882779.issue15543@psf.upfronthosting.co.za> Message-ID: <1344912172.61.0.307225667782.issue15543@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Sure, you're welcome. And sounds good, I'll change it. The singular was the prevailing form, but you're right that there is no reason we can't change it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 05:11:36 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 14 Aug 2012 03:11:36 +0000 Subject: [issue15543] central documentation for 'universal newlines' In-Reply-To: <1343953234.25.0.0555174882779.issue15543@psf.upfronthosting.co.za> Message-ID: <1344913896.14.0.322005603879.issue15543@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Is it worth standardizing on "universal newlines mode" in the code as well (docstrings, etc)? There are about ten occurrences of "universal newline mode" that would need to be changed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 05:39:29 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 14 Aug 2012 03:39:29 +0000 Subject: [issue6033] LOOKUP_METHOD and CALL_METHOD optimization In-Reply-To: <1242438240.35.0.944379800728.issue6033@psf.upfronthosting.co.za> Message-ID: <1344915569.93.0.741768322224.issue6033@psf.upfronthosting.co.za> R. David Murray added the comment: Benjamin confirms a regression in his patch, and the other patch was not intended for CPython. So I'm closing this issue. ---------- nosy: +r.david.murray stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 05:41:55 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 14 Aug 2012 03:41:55 +0000 Subject: [issue15543] central documentation for 'universal newlines' In-Reply-To: <1343953234.25.0.0555174882779.issue15543@psf.upfronthosting.co.za> Message-ID: <1344915715.16.0.885203798684.issue15543@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Here is a new patch with David's suggested change (just for doc files though). ---------- Added file: http://bugs.python.org/file26796/issue-15543-4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 05:45:13 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 14 Aug 2012 03:45:13 +0000 Subject: [issue7231] Windows installer does not add \Scripts folder to the path In-Reply-To: <1256749152.57.0.801313448944.issue7231@psf.upfronthosting.co.za> Message-ID: <1344915913.84.0.00714071165304.issue7231@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- resolution: -> duplicate stage: needs patch -> committed/rejected status: open -> closed superseder: -> Windows installer should add Python and Scripts directories to the PATH environment variable _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 06:21:02 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Aug 2012 04:21:02 +0000 Subject: [issue15586] Provide some examples for usage of ElementTree methods/attributes In-Reply-To: <1344407679.24.0.102359835139.issue15586@psf.upfronthosting.co.za> Message-ID: <3Wx0ws3p1czPwJ@mail.python.org> Roundup Robot added the comment: New changeset fc66730dae4c by Eli Bendersky in branch 'default': Issue #15586: add some examples to ElementTree documentation. Patch by Daniel Ellis. http://hg.python.org/cpython/rev/fc66730dae4c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 06:30:35 2012 From: report at bugs.python.org (Eli Bendersky) Date: Tue, 14 Aug 2012 04:30:35 +0000 Subject: [issue15586] Provide some examples for usage of ElementTree methods/attributes In-Reply-To: <1344407679.24.0.102359835139.issue15586@psf.upfronthosting.co.za> Message-ID: <1344918635.32.0.955169376578.issue15586@psf.upfronthosting.co.za> Eli Bendersky added the comment: I committed your patch to default (3.3) with some minor fixes. Please go over them as you will need to apply them to the 2.7 patch. I've reviewed the 2.7 patch as well - it's an initial review. Did you execute all the code samples on 2.7? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 07:03:31 2012 From: report at bugs.python.org (umedoblock) Date: Tue, 14 Aug 2012 05:03:31 +0000 Subject: [issue15644] after _bytesio.seek(0), _bytesio.getvalue() returned reversed data. Message-ID: <1344920611.47.0.245957417255.issue15644@psf.upfronthosting.co.za> New submission from umedoblock: import io _bytesio = io.BytesIO() _bytesio.write(b'abc') _bytesio.write(b'def') _bytesio.seek(0) _bytesio.write(b'xyz') print(_bytesio.read(2)) print(_bytesio.read(2)) print(_bytesio.getvalue()) # output b'de' b'f' b'xyzdef' # where is the b'abc' ? ---------- components: IO messages: 168174 nosy: umedoblock priority: normal severity: normal status: open title: after _bytesio.seek(0), _bytesio.getvalue() returned reversed data. type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 07:34:46 2012 From: report at bugs.python.org (Alexandre Vassalotti) Date: Tue, 14 Aug 2012 05:34:46 +0000 Subject: [issue15642] Integrate pickle protocol version 4 GSoC work by Stefan Mihaila In-Reply-To: <1344890920.23.0.695633734046.issue15642@psf.upfronthosting.co.za> Message-ID: <1344922486.44.0.685594361951.issue15642@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: I get warnings when compiling with the patch: /home/avassalotti/pickle4/Modules/_pickle.c: In function ?save_global_binary?: /home/avassalotti/pickle4/Modules/_pickle.c:2952: warning: pointer targets in passing argument 2 of ?_Pickler_Write? differ in signedness /home/avassalotti/pickle4/Modules/_pickle.c:872: note: expected ?const char *? but argument is of type ?unsigned char *? /home/avassalotti/pickle4/Modules/_pickle.c:2956: warning: pointer targets in passing argument 2 of ?_Pickler_Write? differ in signedness /home/avassalotti/pickle4/Modules/_pickle.c:872: note: expected ?const char *? but argument is of type ?unsigned char *? /home/avassalotti/pickle4/Modules/_pickle.c:2960: warning: pointer targets in passing argument 2 of ?_Pickler_Write? differ in signedness /home/avassalotti/pickle4/Modules/_pickle.c:872: note: expected ?const char *? but argument is of type ?unsigned char *? /home/avassalotti/pickle4/Modules/_pickle.c:2975: warning: pointer targets in passing argument 2 of ?_Pickler_Write? differ in signedness /home/avassalotti/pickle4/Modules/_pickle.c:872: note: expected ?const char *? but argument is of type ?unsigned char *? /home/avassalotti/pickle4/Modules/_pickle.c:2979: warning: pointer targets in passing argument 2 of ?_Pickler_Write? differ in signedness /home/avassalotti/pickle4/Modules/_pickle.c:872: note: expected ?const char *? but argument is of type ?unsigned char *? /home/avassalotti/pickle4/Modules/_pickle.c:2988: warning: pointer targets in passing argument 2 of ?_Pickler_Write? differ in signedness /home/avassalotti/pickle4/Modules/_pickle.c:872: note: expected ?const char *? but argument is of type ?unsigned char *? /home/avassalotti/pickle4/Modules/_pickle.c:3012: warning: pointer targets in passing argument 2 of ?_Pickler_Write? differ in signedness /home/avassalotti/pickle4/Modules/_pickle.c:872: note: expected ?const char *? but argument is of type ?unsigned char *? /home/avassalotti/pickle4/Modules/_pickle.c: In function ?save_set?: /home/avassalotti/pickle4/Modules/_pickle.c:3368: warning: suggest parentheses around assignment used as truth value /home/avassalotti/pickle4/Modules/_pickle.c: In function ?save_frozenset?: /home/avassalotti/pickle4/Modules/_pickle.c:3422: warning: suggest parentheses around assignment used as truth value These should be fixed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 07:46:48 2012 From: report at bugs.python.org (Alexandre Vassalotti) Date: Tue, 14 Aug 2012 05:46:48 +0000 Subject: [issue15642] Integrate pickle protocol version 4 GSoC work by Stefan Mihaila In-Reply-To: <1344890920.23.0.695633734046.issue15642@psf.upfronthosting.co.za> Message-ID: <1344923208.22.0.514950767906.issue15642@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: There are reference leaks in the _pickle.c part that will need to be fixed too. 22:36:29 [~/pickle4]$ ./python -m test.regrtest -R :: test_pickle [1/1] test_pickle beginning 9 repetitions 123456789 ......... test_pickle leaked [14780, 14780, 14780, 14780] references, sum=59120 1 test failed: test_pickle [319952 refs] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 08:36:52 2012 From: report at bugs.python.org (Ned Deily) Date: Tue, 14 Aug 2012 06:36:52 +0000 Subject: [issue15644] after _bytesio.seek(0), _bytesio.getvalue() returned reversed data. In-Reply-To: <1344920611.47.0.245957417255.issue15644@psf.upfronthosting.co.za> Message-ID: <1344926212.37.0.0621820525267.issue15644@psf.upfronthosting.co.za> Ned Deily added the comment: The program works as expected. After the first two writes, the buffer contains b'abcdef'. Then the seek(0) moves the stream pointer to the beginning of the buffer and the next write overwrites buffer positions 0 through 2, replacing b'abc' with b'xyz'. So now the buffer is b'xyzdef'. The next read starts at position 3 (following the last byte written), reading b'de'. ---------- nosy: +ned.deily resolution: -> works for me stage: -> committed/rejected status: open -> closed type: behavior -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 08:55:11 2012 From: report at bugs.python.org (Juan Javier) Date: Tue, 14 Aug 2012 06:55:11 +0000 Subject: [issue15634] synchronized decorator for the threading module In-Reply-To: <1344845068.87.0.536585589553.issue15634@psf.upfronthosting.co.za> Message-ID: <1344927311.65.0.995436947648.issue15634@psf.upfronthosting.co.za> Juan Javier added the comment: Ok, you are right, serialized is the right name. Also, passing the lock to the decorator will the correct option. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 10:10:20 2012 From: report at bugs.python.org (Juan Javier) Date: Tue, 14 Aug 2012 08:10:20 +0000 Subject: [issue15634] synchronized decorator for the threading module In-Reply-To: <1344845068.87.0.536585589553.issue15634@psf.upfronthosting.co.za> Message-ID: <1344931820.32.0.124442017039.issue15634@psf.upfronthosting.co.za> Juan Javier added the comment: What about this? def serialized(lock): def _serialized(func): def __serialized(*args, **kwds): with lock: return func(*args, **kwds) __serialized.__doc__ = func.__doc__ return __serialized return _serialized ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 10:16:20 2012 From: report at bugs.python.org (Stefan Holek) Date: Tue, 14 Aug 2012 08:16:20 +0000 Subject: [issue15645] 2to3 Grammar pickles not created when upgrading to 3.3.0b2 Message-ID: <1344932180.41.0.826216341416.issue15645@psf.upfronthosting.co.za> New submission from Stefan Holek: After upgrading 3.3.0b1 to b2 (make install to same location) I noticed that the Grammar pickles for beta.2 were missing (the beta.1 pickles still being there). The result is permission errors and/or virtualenv SandboxViolations, when 2to3 is used for the first time. E.g.: SandboxViolation: open('/usr/local/python3.3/lib/python3.3/lib2to3/Grammar3.3.0.beta.2.pickle', 'wb') {} This is because users of Python (as opposed to root) may of course not write to the library dir. The pickles are created fine on a fresh install of Python 3.3.0b2 (make install to new location). ---------- components: 2to3 (2.x to 3.x conversion tool) messages: 168180 nosy: stefanholek priority: normal severity: normal status: open title: 2to3 Grammar pickles not created when upgrading to 3.3.0b2 versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 11:07:39 2012 From: report at bugs.python.org (Robin Schreiber) Date: Tue, 14 Aug 2012 09:07:39 +0000 Subject: [issue14935] PEP 384 Refactoring applied to _csv module In-Reply-To: <1338222171.68.0.797250497291.issue14935@psf.upfronthosting.co.za> Message-ID: <1344935259.54.0.102096376649.issue14935@psf.upfronthosting.co.za> Robin Schreiber added the comment: Fixed the dealloc-methods of the types, for proper type dereferencing. ---------- Added file: http://bugs.python.org/file26797/csv_pep384_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 11:08:16 2012 From: report at bugs.python.org (Robin Schreiber) Date: Tue, 14 Aug 2012 09:08:16 +0000 Subject: [issue14935] PEP 384 Refactoring applied to _csv module In-Reply-To: <1338222171.68.0.797250497291.issue14935@psf.upfronthosting.co.za> Message-ID: <1344935296.84.0.610995816743.issue14935@psf.upfronthosting.co.za> Changes by Robin Schreiber : ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 11:19:54 2012 From: report at bugs.python.org (Stefan Krah) Date: Tue, 14 Aug 2012 09:19:54 +0000 Subject: [issue15632] regrtest.py: spurious leaks with -R option In-Reply-To: <1344799906.56.0.0975538971998.issue15632@psf.upfronthosting.co.za> Message-ID: <1344935994.08.0.390973997246.issue15632@psf.upfronthosting.co.za> Stefan Krah added the comment: Should we go all the way and also explicitly fill the small int cache? Integers 0-255 should be initialized already, but I'm not sure about [-5..-1] and 256. I haven't been able to create a test case for integers though. ---------- Added file: http://bugs.python.org/file26798/issue15632.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 11:29:29 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 14 Aug 2012 09:29:29 +0000 Subject: [issue15269] Document dircmp.left and dircmp.right In-Reply-To: <1341635280.22.0.709109531165.issue15269@psf.upfronthosting.co.za> Message-ID: <1344936569.51.0.437033047797.issue15269@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Hi Chris & Eli, - Sorry that I missed this issue. Chris - agree to your rationale. I can see how having self.left and self.right documented can add value, The diff example was useful. Initially, I did have some doubts in terms how it could be useful when the args are sent by the user, your example clarified. Thanks!. As Eli has looked at this one too, I shall commit the patch. Everything is good. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 11:36:36 2012 From: report at bugs.python.org (Matthias Klose) Date: Tue, 14 Aug 2012 09:36:36 +0000 Subject: [issue15631] Python 3.3 beta 1 installation issue lib/lib64 folders In-Reply-To: <1344794304.26.0.478120841355.issue15631@psf.upfronthosting.co.za> Message-ID: <1344936996.01.0.361214820047.issue15631@psf.upfronthosting.co.za> Matthias Klose added the comment: the configure step sets LIBDIR to /usr/local/lib64. Please find out why this is not set to /usr/local/lib. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 11:39:30 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 14 Aug 2012 09:39:30 +0000 Subject: [issue15269] Document dircmp.left and dircmp.right In-Reply-To: <1341635280.22.0.709109531165.issue15269@psf.upfronthosting.co.za> Message-ID: <1344937170.98.0.654699695927.issue15269@psf.upfronthosting.co.za> Senthil Kumaran added the comment: As this is not adding any feature, but just an additional clarification to the existing attribute together with some useful documentation, I believe this can go in 2.7, 3.2 and 3.3 Please correct me if I am wrong here. ---------- versions: +Python 2.7, Python 3.2, Python 3.3 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 11:46:45 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 14 Aug 2012 09:46:45 +0000 Subject: [issue15269] Document dircmp.left and dircmp.right In-Reply-To: <1341635280.22.0.709109531165.issue15269@psf.upfronthosting.co.za> Message-ID: <1344937605.18.0.246038403593.issue15269@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Thanks a lot, Senthil. I appreciate it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 12:00:20 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 14 Aug 2012 10:00:20 +0000 Subject: [issue15543] central documentation for 'universal newlines' In-Reply-To: <1343953234.25.0.0555174882779.issue15543@psf.upfronthosting.co.za> Message-ID: <1344938420.52.0.743129941329.issue15543@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Updating patch to tip again. ---------- Added file: http://bugs.python.org/file26799/issue-15543-5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 12:07:35 2012 From: report at bugs.python.org (Stefan Krah) Date: Tue, 14 Aug 2012 10:07:35 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1344938855.37.0.712662302607.issue15573@psf.upfronthosting.co.za> Stefan Krah added the comment: Here is a patch implementing by-value comparisons for all format strings understood by the struct module. It is slightly longer than promised, since for larger arrays it is necessary to cache an unpacking object for acceptable performance. The fast path for identical single element native format strings is unchanged. The new comparison rules are stated in the memoryview docs. For Georg's benefit, here are the memoryobject.c changes and the reasons why I think the patch can go into 3.3: o cmp_structure() is split into cmp_format() and cmp_shape(), with unchanged semantics. o The new section "unpack using the struct module" is largely identical to existing parts of _testbuffer.c: - struct_get_unpacker() ==> see _testbuffer.c:ndarray_as_list() - struct_unpack_single() ==> see base case in _testbuffer.c:unpack_rec() o The new code is only called in the previous default case of unpack_cmp(). o The new code has 100% coverage. Performance: ============ Identical format, bytes: ------------------------ $ ./python -m timeit -n 1000 -s "import array; x = array.array('B', [1]*10000); y = array.array('B', [1]*10000);" "x == y" 1000 loops, best of 3: 116 usec per loop $ ./python -m timeit -n 1000 -s "import array; x = array.array('B', [1]*10000); y = array.array('B', [1]*10000); a = memoryview(x); b = memoryview(y)" "a == b" 1000 loops, best of 3: 49.1 usec per loop Identical format, double: ------------------------- $ ./python -m timeit -n 1000 -s "import array; x = array.array('d', [1.0]*10000); y = array.array('d', [1.0]*10000);" "x == y" 1000 loops, best of 3: 319 usec per loop $ ./python -m timeit -n 1000 -s "import array; x = array.array('d', [1.0]*10000); y = array.array('d', [1.0]*10000); a = memoryview(x); b = memoryview(y)" "a == b" 1000 loops, best of 3: 65.7 usec per loop Different format ('B', 'b'): ---------------------------- $ ./python -m timeit -n 100 -s "import array; x = array.array('B', [1]*10000); y = array.array('b', [1]*10000);" "x == y" 100 loops, best of 3: 131 usec per loop $ ./python -m timeit -n 1000 -s "import array; x = array.array('B', [1]*10000); y = array.array('b', [1]*10000); a = memoryview(x); b = memoryview(y)" "a == b" 1000 loops, best of 3: 3.42 msec per loop Different format ('d', 'f'): ---------------------------- $ ./python -m timeit -n 1000 -s "import array; x = array.array('d', [1.0]*10000); y = array.array('f', [1.0]*10000);" "x == y" 1000 loops, best of 3: 315 usec per loop $ ./python -m timeit -n 1000 -s "import array; x = array.array('d', [1.0]*10000); y = array.array('f', [1.0]*10000); a = memoryview(x); b = memoryview(y)" "a == b" 1000 loops, best of 3: 3.59 msec per loop ---------- Added file: http://bugs.python.org/file26800/issue15573-struct.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 12:34:33 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 14 Aug 2012 10:34:33 +0000 Subject: [issue15646] multiprocessing can do equivalent of a fork bomb on Windows Message-ID: <1344940473.31.0.674341718518.issue15646@psf.upfronthosting.co.za> New submission from Richard Oudkerk: If the "if __name__ == '__main__'" idiom is not used on Windows you can get the recursive starting of new processes. This is because importing the main module in a child process starts a new child process as a side effect. There is a test intended to prevent this and raise RuntimeError instead, but it is currently ineffective. ---------- messages: 168189 nosy: sbt priority: normal severity: normal status: open title: multiprocessing can do equivalent of a fork bomb on Windows type: behavior versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 12:41:12 2012 From: report at bugs.python.org (Matthias Klose) Date: Tue, 14 Aug 2012 10:41:12 +0000 Subject: [issue15647] isdir should be a local symbol, not exported Message-ID: <1344940872.16.0.49661392396.issue15647@psf.upfronthosting.co.za> New submission from Matthias Klose: 2.7 only: isdir should not be exported, but a local symbol instead (this was accidentally changed after the 2.7.3 release. currently defined and used in Modules/getpath.c and Python/import.c, and used in Python/bltinmodule.c proposal to rename the implementation in import.c to _Py_isdir and use it in import.c and bltinmodule.c. as an alternative, make the isdir implementation static for windows and posix builds. ---------- components: Interpreter Core files: local-isdir-symbol.diff keywords: needs review, patch messages: 168190 nosy: doko priority: normal severity: normal status: open title: isdir should be a local symbol, not exported versions: Python 2.7 Added file: http://bugs.python.org/file26801/local-isdir-symbol.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 13:12:05 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 14 Aug 2012 11:12:05 +0000 Subject: [issue6135] subprocess seems to use local encoding and give no choice In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za> Message-ID: <1344942725.6.0.213100894837.issue6135@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > > only one Popen instance (for the iconv call), but different encodings > > for stdin and stdout. > Isn't that the exception rather than the rule? I think it actually makes > sense, in at least 99.83% of cases ;-), to have a common encoding > setting for all streams. FWIW, I recently encountered a scenario (albeit in a test situation) where the ability to set different encodings for stdout and stderr would have been useful to me. It was while creating a test case for issue 15595. I was changing the locale encoding for stdout, but I also wanted to leave it unchanged for stderr because there didn't seem to be a way to control the encoding that the child used for stderr. ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 13:40:28 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 14 Aug 2012 11:40:28 +0000 Subject: [issue15648] stderr "refs" output does not respect PYTHONIOENCODING Message-ID: <1344944428.64.0.0280287905357.issue15648@psf.upfronthosting.co.za> New submission from Chris Jerdonek: The --help documentation for the python executable says-- PYTHONIOENCODING: Encoding[:errors] used for stdin/stdout/stderr. However, PYTHONIOENCODING doesn't seem to be respected for the python executable's "refs" output to stderr. For example, this-- args = [sys.executable, '-c', "print('[100 refs]')"] env = {'PYTHONIOENCODING': 'utf-8'} popen = Popen(args, universal_newlines=False, stdin=PIPE, stdout=PIPE, stderr=PIPE, env=env) print(repr(popen.communicate())) env = {'PYTHONIOENCODING': 'utf-16'} popen = Popen(args, universal_newlines=False, stdin=PIPE, stdout=PIPE, stderr=PIPE, env=env) print(repr(popen.communicate())) yields-- (b'[10 refs]\n', b'[41761 refs]\n') (b'[\x001\x000\x00 \x00r\x00e\x00f\x00s\x00]\x00\n\x00', b'[42367 refs]\n') ---------- messages: 168192 nosy: cjerdonek priority: normal severity: normal status: open title: stderr "refs" output does not respect PYTHONIOENCODING versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 13:54:13 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 14 Aug 2012 11:54:13 +0000 Subject: [issue15645] 2to3 Grammar pickles not created when upgrading to 3.3.0b2 In-Reply-To: <1344932180.41.0.826216341416.issue15645@psf.upfronthosting.co.za> Message-ID: <1344945253.18.0.129024312522.issue15645@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 13:55:22 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Aug 2012 11:55:22 +0000 Subject: [issue15646] multiprocessing can do equivalent of a fork bomb on Windows In-Reply-To: <1344940473.31.0.674341718518.issue15646@psf.upfronthosting.co.za> Message-ID: <3WxC144fkvzQ2v@mail.python.org> Roundup Robot added the comment: New changeset e4fe1daef9f7 by Richard Oudkerk in branch '2.7': Issue #15646: Prevent equivalent of a fork bomb when using multiprocessing http://hg.python.org/cpython/rev/e4fe1daef9f7 New changeset 20f8a2455ffb by Richard Oudkerk in branch '3.2': Issue #15646: Prevent equivalent of a fork bomb when using multiprocessing http://hg.python.org/cpython/rev/20f8a2455ffb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 14:28:32 2012 From: report at bugs.python.org (Xavier Morel) Date: Tue, 14 Aug 2012 12:28:32 +0000 Subject: [issue15639] csv.Error description is incorrectly broad In-Reply-To: <1344861900.41.0.500081964818.issue15639@psf.upfronthosting.co.za> Message-ID: <1344947312.86.0.637810464409.issue15639@psf.upfronthosting.co.za> Xavier Morel added the comment: Correction: csv also seems to raise csv.Error if the file contains NUL bytes: Error: line contains NULL byte ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 14:45:33 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Aug 2012 12:45:33 +0000 Subject: [issue14167] document return statement in finally blocks In-Reply-To: <1330614429.57.0.59180427723.issue14167@psf.upfronthosting.co.za> Message-ID: <3WxD7012klzQ2j@mail.python.org> Roundup Robot added the comment: New changeset e0e8e70e4035 by Andrew Svetlov in branch '3.2': Issue #14167: Document return statement in finally blocks. http://hg.python.org/cpython/rev/e0e8e70e4035 New changeset 05714e9811fa by Andrew Svetlov in branch 'default': Issue #14167: Document return statement in finally blocks. http://hg.python.org/cpython/rev/05714e9811fa New changeset bef098bd3fa5 by Andrew Svetlov in branch '2.7': Issue #14167: Document return statement in finally blocks. http://hg.python.org/cpython/rev/bef098bd3fa5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 14:46:27 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Tue, 14 Aug 2012 12:46:27 +0000 Subject: [issue14167] document return statement in finally blocks In-Reply-To: <1330614429.57.0.59180427723.issue14167@psf.upfronthosting.co.za> Message-ID: <1344948387.67.0.331434392406.issue14167@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Fixed. Thanks. ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 14:56:02 2012 From: report at bugs.python.org (Nikolaus Rath) Date: Tue, 14 Aug 2012 12:56:02 +0000 Subject: [issue15633] httplib.response is not closed after all data has been read In-Reply-To: <1344821463.76.0.139090148106.issue15633@psf.upfronthosting.co.za> Message-ID: <1344948962.37.0.466676065359.issue15633@psf.upfronthosting.co.za> Nikolaus Rath added the comment: The call should be read(size), with size a number. I will make sure to check size, "fp", "length", "chunked" and "chunk_left" when it happens the next time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 15:12:32 2012 From: report at bugs.python.org (Daniel Ellis) Date: Tue, 14 Aug 2012 13:12:32 +0000 Subject: [issue15586] Provide some examples for usage of ElementTree methods/attributes In-Reply-To: <1344407679.24.0.102359835139.issue15586@psf.upfronthosting.co.za> Message-ID: <1344949952.95.0.37554789938.issue15586@psf.upfronthosting.co.za> Daniel Ellis added the comment: Thank you for the review Eli. I've made your changes and attached the updated patch. I did run all of the code snippets that are being added on 2.7, and the only thing I found different was the changed print statement. I don't believe I overlooked anything, but I may have made a mistake. ---------- Added file: http://bugs.python.org/file26802/2.7_branch_etree_doc_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 15:14:53 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Aug 2012 13:14:53 +0000 Subject: [issue9161] add_option in optparse no longer accepts unicode string In-Reply-To: <1278308192.07.0.362660691035.issue9161@psf.upfronthosting.co.za> Message-ID: <3WxDmq5J5yzQ30@mail.python.org> Roundup Robot added the comment: New changeset ffd70c371fee by R David Murray in branch '2.7': #9161: Fix test to use standard optparse test pattern (what was I thinking?) http://hg.python.org/cpython/rev/ffd70c371fee ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 15:43:49 2012 From: report at bugs.python.org (Stefan Mihaila) Date: Tue, 14 Aug 2012 13:43:49 +0000 Subject: [issue15642] Integrate pickle protocol version 4 GSoC work by Stefan Mihaila In-Reply-To: <1344890920.23.0.695633734046.issue15642@psf.upfronthosting.co.za> Message-ID: <1344951829.67.0.388173467467.issue15642@psf.upfronthosting.co.za> Stefan Mihaila added the comment: Maybe we could postpone the review process for a few days until I fix some known issues ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 15:56:53 2012 From: report at bugs.python.org (umedoblock) Date: Tue, 14 Aug 2012 13:56:53 +0000 Subject: [issue15644] after _bytesio.seek(0), _bytesio.getvalue() returned reversed data. In-Reply-To: <1344920611.47.0.245957417255.issue15644@psf.upfronthosting.co.za> Message-ID: <1344952613.29.0.932078052354.issue15644@psf.upfronthosting.co.za> umedoblock added the comment: thanks Ned. I understood your comment. I'm happy! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 16:38:15 2012 From: report at bugs.python.org (Stefan Krah) Date: Tue, 14 Aug 2012 14:38:15 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1344955095.19.0.921590167381.issue15573@psf.upfronthosting.co.za> Stefan Krah added the comment: I didn't get my own comments as mail, so this is just a notification that I've answered Nick's comments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 17:14:43 2012 From: report at bugs.python.org (Stan Seibert) Date: Tue, 14 Aug 2012 15:14:43 +0000 Subject: [issue13370] test_ctypes fails when building python with clang In-Reply-To: <1320761474.93.0.268896325495.issue13370@psf.upfronthosting.co.za> Message-ID: <1344957283.02.0.350227231675.issue13370@psf.upfronthosting.co.za> Stan Seibert added the comment: FYI: This bug still exists using the version of clang shipped with OS X 10.8. Tested with Python 3.3.0b2 and: Apple clang version 4.0 (tags/Apple/clang-421.0.57) (based on LLVM 3.1svn) Target: x86_64-apple-darwin12.0.0 Thread model: posix ---------- nosy: +Stan.Seibert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 17:35:52 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 14 Aug 2012 15:35:52 +0000 Subject: [issue15646] multiprocessing can do equivalent of a fork bomb on Windows In-Reply-To: <1344940473.31.0.674341718518.issue15646@psf.upfronthosting.co.za> Message-ID: <1344958552.42.0.440244992739.issue15646@psf.upfronthosting.co.za> Changes by Richard Oudkerk : ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 17:43:11 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Aug 2012 15:43:11 +0000 Subject: [issue15592] subprocess.communicate() breaks on no input with universal newlines true In-Reply-To: <1344443880.03.0.234384317121.issue15592@psf.upfronthosting.co.za> Message-ID: <3WxJ3y0DbvzQ4l@mail.python.org> Roundup Robot added the comment: New changeset 839bd8f98539 by Andrew Svetlov in branch '3.2': Add test to explicit check the absence regression in subprocess (issue #15592). http://hg.python.org/cpython/rev/839bd8f98539 New changeset 9d86480cc177 by Andrew Svetlov in branch 'default': Issue #15592. Fix regression: subprocess.communicate() breaks on no input with universal newlines true. http://hg.python.org/cpython/rev/9d86480cc177 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 17:45:52 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Aug 2012 15:45:52 +0000 Subject: [issue15647] isdir should be a local symbol, not exported In-Reply-To: <1344940872.16.0.49661392396.issue15647@psf.upfronthosting.co.za> Message-ID: <3WxJ7338z4zQ4q@mail.python.org> Roundup Robot added the comment: New changeset bdd1b2228c14 by Matthias Klose in branch '2.7': - Issue #15647: Make isdir static for windows and posix http://hg.python.org/cpython/rev/bdd1b2228c14 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 17:46:41 2012 From: report at bugs.python.org (Matthias Klose) Date: Tue, 14 Aug 2012 15:46:41 +0000 Subject: [issue15647] isdir should be a local symbol, not exported In-Reply-To: <1344940872.16.0.49661392396.issue15647@psf.upfronthosting.co.za> Message-ID: <1344959201.63.0.127523219118.issue15647@psf.upfronthosting.co.za> Matthias Klose added the comment: fixed for 2.7, made isdir static on windows and posix ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 17:47:01 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Tue, 14 Aug 2012 15:47:01 +0000 Subject: [issue15649] subprocess.Popen.communicate: accept str for input parameter if universal_newlines is False Message-ID: <1344959221.38.0.0409924242397.issue15649@psf.upfronthosting.co.za> New submission from Andrew Svetlov: Currently Popen.communicate accept str is universal_newlines==True and bytes if universal_newlines==False. I like to accept both str and bytes if universal_newlines is False and raise explicit exception for bytes if universal_newlines is True. Looks like universal_newlines for bytes doesn't make sense, also we prefer to use str everywhere. Bytes should be used if it is really byte-stream or if unicode cannot be passed by some limitations of underlying OS etc. There are couple dark corners: 1. What to do if stdin doesn't have `encoding` attribute? Convert to bytes using filesystemencoding? Raise explicit exception? Adding `encode` parameter for .communicate doesn't looks elegant. 2. How .communicate works on Windows? I see completely different implementation of this method for win32. ---------- messages: 168207 nosy: asvetlov priority: normal severity: normal stage: needs patch status: open title: subprocess.Popen.communicate: accept str for input parameter if universal_newlines is False type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 17:49:27 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Tue, 14 Aug 2012 15:49:27 +0000 Subject: [issue15649] subprocess.Popen.communicate: accept str for input parameter if universal_newlines is False In-Reply-To: <1344959221.38.0.0409924242397.issue15649@psf.upfronthosting.co.za> Message-ID: <1344959367.0.0.929716114226.issue15649@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- components: +Library (Lib) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 17:49:48 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Tue, 14 Aug 2012 15:49:48 +0000 Subject: [issue15592] subprocess.communicate() breaks on no input with universal newlines true In-Reply-To: <1344443880.03.0.234384317121.issue15592@psf.upfronthosting.co.za> Message-ID: <1344959388.56.0.303975844566.issue15592@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Close the issue. Thanks, Chris. It was the real regression, 3.2 works fine. See also #15649 for accepting str if not universal_newlines. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 18:01:23 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Tue, 14 Aug 2012 16:01:23 +0000 Subject: [issue15204] Deprecate the 'U' open mode In-Reply-To: <1340792991.22.0.497199331706.issue15204@psf.upfronthosting.co.za> Message-ID: <1344960083.15.0.605916499756.issue15204@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 18:29:16 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 14 Aug 2012 16:29:16 +0000 Subject: [issue15592] subprocess.communicate() breaks on no input with universal newlines true In-Reply-To: <1344443880.03.0.234384317121.issue15592@psf.upfronthosting.co.za> Message-ID: <1344961756.67.0.878082110035.issue15592@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Thanks, Andrew! ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 18:29:57 2012 From: report at bugs.python.org (Brett Cannon) Date: Tue, 14 Aug 2012 16:29:57 +0000 Subject: [issue15623] Init time relative imports no longer work from __init__.so modules In-Reply-To: <1344697325.25.0.880049566038.issue15623@psf.upfronthosting.co.za> Message-ID: <1344961797.57.0.566410267439.issue15623@psf.upfronthosting.co.za> Brett Cannon added the comment: I had a minute free so I just tried inserting an empty module into sys.modules and then importing an extension module to see if it would get reused. It doesn't. imp.load_dynamic() actually just blindly overwrites what is in sys.modules. I'm willing to bet it just assumes whatever is in the special extensions module cache is the canonical module and just re-inserts blindly into sys.modules. So that leaves needing to diagnose where Python 3.3 inserts an extension into sys.modules and if it can somehow be moved up. Probably should also see how the heck 3.2 is doing it to know where the difference occurs to make sure that it isn't some silly oversight somehow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 18:35:40 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 14 Aug 2012 16:35:40 +0000 Subject: [issue15649] subprocess.Popen.communicate: accept str for input parameter if universal_newlines is False In-Reply-To: <1344959221.38.0.0409924242397.issue15649@psf.upfronthosting.co.za> Message-ID: <1344962140.26.0.00230242097397.issue15649@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > What to do if stdin doesn't have `encoding` attribute? Convert to bytes using filesystemencoding? If choosing an encoding, it probably makes sense to default to the same as for when universal_newlines=True, namely locale.getpreferredencoding(False). > Adding `encode` parameter for .communicate doesn't looks elegant. Also see issue 6135 (to allow setting encoding). ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 18:39:05 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Tue, 14 Aug 2012 16:39:05 +0000 Subject: [issue14649] doctest.DocTestSuite error misleading when module has no docstrings In-Reply-To: <1335192861.9.0.305748973415.issue14649@psf.upfronthosting.co.za> Message-ID: <1344962345.68.0.404339534486.issue14649@psf.upfronthosting.co.za> Andrew Svetlov added the comment: I think current behavior is correct. Every doctest is docstring from tested module, but not every docstring is a valid doctest. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 18:40:29 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 14 Aug 2012 16:40:29 +0000 Subject: [issue6135] subprocess seems to use local encoding and give no choice In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za> Message-ID: <1344962429.86.0.0968850728686.issue6135@psf.upfronthosting.co.za> Chris Jerdonek added the comment: To my previous comment, issue 15648 shows the case where I was able to change the encoding for stdout in the child process but not stderr (which would require supporting two encodings in Popen to handle). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 19:17:44 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 14 Aug 2012 17:17:44 +0000 Subject: [issue14649] doctest.DocTestSuite error misleading when module has no docstrings In-Reply-To: <1335192861.9.0.305748973415.issue14649@psf.upfronthosting.co.za> Message-ID: <1344964664.91.0.456613261791.issue14649@psf.upfronthosting.co.za> R. David Murray added the comment: Chris isn't suggesting changing the behavior, just the error message. I agree with his change for exactly the reason you say: currently doctest doesn't complain if a module does have docstrings but none of those docstrings are tests. So a module could have no tests without the error being raised. However, I suspect that the current behavior is a bug. I suspect the intent was to raise an error if there were no *tests*, not if there were no docstrings. I don't think it is a bug that should be fixed, though. I have a couple of test runners in various projects that run doctest on *all* modules, the goal being to pick up any doctests that there are or that I may add, even though not all modules have docstrings that contain doctests. The doctest version of TestCase-based discovery. So if anything I think this exception should be dropped. If the report is that no tests are run, that should be enough of an indication that something is wrong, without raising an error, as it has been for the case where there are docstrings but no tests (we do not as far as I know have a bug or feature request that the current behavior is inadequate). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 20:09:30 2012 From: report at bugs.python.org (Robin Schreiber) Date: Tue, 14 Aug 2012 18:09:30 +0000 Subject: [issue15390] PEP 3121, 384 refactoring applied to datetime module In-Reply-To: <1342647232.82.0.0763290244077.issue15390@psf.upfronthosting.co.za> Message-ID: <1344967770.31.0.504621736592.issue15390@psf.upfronthosting.co.za> Robin Schreiber added the comment: Fixed _dealloc methods. Also: Init now returns the previously initialized module if available. ---------- Added file: http://bugs.python.org/file26803/_datetimemodule_pep3121-384_v1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 20:14:34 2012 From: report at bugs.python.org (Robin Schreiber) Date: Tue, 14 Aug 2012 18:14:34 +0000 Subject: [issue15650] PEP 3121, 384 refactoring applied to dbm module Message-ID: <1344968074.48.0.47544287235.issue15650@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the dbm module! ---------- components: Extension Modules files: _dbmmodule_pep3121-384_v0.patch keywords: patch messages: 168216 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121, 384 refactoring applied to dbm module versions: Python 3.4 Added file: http://bugs.python.org/file26804/_dbmmodule_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 20:25:21 2012 From: report at bugs.python.org (Robin Schreiber) Date: Tue, 14 Aug 2012 18:25:21 +0000 Subject: [issue15651] PEP 3121, 384 refactoring applied to elementtree module Message-ID: <1344968721.44.0.689766020196.issue15651@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the elementtree module! ---------- components: Extension Modules files: _elementtree_pep3121-384_v0.patch keywords: patch messages: 168217 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121, 384 refactoring applied to elementtree module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26805/_elementtree_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 20:28:52 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Tue, 14 Aug 2012 18:28:52 +0000 Subject: [issue15390] PEP 3121, 384 refactoring applied to datetime module In-Reply-To: <1342647232.82.0.0763290244077.issue15390@psf.upfronthosting.co.za> Message-ID: <1344968932.32.0.671295833416.issue15390@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Add Alexander Belopolsky to nosy list as maintainer of datetime module. ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 20:31:40 2012 From: report at bugs.python.org (Robin Schreiber) Date: Tue, 14 Aug 2012 18:31:40 +0000 Subject: [issue15652] PEP 3121, 384 refactoring applied to gdbm module Message-ID: <1344969100.54.0.643991722265.issue15652@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the gdbm module! ---------- components: Extension Modules files: _gdbm_pep3121-384_v0.patch keywords: patch messages: 168219 nosy: Robin.Schreiber, anthony_baxter priority: normal severity: normal status: open title: PEP 3121, 384 refactoring applied to gdbm module versions: Python 3.4 Added file: http://bugs.python.org/file26806/_gdbm_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 20:33:34 2012 From: report at bugs.python.org (Robin Schreiber) Date: Tue, 14 Aug 2012 18:33:34 +0000 Subject: [issue15651] PEP 3121, 384 refactoring applied to elementtree module In-Reply-To: <1344968721.44.0.689766020196.issue15651@psf.upfronthosting.co.za> Message-ID: <1344969214.66.0.730120708528.issue15651@psf.upfronthosting.co.za> Changes by Robin Schreiber : ---------- nosy: +effbot _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 20:42:13 2012 From: report at bugs.python.org (Robin Schreiber) Date: Tue, 14 Aug 2012 18:42:13 +0000 Subject: [issue15653] PEP 3121, 384 refactoring applied to hashopenssl module Message-ID: <1344969733.85.0.308586175776.issue15653@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the hashopenssl module! ---------- components: Extension Modules files: _hashopenssl_pep3121-384_v0.patch keywords: patch messages: 168220 nosy: Robin.Schreiber, gstein priority: normal severity: normal status: open title: PEP 3121, 384 refactoring applied to hashopenssl module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26807/_hashopenssl_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 20:47:38 2012 From: report at bugs.python.org (Robin Schreiber) Date: Tue, 14 Aug 2012 18:47:38 +0000 Subject: [issue15654] PEP 384 Refactoring applied to bz2 module Message-ID: <1344970058.86.0.178955604138.issue15654@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP384 have now been applied to the bz2 module! ---------- components: Extension Modules files: _bz2_pep384_v0.patch keywords: patch messages: 168221 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 384 Refactoring applied to bz2 module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26808/_bz2_pep384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 20:53:18 2012 From: report at bugs.python.org (Robin Schreiber) Date: Tue, 14 Aug 2012 18:53:18 +0000 Subject: [issue15655] PEP 384 Refactoring applied to json module Message-ID: <1344970398.16.0.223655068768.issue15655@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the json module! ---------- components: Extension Modules files: _json_pep384_v0.patch keywords: patch messages: 168222 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 384 Refactoring applied to json module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26809/_json_pep384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 20:57:45 2012 From: report at bugs.python.org (Sandro Tosi) Date: Tue, 14 Aug 2012 18:57:45 +0000 Subject: [issue15656] "Extending Python with C" page needs update for 3.x Message-ID: <1344970665.85.0.951420699824.issue15656@psf.upfronthosting.co.za> New submission from Sandro Tosi: Hello, this has been reported at http://mail.python.org/pipermail/docs/2012-July/009223.html but since I have no experience to judge if it's correct or not, i'll just report it: >>> I've recenty started to try using C code in python using the wonderful python API, although i have to say the learning curve was non neglectable :P I've spotted what I believe to be a small mistake in the documentation from this page: http://docs.python.org/release/3.2/extending/extending.html In paragraph 1.8 (http://docs.python.org/release/3.2/extending/extending.html#keyword-parameters-for-extension-functions), the code example given contains an error, which is actually obsolete code from python 2.7: void initkeywdarg(void) { /* Create the module and add the functions */ Py_InitModule("keywdarg", keywdarg_methods); } This doesn't work in Python3.2. It's supposed to be static struct PyModuleDef keywdargmodule = { PyModuleDef_HEAD_INIT, "keywdarg", /* name of module */ keywdarg_doc, /* module documentation, may be NULL */ -1, /* size of per-interpreter state of the module, or -1 if the module keeps state in global variables. */ keywdarg_methods }; PyMODINIT_FUNC PyInit_keywdarg(void) { return PyModule_Create(&keywdargmodule); } As explained above (and confirmed by experience). <<< ---------- assignee: docs at python components: Documentation messages: 168223 nosy: docs at python, sandro.tosi priority: normal severity: normal stage: patch review status: open title: "Extending Python with C" page needs update for 3.x versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 20:59:27 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 14 Aug 2012 18:59:27 +0000 Subject: [issue15653] PEP 3121, 384 refactoring applied to hashopenssl module In-Reply-To: <1344969733.85.0.308586175776.issue15653@psf.upfronthosting.co.za> Message-ID: <1344970767.55.0.312661832028.issue15653@psf.upfronthosting.co.za> Antoine Pitrou added the comment: + m = PyState_FindModule(&_hashlibmodule); + if(!m){ + m = PyModule_Create(&_hashlibmodule); + if (m == NULL) + return NULL; + } else { + Py_INCREF(m); + return m; + } Why is this dance needed? + if((void *)type->tp_dealloc == (void *)EVP_dealloc) { + Py_DECREF(type); + } Why? ---------- nosy: +gregory.p.smith, loewis, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 20:59:41 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 14 Aug 2012 18:59:41 +0000 Subject: [issue15653] PEP 3121, 384 refactoring applied to hashopenssl module In-Reply-To: <1344969733.85.0.308586175776.issue15653@psf.upfronthosting.co.za> Message-ID: <1344970781.1.0.348502181553.issue15653@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 21:01:22 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 14 Aug 2012 19:01:22 +0000 Subject: [issue15653] PEP 3121, 384 refactoring applied to hashopenssl module In-Reply-To: <1344969733.85.0.308586175776.issue15653@psf.upfronthosting.co.za> Message-ID: <1344970882.33.0.607481356279.issue15653@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Something else: +#define _hashlibstate(o) ((_hashlibstate *)PyModule_GetState(o)) It is really bad style to #define a symbol that shadows another symbol. Since it's a #define, I would expect to be named something like STATE(o). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 21:02:46 2012 From: report at bugs.python.org (Sandro Tosi) Date: Tue, 14 Aug 2012 19:02:46 +0000 Subject: [issue15657] Error in Python 3 docs for PyMethodDef Message-ID: <1344970966.7.0.115664419243.issue15657@psf.upfronthosting.co.za> New submission from Sandro Tosi: Hello, it has been reported at http://mail.python.org/pipermail/docs/2012-April/008215.html but given it raises some question whether it's a bug in the doc or in the code, i'd rather report the issue here and hear what other think: >>> In the Python 3.2.2 documentation (and earlier Python 3 versions), in the Python/C API Reference Manual, chapter Object Implementation Support, the documentation for PyMethodDef says: The ml_flags field is a bitfield which can include the following flags. The individual flags indicate either a calling convention or a binding convention. Of the calling convention flags, only METH_VARARGS and METH_KEYWORDS can be combined (but note that METH_KEYWORDS alone is equivalent to METH_VARARGS | METH_KEYWORDS). The bit in the parenthetical is incorrect. If you take a look at PyCFunction_Call in Objects/methodobject.c, you will find a switch for METH_VARARGS | METH_KEYWORDS, but no switch for METH_KEYWORDS. Hence, using METH_KEYWORDS will land you with a SystemError that complains about METH_OLDARGS. This is either a bug in the documentation, or a bug in Python. In this case, since the code has persisted through three major revisions of Python 3, I suggest that the bug _is_ in the documentation (whether it should be or not), since changing the code for this at this late date means a programmer has to use METH_VARARGS | METH_KEYWORDS anyway for compatibility. It may be work pointing out specifically in the documentation that just using METH_KEYWORDS will not work. <<< ---------- assignee: docs at python components: Documentation messages: 168226 nosy: docs at python, sandro.tosi priority: normal severity: normal stage: patch review status: open title: Error in Python 3 docs for PyMethodDef versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 21:03:23 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 14 Aug 2012 19:03:23 +0000 Subject: [issue15655] PEP 384 Refactoring applied to json module In-Reply-To: <1344970398.16.0.223655068768.issue15655@psf.upfronthosting.co.za> Message-ID: <1344971003.63.0.0507585137711.issue15655@psf.upfronthosting.co.za> Antoine Pitrou added the comment: + // in case init is called multiple times within one interpreter, + // we do not have to repeat all of the initialization First, you shouldn't use C++-style comments ("//"). Second, I find this comment a bit weird. Even if init is called a second time, surely clear would have been called in-between, and therefore the module state has to be initialized again? Review comments from issue15653 also apply here. ---------- nosy: +loewis, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 21:08:58 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 14 Aug 2012 19:08:58 +0000 Subject: [issue14649] doctest.DocTestSuite error misleading when module has no docstrings In-Reply-To: <1335192861.9.0.305748973415.issue14649@psf.upfronthosting.co.za> Message-ID: <1344971338.4.0.339003436707.issue14649@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > Every doctest is docstring from tested module, but not every docstring is a valid doctest. Actually, I'm not sure even this is correct. doctest will form a unittest *TestSuite* from a module if it has docstrings, but it will not necessarily create a test for each docstring. You can see this by running code like the following on a target module that contains an empty docstring: suite = doctest.DocTestSuite('doctest_target') print(repr(suite)) print(suite.countTestCases()) which outputs-- 0 So while "tests" (in the doctest code) evaluates to True (because it is a TestSuite instance), it still "has no tests." If it wants to check for tests, it should probably be evaluating tests.countTestCases(), as David suggested. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 21:09:58 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 14 Aug 2012 19:09:58 +0000 Subject: [issue15390] PEP 3121, 384 refactoring applied to datetime module In-Reply-To: <1342647232.82.0.0763290244077.issue15390@psf.upfronthosting.co.za> Message-ID: <1344971398.7.0.613927688045.issue15390@psf.upfronthosting.co.za> Antoine Pitrou added the comment: + Py_CLEAR(_datetimemodulestate(m)->PyDateTime_DateTimeType); + Py_CLEAR(_datetimemodulestate(m)->PyDateTime_DeltaType); + Py_CLEAR(_datetimemodulestate(m)->PyDateTime_TimeType); + Py_CLEAR(_datetimemodulestate(m)->PyDateTime_TimeZoneType); + Py_CLEAR(_datetimemodulestate(m)->PyDateTime_DateType); + Py_CLEAR(_datetimemodulestate(m)->PyDateTime_TZInfoType); Style nit: I would really store the module state pointer in a variable here, instead of repeating _datetimemodulestate(m) every line. (same in other places, such as the module init function) +PyObject* _Get_State(struct PyModuleDef*); I'm not sure why a module should define such generic a function, and especially not without a "Py" prefix. Besides, review comments from issue15653 apply here. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 21:11:33 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 14 Aug 2012 19:11:33 +0000 Subject: [issue15654] PEP 384 Refactoring applied to bz2 module In-Reply-To: <1344970058.86.0.178955604138.issue15654@psf.upfronthosting.co.za> Message-ID: <1344971493.26.0.40635802556.issue15654@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Same review comments as in issue15653. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 21:12:39 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 14 Aug 2012 19:12:39 +0000 Subject: [issue15651] PEP 3121, 384 refactoring applied to elementtree module In-Reply-To: <1344968721.44.0.689766020196.issue15651@psf.upfronthosting.co.za> Message-ID: <1344971559.65.0.726536321101.issue15651@psf.upfronthosting.co.za> Antoine Pitrou added the comment: See issue15390 review comments :) ---------- nosy: +eli.bendersky, pitrou stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 21:12:56 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 14 Aug 2012 19:12:56 +0000 Subject: [issue14649] doctest.DocTestSuite error misleading when module has no docstrings In-Reply-To: <1335192861.9.0.305748973415.issue14649@psf.upfronthosting.co.za> Message-ID: <1344971576.91.0.494710545775.issue14649@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > I suspect the intent was to raise an error if there were no *tests*, not if there were no docstrings. That, or the implementor thought that if no docstrings were found, then that might indicate something went wrong with the parsing. For background purposes, here is the justification in the code comment: elif not tests: # Why do we want to do this? Because it reveals a bug that might # otherwise be hidden. raise ValueError(module, "has no tests") > I have a couple of test runners in various projects that run doctest on *all* modules Same here, which is how I noticed the issue. > So if anything I think this exception should be dropped. If the report is that no tests are run, that should be enough of an indication that something is wrong I would be in favor of this. The unittest module's test discovery, for example, does not raise an exception if it finds no tests (to my knowledge). In what versions would we be able to make this change? I could prepare another patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 21:27:34 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 14 Aug 2012 19:27:34 +0000 Subject: [issue14649] doctest.DocTestSuite error misleading when module has no docstrings In-Reply-To: <1335192861.9.0.305748973415.issue14649@psf.upfronthosting.co.za> Message-ID: <1344972454.79.0.143163716929.issue14649@psf.upfronthosting.co.za> R. David Murray added the comment: That's a good question. Perhaps you could argue for it as a bug fix since it doesn't seem to be documented either way...except for the 'exclude_empty' argument of testmod. If testmod throws an error when there are no docstrings instead of returning a 0 test count or (if exclude_empty is true) skipping the module, then I think we can treat it as a bug and fix it in all active versions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 21:42:18 2012 From: report at bugs.python.org (Michael Welsh Duggan) Date: Tue, 14 Aug 2012 19:42:18 +0000 Subject: [issue15657] Error in Python 3 docs for PyMethodDef In-Reply-To: <1344970966.7.0.115664419243.issue15657@psf.upfronthosting.co.za> Message-ID: <1344973338.71.0.280956089058.issue15657@psf.upfronthosting.co.za> Changes by Michael Welsh Duggan : ---------- nosy: +md5i _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 21:43:58 2012 From: report at bugs.python.org (Robin Schreiber) Date: Tue, 14 Aug 2012 19:43:58 +0000 Subject: [issue15653] PEP 3121, 384 refactoring applied to hashopenssl module In-Reply-To: <1344969733.85.0.308586175776.issue15653@psf.upfronthosting.co.za> Message-ID: <1344973438.7.0.0832940303654.issue15653@psf.upfronthosting.co.za> Robin Schreiber added the comment: Regarding the macro definition, I would be fine with changing it to _hashlib_state. The dance you have found inside the Init, makes shure that the very same module is returned if Init is called twice or multiple times, before the Module is unloaded. A month back, when I created this patch, I had statements such as test.import.import_fresh_module(...) call the Init-method multiple times, before a module was unloaded. This was apparently a bug, as I can no longer reproduce this behavior, but at that time I thought it was the expected behavior :-) The last code snipped verifies, that we only dereference the type if the dealloc function is not being called from inside the subtype_dealloc function. This is necessary because the subtype_dealloc function itself contains a decref of the respective type object. Without this check, we would then end up decrefing the type too many times. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 21:49:28 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 14 Aug 2012 19:49:28 +0000 Subject: [issue15653] PEP 3121, 384 refactoring applied to hashopenssl module In-Reply-To: <1344973438.7.0.0832940303654.issue15653@psf.upfronthosting.co.za> Message-ID: <1344973551.3329.2.camel@localhost.localdomain> Antoine Pitrou added the comment: > The last code snipped verifies, that we only dereference the type if > the dealloc function is not being called from inside the > subtype_dealloc function. This is necessary because the > subtype_dealloc function itself contains a decref of the respective > type object. Without this check, we would then end up decrefing the > type too many times. I still don't understand why it is required. You shouldn't have to decref the type at all. Otherwise, it is a bug somewhere in Python (typeobject.c perhaps). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 21:50:27 2012 From: report at bugs.python.org (Robin Schreiber) Date: Tue, 14 Aug 2012 19:50:27 +0000 Subject: [issue15655] PEP 384 Refactoring applied to json module In-Reply-To: <1344970398.16.0.223655068768.issue15655@psf.upfronthosting.co.za> Message-ID: <1344973827.13.0.627919200165.issue15655@psf.upfronthosting.co.za> Robin Schreiber added the comment: Hey Antoine, This comment describes exactly what I intended with the "dance" in issue15653. For example the json testsuite issued multiple calls to the init function before unloading and consequently clearing the module. However it seems as if the behavior this code dealt with, has been a bug inside the import lib. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 21:53:44 2012 From: report at bugs.python.org (Nadeem Vawda) Date: Tue, 14 Aug 2012 19:53:44 +0000 Subject: [issue15654] PEP 384 Refactoring applied to bz2 module In-Reply-To: <1344970058.86.0.178955604138.issue15654@psf.upfronthosting.co.za> Message-ID: <1344974024.24.0.248917938714.issue15654@psf.upfronthosting.co.za> Changes by Nadeem Vawda : ---------- nosy: +nadeem.vawda _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 21:55:54 2012 From: report at bugs.python.org (Robin Schreiber) Date: Tue, 14 Aug 2012 19:55:54 +0000 Subject: [issue15653] PEP 3121, 384 refactoring applied to hashopenssl module In-Reply-To: <1344969733.85.0.308586175776.issue15653@psf.upfronthosting.co.za> Message-ID: <1344974154.8.0.918172039071.issue15653@psf.upfronthosting.co.za> Robin Schreiber added the comment: Well, as I have changed the static type to a HeapType (as I am now using the stable ABI from PEP 384 for this type), we have to start perfoming proper reference counting with this object. This includes increfing the type in case a new object of that type is created, and decrefing if such an object is being deallocated. As of now, I do not know of HeapTypes being excluded from refcounting. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 21:57:46 2012 From: report at bugs.python.org (Robin Schreiber) Date: Tue, 14 Aug 2012 19:57:46 +0000 Subject: [issue15655] PEP 384 Refactoring applied to json module In-Reply-To: <1344970398.16.0.223655068768.issue15655@psf.upfronthosting.co.za> Message-ID: <1344974266.58.0.560634408619.issue15655@psf.upfronthosting.co.za> Robin Schreiber added the comment: Incidentally, I am deeply sorry for the C++-Style comments. I thought those would be detected by the patchcheck.py. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 22:04:19 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 14 Aug 2012 20:04:19 +0000 Subject: [issue15653] PEP 3121, 384 refactoring applied to hashopenssl module In-Reply-To: <1344969733.85.0.308586175776.issue15653@psf.upfronthosting.co.za> Message-ID: <1344974659.97.0.240375481858.issue15653@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Le mardi 14 ao?t 2012 ? 19:55 +0000, Robin Schreiber a ?crit : > As of now, I do not know of HeapTypes being excluded from refcounting. No, but see http://bugs.python.org/issue15142 It's not obvious to me that the type should be explicitly decref'ed from the tp_dealloc function. This will make things more complicated for people willing to migrate their extensions to the stable ABI. Also, all this is not documented at all :-( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 22:16:14 2012 From: report at bugs.python.org (Robin Schreiber) Date: Tue, 14 Aug 2012 20:16:14 +0000 Subject: [issue15653] PEP 3121, 384 refactoring applied to hashopenssl module In-Reply-To: <1344969733.85.0.308586175776.issue15653@psf.upfronthosting.co.za> Message-ID: <1344975374.03.0.631649909071.issue15653@psf.upfronthosting.co.za> Robin Schreiber added the comment: As subtype_dealloc decref'ed the HeapType I thought the dealloc method was the most appropriate place to decrement the refcount of the type. However you still agree that these types need to be recounted properly, don't you? In that case, where would you place the decref of the type? I have talked with Martin v. L?wis about this issue, and I think he was quite comfortable with placing the decref inside the dealloc method. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 22:21:35 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 14 Aug 2012 20:21:35 +0000 Subject: [issue15653] PEP 3121, 384 refactoring applied to hashopenssl module In-Reply-To: <1344975374.03.0.631649909071.issue15653@psf.upfronthosting.co.za> Message-ID: <1344975523.3329.5.camel@localhost.localdomain> Antoine Pitrou added the comment: Le mardi 14 ao?t 2012 ? 20:16 +0000, Robin Schreiber a ?crit : > However you still agree that these types need to be recounted > properly, don't you? Yes, of course. > In that case, where would you place the decref of the type? That's a good question. Perhaps the DECREF mechanism / typeobject.c should do it. Or perhaps PyType_FromSpec should place a stub which would call the actual dealloc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 22:57:33 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Aug 2012 20:57:33 +0000 Subject: [issue15490] Correct __sizeof__ support for StringIO In-Reply-To: <1343591617.54.0.289047671129.issue15490@psf.upfronthosting.co.za> Message-ID: <1344977853.21.0.554790119099.issue15490@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Patch updated. Now private pyobjects (readnl, accu) counted. Note all three patches rather different. ---------- Added file: http://bugs.python.org/file26810/stringio_sizeof-3.3_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 22:58:12 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Aug 2012 20:58:12 +0000 Subject: [issue15490] Correct __sizeof__ support for StringIO In-Reply-To: <1343591617.54.0.289047671129.issue15490@psf.upfronthosting.co.za> Message-ID: <1344977892.14.0.000318825539333.issue15490@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file26811/stringio_sizeof-3.2_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 22:59:10 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Aug 2012 20:59:10 +0000 Subject: [issue15490] Correct __sizeof__ support for StringIO In-Reply-To: <1343591617.54.0.289047671129.issue15490@psf.upfronthosting.co.za> Message-ID: <1344977950.69.0.598417095022.issue15490@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file26812/stringio_sizeof-2.7_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 14 23:45:23 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Aug 2012 21:45:23 +0000 Subject: [issue15604] PyObject_IsTrue failure checks In-Reply-To: <1344525855.66.0.08938802791.issue15604@psf.upfronthosting.co.za> Message-ID: <201208150044.47845.storchaka@gmail.com> Serhiy Storchaka added the comment: Patches updated to reflect Antoine's comments. ---------- Added file: http://bugs.python.org/file26813/istrue_check-3.3_2.patch Added file: http://bugs.python.org/file26814/istrue_check-3.2_2.patch Added file: http://bugs.python.org/file26815/istrue_check-2.7_2.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r e2e85ed7f8ba Modules/_csv.c --- a/Modules/_csv.c Tue Aug 14 18:42:54 2012 +0300 +++ b/Modules/_csv.c Wed Aug 15 00:36:48 2012 +0300 @@ -196,8 +196,12 @@ { if (src == NULL) *target = dflt; - else - *target = PyObject_IsTrue(src); + else { + int b = PyObject_IsTrue(src); + if (b < 0) + return -1; + *target = b; + } return 0; } diff -r e2e85ed7f8ba Modules/_io/textio.c --- a/Modules/_io/textio.c Tue Aug 14 18:42:54 2012 +0300 +++ b/Modules/_io/textio.c Wed Aug 15 00:36:48 2012 +0300 @@ -1056,8 +1056,11 @@ res = _PyObject_CallMethodId(buffer, &PyId_seekable, NULL); if (res == NULL) goto error; - self->seekable = self->telling = PyObject_IsTrue(res); + r = PyObject_IsTrue(res); Py_DECREF(res); + if (r < 0) + goto error; + self->seekable = self->telling = r; self->has_read1 = _PyObject_HasAttrId(buffer, &PyId_read1); diff -r e2e85ed7f8ba Modules/_posixsubprocess.c --- a/Modules/_posixsubprocess.c Tue Aug 14 18:42:54 2012 +0300 +++ b/Modules/_posixsubprocess.c Wed Aug 15 00:36:48 2012 +0300 @@ -503,7 +503,7 @@ subprocess_fork_exec(PyObject* self, PyObject *args) { PyObject *gc_module = NULL; - PyObject *executable_list, *py_close_fds, *py_fds_to_keep; + PyObject *executable_list, *py_fds_to_keep; PyObject *env_list, *preexec_fn; PyObject *process_args, *converted_args = NULL, *fast_args = NULL; PyObject *preexec_fn_args_tuple = NULL; @@ -518,15 +518,14 @@ Py_ssize_t arg_num; if (!PyArg_ParseTuple( - args, "OOOOOOiiiiiiiiiiO:fork_exec", - &process_args, &executable_list, &py_close_fds, &py_fds_to_keep, + args, "OOpOOOiiiiiiiiiiO:fork_exec", + &process_args, &executable_list, &close_fds, &py_fds_to_keep, &cwd_obj, &env_list, &p2cread, &p2cwrite, &c2pread, &c2pwrite, &errread, &errwrite, &errpipe_read, &errpipe_write, &restore_signals, &call_setsid, &preexec_fn)) return NULL; - close_fds = PyObject_IsTrue(py_close_fds); if (close_fds && errpipe_write < 3) { /* precondition */ PyErr_SetString(PyExc_ValueError, "errpipe_write must be >= 3"); return NULL; diff -r e2e85ed7f8ba Modules/_ssl.c --- a/Modules/_ssl.c Tue Aug 14 18:42:54 2012 +0300 +++ b/Modules/_ssl.c Wed Aug 15 00:36:48 2012 +0300 @@ -1037,15 +1037,15 @@ PyObject *retval = NULL; int len; int verification; - PyObject *binary_mode = Py_None; + int binary_mode = 0; - if (!PyArg_ParseTuple(args, "|O:peer_certificate", &binary_mode)) + if (!PyArg_ParseTuple(args, "|p:peer_certificate", &binary_mode)) return NULL; if (!self->peer_cert) Py_RETURN_NONE; - if (PyObject_IsTrue(binary_mode)) { + if (binary_mode) { /* return cert in DER-encoded format */ unsigned char *bytes_buf = NULL; diff -r e2e85ed7f8ba Modules/itertoolsmodule.c --- a/Modules/itertoolsmodule.c Tue Aug 14 18:42:54 2012 +0300 +++ b/Modules/itertoolsmodule.c Wed Aug 15 00:36:48 2012 +0300 @@ -1105,11 +1105,13 @@ } ok = PyObject_IsTrue(good); Py_DECREF(good); - if (!ok) { + if (ok == 0) { lz->start = 1; return item; } Py_DECREF(item); + if (ok < 0) + return NULL; } } @@ -1124,7 +1126,7 @@ dropwhile_setstate(dropwhileobject *lz, PyObject *state) { int start = PyObject_IsTrue(state); - if (start == -1) + if (start < 0) return NULL; lz->start = start; Py_RETURN_NONE; @@ -1270,10 +1272,11 @@ } ok = PyObject_IsTrue(good); Py_DECREF(good); - if (ok) + if (ok == 1) return item; Py_DECREF(item); - lz->stop = 1; + if (ok == 0) + lz->stop = 1; return NULL; } @@ -1288,7 +1291,7 @@ takewhile_reduce_setstate(takewhileobject *lz, PyObject *state) { int stop = PyObject_IsTrue(state); - if (stop == -1) + if (stop < 0) return NULL; lz->stop = stop; Py_RETURN_NONE; @@ -3536,7 +3539,7 @@ if (ok == 1) return datum; Py_DECREF(datum); - if (ok == -1) + if (ok < 0) return NULL; } } @@ -3692,9 +3695,11 @@ ok = PyObject_IsTrue(good); Py_DECREF(good); } - if (!ok) + if (ok == 0) return item; Py_DECREF(item); + if (ok < 0) + return NULL; } } diff -r e2e85ed7f8ba Modules/parsermodule.c --- a/Modules/parsermodule.c Tue Aug 14 18:42:54 2012 +0300 +++ b/Modules/parsermodule.c Wed Aug 15 00:36:48 2012 +0300 @@ -382,36 +382,28 @@ static PyObject* parser_st2tuple(PyST_Object *self, PyObject *args, PyObject *kw) { - PyObject *line_option = 0; - PyObject *col_option = 0; + int line_info = 0; + int col_info = 0; PyObject *res = 0; int ok; static char *keywords[] = {"st", "line_info", "col_info", NULL}; if (self == NULL || PyModule_Check(self)) { - ok = PyArg_ParseTupleAndKeywords(args, kw, "O!|OO:st2tuple", keywords, - &PyST_Type, &self, &line_option, - &col_option); + ok = PyArg_ParseTupleAndKeywords(args, kw, "O!|pp:st2tuple", keywords, + &PyST_Type, &self, &line_info, + &col_info); } else - ok = PyArg_ParseTupleAndKeywords(args, kw, "|OO:totuple", &keywords[1], - &line_option, &col_option); + ok = PyArg_ParseTupleAndKeywords(args, kw, "|pp:totuple", &keywords[1], + &line_info, &col_info); if (ok != 0) { - int lineno = 0; - int col_offset = 0; - if (line_option != NULL) { - lineno = (PyObject_IsTrue(line_option) != 0) ? 1 : 0; - } - if (col_option != NULL) { - col_offset = (PyObject_IsTrue(col_option) != 0) ? 1 : 0; - } /* * Convert ST into a tuple representation. Use Guido's function, * since it's known to work already. */ res = node2tuple(((PyST_Object*)self)->st_node, - PyTuple_New, PyTuple_SetItem, lineno, col_offset); + PyTuple_New, PyTuple_SetItem, line_info, col_info); } return (res); } @@ -426,35 +418,27 @@ static PyObject* parser_st2list(PyST_Object *self, PyObject *args, PyObject *kw) { - PyObject *line_option = 0; - PyObject *col_option = 0; + int line_info = 0; + int col_info = 0; PyObject *res = 0; int ok; static char *keywords[] = {"st", "line_info", "col_info", NULL}; if (self == NULL || PyModule_Check(self)) - ok = PyArg_ParseTupleAndKeywords(args, kw, "O!|OO:st2list", keywords, - &PyST_Type, &self, &line_option, - &col_option); + ok = PyArg_ParseTupleAndKeywords(args, kw, "O!|pp:st2list", keywords, + &PyST_Type, &self, &line_info, + &col_info); else - ok = PyArg_ParseTupleAndKeywords(args, kw, "|OO:tolist", &keywords[1], - &line_option, &col_option); + ok = PyArg_ParseTupleAndKeywords(args, kw, "|pp:tolist", &keywords[1], + &line_info, &col_info); if (ok) { - int lineno = 0; - int col_offset = 0; - if (line_option != 0) { - lineno = PyObject_IsTrue(line_option) ? 1 : 0; - } - if (col_option != NULL) { - col_offset = (PyObject_IsTrue(col_option) != 0) ? 1 : 0; - } /* * Convert ST into a tuple representation. Use Guido's function, * since it's known to work already. */ res = node2tuple(self->st_node, - PyList_New, PyList_SetItem, lineno, col_offset); + PyList_New, PyList_SetItem, line_info, col_info); } return (res); } diff -r e2e85ed7f8ba Modules/pyexpat.c --- a/Modules/pyexpat.c Tue Aug 14 18:42:54 2012 +0300 +++ b/Modules/pyexpat.c Wed Aug 15 00:36:48 2012 +0300 @@ -1033,14 +1033,11 @@ static PyObject * xmlparse_UseForeignDTD(xmlparseobject *self, PyObject *args) { - PyObject *flagobj = NULL; - XML_Bool flag = XML_TRUE; + int flag = 1; enum XML_Error rc; - if (!PyArg_UnpackTuple(args, "UseForeignDTD", 0, 1, &flagobj)) + if (!PyArg_ParseTuple(args, "p:UseForeignDTD", &flag)) return NULL; - if (flagobj != NULL) - flag = PyObject_IsTrue(flagobj) ? XML_TRUE : XML_FALSE; - rc = XML_UseForeignDTD(self->itself, flag); + rc = XML_UseForeignDTD(self->itself, flag ? XML_TRUE : XML_FALSE); if (rc != XML_ERROR_NONE) { return set_error(self, rc); } @@ -1405,7 +1402,10 @@ } assert(PyUnicode_Check(name)); if (PyUnicode_CompareWithASCIIString(name, "buffer_text") == 0) { - if (PyObject_IsTrue(v)) { + int b = PyObject_IsTrue(v); + if (b < 0) + return -1; + if (b) { if (self->buffer == NULL) { self->buffer = malloc(self->buffer_size); if (self->buffer == NULL) { @@ -1424,25 +1424,25 @@ return 0; } if (PyUnicode_CompareWithASCIIString(name, "namespace_prefixes") == 0) { - if (PyObject_IsTrue(v)) - self->ns_prefixes = 1; - else - self->ns_prefixes = 0; + int b = PyObject_IsTrue(v); + if (b < 0) + return -1; + self->ns_prefixes = b; XML_SetReturnNSTriplet(self->itself, self->ns_prefixes); return 0; } if (PyUnicode_CompareWithASCIIString(name, "ordered_attributes") == 0) { - if (PyObject_IsTrue(v)) - self->ordered_attributes = 1; - else - self->ordered_attributes = 0; + int b = PyObject_IsTrue(v); + if (b < 0) + return -1; + self->ordered_attributes = b; return 0; } if (PyUnicode_CompareWithASCIIString(name, "specified_attributes") == 0) { - if (PyObject_IsTrue(v)) - self->specified_attributes = 1; - else - self->specified_attributes = 0; + int b = PyObject_IsTrue(v); + if (b < 0) + return -1; + self->specified_attributes = b; return 0; } diff -r e2e85ed7f8ba Objects/typeobject.c --- a/Objects/typeobject.c Tue Aug 14 18:42:54 2012 +0300 +++ b/Objects/typeobject.c Wed Aug 15 00:36:48 2012 +0300 @@ -396,12 +396,16 @@ } if (res == 0) { PyType_Modified(type); - if (value && PyObject_IsTrue(value)) { + int abstract = 0; + if (value) { + abstract = PyObject_IsTrue(value); + if (abstract < 0) + return -1; + } + if (abstract) type->tp_flags |= Py_TPFLAGS_IS_ABSTRACT; - } - else { + else type->tp_flags &= ~Py_TPFLAGS_IS_ABSTRACT; - } } return res; } diff -r e2e85ed7f8ba Python/bltinmodule.c --- a/Python/bltinmodule.c Tue Aug 14 18:42:54 2012 +0300 +++ b/Python/bltinmodule.c Wed Aug 15 00:36:48 2012 +0300 @@ -429,9 +429,11 @@ ok = PyObject_IsTrue(good); Py_DECREF(good); } - if (ok) + if (ok > 0) return item; Py_DECREF(item); + if (ok < 0) + return NULL; } } -------------- next part -------------- diff -r 84899daa4309 Modules/_csv.c --- a/Modules/_csv.c Tue Aug 14 18:41:40 2012 +0300 +++ b/Modules/_csv.c Wed Aug 15 00:36:56 2012 +0300 @@ -166,8 +166,12 @@ { if (src == NULL) *target = dflt; - else - *target = PyObject_IsTrue(src); + else { + int b = PyObject_IsTrue(src); + if (b < 0) + return -1; + *target = b; + } return 0; } diff -r 84899daa4309 Modules/_io/textio.c --- a/Modules/_io/textio.c Tue Aug 14 18:41:40 2012 +0300 +++ b/Modules/_io/textio.c Wed Aug 15 00:36:56 2012 +0300 @@ -1046,8 +1046,11 @@ res = PyObject_CallMethod(buffer, "seekable", NULL); if (res == NULL) goto error; - self->seekable = self->telling = PyObject_IsTrue(res); + r = PyObject_IsTrue(res); Py_DECREF(res); + if (r < 0) + goto error; + self->seekable = self->telling = r; self->has_read1 = PyObject_HasAttrString(buffer, "read1"); diff -r 84899daa4309 Modules/_posixsubprocess.c --- a/Modules/_posixsubprocess.c Tue Aug 14 18:41:40 2012 +0300 +++ b/Modules/_posixsubprocess.c Wed Aug 15 00:36:56 2012 +0300 @@ -525,6 +525,8 @@ return NULL; close_fds = PyObject_IsTrue(py_close_fds); + if (close_fds < 0) + return NULL; if (close_fds && errpipe_write < 3) { /* precondition */ PyErr_SetString(PyExc_ValueError, "errpipe_write must be >= 3"); return NULL; diff -r 84899daa4309 Modules/_ssl.c --- a/Modules/_ssl.c Tue Aug 14 18:41:40 2012 +0300 +++ b/Modules/_ssl.c Wed Aug 15 00:36:56 2012 +0300 @@ -883,6 +883,7 @@ int len; int verification; PyObject *binary_mode = Py_None; + int b; if (!PyArg_ParseTuple(args, "|O:peer_certificate", &binary_mode)) return NULL; @@ -890,7 +891,10 @@ if (!self->peer_cert) Py_RETURN_NONE; - if (PyObject_IsTrue(binary_mode)) { + b = PyObject_IsTrue(binary_mode); + if (b < 0) + return NULL; + if (b) { /* return cert in DER-encoded format */ unsigned char *bytes_buf = NULL; diff -r 84899daa4309 Modules/itertoolsmodule.c --- a/Modules/itertoolsmodule.c Tue Aug 14 18:41:40 2012 +0300 +++ b/Modules/itertoolsmodule.c Wed Aug 15 00:36:56 2012 +0300 @@ -903,11 +903,13 @@ } ok = PyObject_IsTrue(good); Py_DECREF(good); - if (!ok) { + if (ok == 0) { lz->start = 1; return item; } Py_DECREF(item); + if (ok < 0) + return NULL; } } @@ -1043,10 +1045,11 @@ } ok = PyObject_IsTrue(good); Py_DECREF(good); - if (ok) + if (ok > 0) return item; Py_DECREF(item); - lz->stop = 1; + if (ok == 0) + lz->stop = 1; return NULL; } @@ -2959,9 +2962,11 @@ ok = PyObject_IsTrue(good); Py_DECREF(good); } - if (!ok) + if (ok == 0) return item; Py_DECREF(item); + if (ok < 0) + return NULL; } } diff -r 84899daa4309 Modules/parsermodule.c --- a/Modules/parsermodule.c Tue Aug 14 18:41:40 2012 +0300 +++ b/Modules/parsermodule.c Wed Aug 15 00:36:56 2012 +0300 @@ -401,10 +401,14 @@ int lineno = 0; int col_offset = 0; if (line_option != NULL) { - lineno = (PyObject_IsTrue(line_option) != 0) ? 1 : 0; + lineno = PyObject_IsTrue(line_option); + if (lineno < 0) + return NULL; } if (col_option != NULL) { - col_offset = (PyObject_IsTrue(col_option) != 0) ? 1 : 0; + col_offset = PyObject_IsTrue(col_option); + if (col_offset < 0) + return NULL; } /* * Convert ST into a tuple representation. Use Guido's function, @@ -444,10 +448,14 @@ int lineno = 0; int col_offset = 0; if (line_option != 0) { - lineno = PyObject_IsTrue(line_option) ? 1 : 0; + lineno = PyObject_IsTrue(line_option); + if (lineno < 0) + return NULL; } - if (col_option != NULL) { - col_offset = (PyObject_IsTrue(col_option) != 0) ? 1 : 0; + if (col_option != 0) { + col_offset = PyObject_IsTrue(col_option); + if (col_offset < 0) + return NULL; } /* * Convert ST into a tuple representation. Use Guido's function, diff -r 84899daa4309 Modules/pyexpat.c --- a/Modules/pyexpat.c Tue Aug 14 18:41:40 2012 +0300 +++ b/Modules/pyexpat.c Wed Aug 15 00:36:56 2012 +0300 @@ -1033,13 +1033,16 @@ xmlparse_UseForeignDTD(xmlparseobject *self, PyObject *args) { PyObject *flagobj = NULL; - XML_Bool flag = XML_TRUE; + int flag = 1; enum XML_Error rc; - if (!PyArg_UnpackTuple(args, "UseForeignDTD", 0, 1, &flagobj)) + if (!PyArg_ParseTuple(args, "O:UseForeignDTD", &flagobj)) return NULL; - if (flagobj != NULL) - flag = PyObject_IsTrue(flagobj) ? XML_TRUE : XML_FALSE; - rc = XML_UseForeignDTD(self->itself, flag); + if (flagobj != NULL) { + flag = PyObject_IsTrue(flagobj); + if (flag < 0) + return NULL; + } + rc = XML_UseForeignDTD(self->itself, flag ? XML_TRUE : XML_FALSE); if (rc != XML_ERROR_NONE) { return set_error(self, rc); } @@ -1397,7 +1400,10 @@ } assert(PyUnicode_Check(name)); if (PyUnicode_CompareWithASCIIString(name, "buffer_text") == 0) { - if (PyObject_IsTrue(v)) { + int b = PyObject_IsTrue(v); + if (b < 0) + return -1; + if (b) { if (self->buffer == NULL) { self->buffer = malloc(self->buffer_size); if (self->buffer == NULL) { @@ -1416,25 +1422,25 @@ return 0; } if (PyUnicode_CompareWithASCIIString(name, "namespace_prefixes") == 0) { - if (PyObject_IsTrue(v)) - self->ns_prefixes = 1; - else - self->ns_prefixes = 0; + int b = PyObject_IsTrue(v); + if (b < 0) + return -1; + self->ns_prefixes = b; XML_SetReturnNSTriplet(self->itself, self->ns_prefixes); return 0; } if (PyUnicode_CompareWithASCIIString(name, "ordered_attributes") == 0) { - if (PyObject_IsTrue(v)) - self->ordered_attributes = 1; - else - self->ordered_attributes = 0; + int b = PyObject_IsTrue(v); + if (b < 0) + return -1; + self->ordered_attributes = b; return 0; } if (PyUnicode_CompareWithASCIIString(name, "specified_attributes") == 0) { - if (PyObject_IsTrue(v)) - self->specified_attributes = 1; - else - self->specified_attributes = 0; + int b = PyObject_IsTrue(v); + if (b < 0) + return -1; + self->specified_attributes = b; return 0; } diff -r 84899daa4309 Objects/typeobject.c --- a/Objects/typeobject.c Tue Aug 14 18:41:40 2012 +0300 +++ b/Objects/typeobject.c Wed Aug 15 00:36:56 2012 +0300 @@ -353,12 +353,16 @@ } if (res == 0) { PyType_Modified(type); - if (value && PyObject_IsTrue(value)) { + int abstract = 0; + if (value) { + abstract = PyObject_IsTrue(value); + if (abstract < 0) + return -1; + } + if (abstract) type->tp_flags |= Py_TPFLAGS_IS_ABSTRACT; - } - else { + else type->tp_flags &= ~Py_TPFLAGS_IS_ABSTRACT; - } } return res; } diff -r 84899daa4309 Python/bltinmodule.c --- a/Python/bltinmodule.c Tue Aug 14 18:41:40 2012 +0300 +++ b/Python/bltinmodule.c Wed Aug 15 00:36:56 2012 +0300 @@ -428,9 +428,11 @@ ok = PyObject_IsTrue(good); Py_DECREF(good); } - if (ok) + if (ok > 0) return item; Py_DECREF(item); + if (ok < 0) + return NULL; } } diff -r 84899daa4309 Python/import.c --- a/Python/import.c Tue Aug 14 18:41:40 2012 +0300 +++ b/Python/import.c Wed Aug 15 00:36:56 2012 +0300 @@ -1338,7 +1338,10 @@ name, pathname); if (cpathname) { PyObject *ro = PySys_GetObject("dont_write_bytecode"); - if (ro == NULL || !PyObject_IsTrue(ro)) + int b = (ro == NULL) ? 0 : PyObject_IsTrue(ro); + if (b < 0) + goto error_exit; + if (!b) write_compiled_module(co, cpathname, &st); } } @@ -2504,7 +2507,13 @@ } if (fromlist != NULL) { - if (fromlist == Py_None || !PyObject_IsTrue(fromlist)) + int b = (fromlist == Py_None) ? 0 : PyObject_IsTrue(fromlist); + if (b < 0) { + Py_DECREF(tail); + Py_DECREF(head); + goto error_exit; + } + if (!b) fromlist = NULL; } -------------- next part -------------- diff -r db1b4aab53eb Modules/_csv.c --- a/Modules/_csv.c Tue Aug 07 11:57:47 2012 -0700 +++ b/Modules/_csv.c Wed Aug 15 00:37:12 2012 +0300 @@ -208,8 +208,12 @@ { if (src == NULL) *target = dflt; - else - *target = PyObject_IsTrue(src); + else { + int b = PyObject_IsTrue(src); + if (b < 0) + return -1; + *target = b; + } return 0; } diff -r db1b4aab53eb Modules/_io/textio.c --- a/Modules/_io/textio.c Tue Aug 07 11:57:47 2012 -0700 +++ b/Modules/_io/textio.c Wed Aug 15 00:37:12 2012 +0300 @@ -1013,8 +1013,11 @@ res = PyObject_CallMethod(buffer, "seekable", NULL); if (res == NULL) goto error; - self->seekable = self->telling = PyObject_IsTrue(res); + r = PyObject_IsTrue(res); Py_DECREF(res); + if (r < 0) + goto error; + self->seekable = self->telling = r; self->encoding_start_of_stream = 0; if (self->seekable && self->encoder) { diff -r db1b4aab53eb Modules/_ssl.c --- a/Modules/_ssl.c Tue Aug 07 11:57:47 2012 -0700 +++ b/Modules/_ssl.c Wed Aug 15 00:37:12 2012 +0300 @@ -1005,6 +1005,7 @@ int len; int verification; PyObject *binary_mode = Py_None; + int b; if (!PyArg_ParseTuple(args, "|O:peer_certificate", &binary_mode)) return NULL; @@ -1012,7 +1013,10 @@ if (!self->peer_cert) Py_RETURN_NONE; - if (PyObject_IsTrue(binary_mode)) { + b = PyObject_IsTrue(binary_mode); + if (b < 0) + return NULL; + if (b) { /* return cert in DER-encoded format */ unsigned char *bytes_buf = NULL; diff -r db1b4aab53eb Modules/cStringIO.c --- a/Modules/cStringIO.c Tue Aug 07 11:57:47 2012 -0700 +++ b/Modules/cStringIO.c Wed Aug 15 00:37:12 2012 +0300 @@ -127,12 +127,16 @@ static PyObject * IO_getval(IOobject *self, PyObject *args) { PyObject *use_pos=Py_None; + int b; Py_ssize_t s; if (!IO__opencheck(self)) return NULL; if (!PyArg_UnpackTuple(args,"getval", 0, 1,&use_pos)) return NULL; - if (PyObject_IsTrue(use_pos)) { + b = PyObject_IsTrue(use_pos); + if (b < 0) + return NULL; + if (b) { s=self->pos; if (s > self->string_size) s=self->string_size; } diff -r db1b4aab53eb Modules/itertoolsmodule.c --- a/Modules/itertoolsmodule.c Tue Aug 07 11:57:47 2012 -0700 +++ b/Modules/itertoolsmodule.c Wed Aug 15 00:37:12 2012 +0300 @@ -903,11 +903,13 @@ } ok = PyObject_IsTrue(good); Py_DECREF(good); - if (!ok) { + if (ok == 0) { lz->start = 1; return item; } Py_DECREF(item); + if (ok < 0) + return NULL; } } @@ -1043,10 +1045,11 @@ } ok = PyObject_IsTrue(good); Py_DECREF(good); - if (ok) + if (ok > 0) return item; Py_DECREF(item); - lz->stop = 1; + if (ok == 0) + lz->stop = 1; return NULL; } @@ -3001,9 +3004,11 @@ ok = PyObject_IsTrue(good); Py_DECREF(good); } - if (ok) + if (ok > 0) return item; Py_DECREF(item); + if (ok < 0) + return NULL; } } @@ -3144,9 +3149,11 @@ ok = PyObject_IsTrue(good); Py_DECREF(good); } - if (!ok) + if (ok == 0) return item; Py_DECREF(item); + if (ok < 0) + return NULL; } } diff -r db1b4aab53eb Modules/parsermodule.c --- a/Modules/parsermodule.c Tue Aug 07 11:57:47 2012 -0700 +++ b/Modules/parsermodule.c Wed Aug 15 00:37:12 2012 +0300 @@ -350,10 +350,14 @@ int lineno = 0; int col_offset = 0; if (line_option != NULL) { - lineno = (PyObject_IsTrue(line_option) != 0) ? 1 : 0; + lineno = PyObject_IsTrue(line_option); + if (lineno < 0) + return NULL; } if (col_option != NULL) { - col_offset = (PyObject_IsTrue(col_option) != 0) ? 1 : 0; + col_offset = PyObject_IsTrue(col_option); + if (col_offset < 0) + return NULL; } /* * Convert ST into a tuple representation. Use Guido's function, @@ -401,10 +405,14 @@ int lineno = 0; int col_offset = 0; if (line_option != 0) { - lineno = PyObject_IsTrue(line_option) ? 1 : 0; + lineno = PyObject_IsTrue(line_option); + if (lineno < 0) + return NULL; } - if (col_option != NULL) { - col_offset = (PyObject_IsTrue(col_option) != 0) ? 1 : 0; + if (col_option != 0) { + col_offset = PyObject_IsTrue(col_option); + if (col_offset < 0) + return NULL; } /* * Convert ST into a tuple representation. Use Guido's function, diff -r db1b4aab53eb Modules/pyexpat.c --- a/Modules/pyexpat.c Tue Aug 07 11:57:47 2012 -0700 +++ b/Modules/pyexpat.c Wed Aug 15 00:37:12 2012 +0300 @@ -1174,13 +1174,16 @@ xmlparse_UseForeignDTD(xmlparseobject *self, PyObject *args) { PyObject *flagobj = NULL; - XML_Bool flag = XML_TRUE; + int flag = 1; enum XML_Error rc; - if (!PyArg_UnpackTuple(args, "UseForeignDTD", 0, 1, &flagobj)) + if (!PyArg_ParseTuple(args, "O:UseForeignDTD", &flagobj)) return NULL; - if (flagobj != NULL) - flag = PyObject_IsTrue(flagobj) ? XML_TRUE : XML_FALSE; - rc = XML_UseForeignDTD(self->itself, flag); + if (flagobj != NULL) { + flag = PyObject_IsTrue(flagobj); + if (flag < 0) + return NULL; + } + rc = XML_UseForeignDTD(self->itself, flag ? XML_TRUE : XML_FALSE); if (rc != XML_ERROR_NONE) { return set_error(self, rc); } @@ -1549,7 +1552,10 @@ return -1; } if (strcmp(name, "buffer_text") == 0) { - if (PyObject_IsTrue(v)) { + int b = PyObject_IsTrue(v); + if (b < 0) + return -1; + if (b) { if (self->buffer == NULL) { self->buffer = malloc(self->buffer_size); if (self->buffer == NULL) { @@ -1568,39 +1574,39 @@ return 0; } if (strcmp(name, "namespace_prefixes") == 0) { - if (PyObject_IsTrue(v)) - self->ns_prefixes = 1; - else - self->ns_prefixes = 0; + int b = PyObject_IsTrue(v); + if (b < 0) + return -1; + self->ns_prefixes = b; XML_SetReturnNSTriplet(self->itself, self->ns_prefixes); return 0; } if (strcmp(name, "ordered_attributes") == 0) { - if (PyObject_IsTrue(v)) - self->ordered_attributes = 1; - else - self->ordered_attributes = 0; + int b = PyObject_IsTrue(v); + if (b < 0) + return -1; + self->ordered_attributes = b; return 0; } if (strcmp(name, "returns_unicode") == 0) { - if (PyObject_IsTrue(v)) { + int b = PyObject_IsTrue(v); + if (b < 0) + return -1; #ifndef Py_USING_UNICODE + if (b) { PyErr_SetString(PyExc_ValueError, "Unicode support not available"); return -1; -#else - self->returns_unicode = 1; + } #endif - } - else - self->returns_unicode = 0; + self->returns_unicode = b; return 0; } if (strcmp(name, "specified_attributes") == 0) { - if (PyObject_IsTrue(v)) - self->specified_attributes = 1; - else - self->specified_attributes = 0; + int b = PyObject_IsTrue(v); + if (b < 0) + return -1; + self->specified_attributes = b; return 0; } diff -r db1b4aab53eb Objects/typeobject.c --- a/Objects/typeobject.c Tue Aug 07 11:57:47 2012 -0700 +++ b/Objects/typeobject.c Wed Aug 15 00:37:12 2012 +0300 @@ -340,12 +340,16 @@ } if (res == 0) { PyType_Modified(type); - if (value && PyObject_IsTrue(value)) { + int abstract = 0; + if (value) { + abstract = PyObject_IsTrue(value); + if (abstract < 0) + return -1; + } + if (abstract) type->tp_flags |= Py_TPFLAGS_IS_ABSTRACT; - } - else { + else type->tp_flags &= ~Py_TPFLAGS_IS_ABSTRACT; - } } return res; } diff -r db1b4aab53eb Python/bltinmodule.c --- a/Python/bltinmodule.c Tue Aug 07 11:57:47 2012 -0700 +++ b/Python/bltinmodule.c Wed Aug 15 00:37:12 2012 +0300 @@ -313,7 +313,7 @@ ok = PyObject_IsTrue(good); Py_DECREF(good); } - if (ok) { + if (ok > 0) { if (j < len) PyList_SET_ITEM(result, j, item); else { @@ -324,8 +324,11 @@ } ++j; } - else + else { Py_DECREF(item); + if (ok < 0) + goto Fail_result_it; + } } @@ -2784,12 +2787,15 @@ } ok = PyObject_IsTrue(good); Py_DECREF(good); - if (ok) { + if (ok > 0) { if (PyTuple_SetItem(result, j++, item) < 0) goto Fail_1; } - else + else { Py_DECREF(item); + if (ok < 0) + goto Fail_1; + } } if (_PyTuple_Resize(&result, j) < 0) @@ -2851,7 +2857,7 @@ ok = PyObject_IsTrue(good); Py_DECREF(good); } - if (ok) { + if (ok > 0) { Py_ssize_t reslen; if (!PyString_Check(item)) { PyErr_SetString(PyExc_TypeError, "can't filter str to str:" @@ -2917,6 +2923,8 @@ } } Py_DECREF(item); + if (ok < 0) + goto Fail_1; } if (j < outlen) @@ -2977,7 +2985,7 @@ ok = PyObject_IsTrue(good); Py_DECREF(good); } - if (ok) { + if (ok > 0) { Py_ssize_t reslen; if (!PyUnicode_Check(item)) { PyErr_SetString(PyExc_TypeError, @@ -3032,6 +3040,8 @@ } } Py_DECREF(item); + if (ok < 0) + goto Fail_1; } if (j < outlen) diff -r db1b4aab53eb Python/import.c --- a/Python/import.c Tue Aug 07 11:57:47 2012 -0700 +++ b/Python/import.c Wed Aug 15 00:37:12 2012 +0300 @@ -1043,7 +1043,10 @@ name, pathname); if (cpathname) { PyObject *ro = PySys_GetObject("dont_write_bytecode"); - if (ro == NULL || !PyObject_IsTrue(ro)) + int b = (ro == NULL) ? 0 : PyObject_IsTrue(ro); + if (b < 0) + goto error_exit; + if (!b) write_compiled_module(co, cpathname, &st); } } @@ -2200,7 +2203,13 @@ } if (fromlist != NULL) { - if (fromlist == Py_None || !PyObject_IsTrue(fromlist)) + int b = (fromlist == Py_None) ? 0 : PyObject_IsTrue(fromlist); + if (b < 0) { + Py_DECREF(tail); + Py_DECREF(head); + goto error_exit; + } + if (!b) fromlist = NULL; } From report at bugs.python.org Wed Aug 15 00:41:17 2012 From: report at bugs.python.org (Oskars) Date: Tue, 14 Aug 2012 22:41:17 +0000 Subject: [issue15658] Idle stopped working Message-ID: <1344984077.82.0.261608430335.issue15658@psf.upfronthosting.co.za> New submission from Oskars: For some years I used Python with IDLE, including my Windows 7 machine. In January IDLE stopped working. Whenever I tried to open with file with IDLE, nothing happened. No error message. Nothing. After some help from help at python.org I typed at the command line "C:\Python27\Lib\idlelib\idle.py -n" and I got this error: IO Error: [Errno 13] Permission denied: 'C:\\Users\\Osk\\.idlerc\\recent-files.lst' So I went to look at the directory .idlerc and found it empty. No recent-files.lst. (Though it may be because it is a hidden file) Now I think the problem is fixed - or at least for the time being. I went to the admin identity and found that IDLE does open up there. So I made a copy of the recent-files.lst file and emailed it to myself. Then I went to my wife's identity. And, again, IDLE opened OK. Finally, I went back to my identity and renamed the file there to "recent-files-H.lst". Then I retrieved the file I had emailed to myself and placed it into the .idlerc directory of my account as "recent-files.lst". Suddenly I could open IDLE and run Python, as before! The mystery remains - what happened? When I compared the contents of the old recent-files.lst and the one I replace it with, the only difference I could find is that the old one had 17 entries, the new one had only one entry. ---------- components: IDLE messages: 168244 nosy: opapOj priority: normal severity: normal status: open title: Idle stopped working type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 02:04:51 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 15 Aug 2012 00:04:51 +0000 Subject: [issue15269] Document dircmp.left and dircmp.right In-Reply-To: <1341635280.22.0.709109531165.issue15269@psf.upfronthosting.co.za> Message-ID: <1344989091.11.0.492420150672.issue15269@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Senthil, here is a recent e-mail and response in which I asked about documentation changes and adding tests during feature freeze: http://mail.python.org/pipermail/python-dev/2012-July/121138.html Also, here is a recent example of a documentation clarification that went into 2.7, 3.2, and tip: http://bugs.python.org/issue15554 Thanks again. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 02:23:02 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 15 Aug 2012 00:23:02 +0000 Subject: [issue14649] doctest.DocTestSuite error misleading when module has no docstrings In-Reply-To: <1335192861.9.0.305748973415.issue14649@psf.upfronthosting.co.za> Message-ID: <1344990182.91.0.720492591435.issue14649@psf.upfronthosting.co.za> Chris Jerdonek added the comment: The problem seems to be restricted only to DocTestSuite. testmod and DocTestFinder both seem to work fine. DocTestSuite calls DocTestFinder but not the other way around: nothing calls DocTestSuite. If in certain versions we do not treat raising the exception as a bug (e.g. in already-released versions), then I am hoping we can at least document the behavior as a known issue in those versions and still change the exception message to be more accurate and helpful. Aside from ensuring that docstrings are present, another way to work around the issue is to pass a DocTestFinder to DocTestSuite with exclude_empty set to False, as in the following code: finder = DocTestFinder(exclude_empty=False) suite = DocTestSuite(module, test_finder=finder) Depending on what we decide for which versions, I am willing to create two patches: one for the documentation and exception message change (e.g. for stable versions), and another to drop raising the exception (e.g. for future versions). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 02:41:16 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 15 Aug 2012 00:41:16 +0000 Subject: [issue15204] Deprecate the 'U' open mode In-Reply-To: <1340792991.22.0.497199331706.issue15204@psf.upfronthosting.co.za> Message-ID: <1344991276.35.0.424135181559.issue15204@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The only people affected by deprecating "U" are the people who are currently using it for some reason -- presumably they are expecting that it does something useful for their code. Ideally, this proposed deprecation should be mentioned on python-dev so that those folks will have an opportunity to respond. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 03:01:26 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 15 Aug 2012 01:01:26 +0000 Subject: [issue15543] central documentation for 'universal newlines' In-Reply-To: <1343953234.25.0.0555174882779.issue15543@psf.upfronthosting.co.za> Message-ID: <1344992486.77.0.0149070790513.issue15543@psf.upfronthosting.co.za> R. David Murray added the comment: Yeah, we might as well be consistent, though it's not a big deal either way. I'd prefer that as a separate patch. Any interest in backporting this to 2.7? Being so close to final release on 3.2 I think we can skip 3.2, unless you feel like doing it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 03:09:02 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 15 Aug 2012 01:09:02 +0000 Subject: [issue15658] Idle stopped working In-Reply-To: <1344984077.82.0.261608430335.issue15658@psf.upfronthosting.co.za> Message-ID: <1344992942.73.0.741165393452.issue15658@psf.upfronthosting.co.za> R. David Murray added the comment: I believe this is a duplicate of issue 4625. ---------- nosy: +r.david.murray resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> IDLE won't open anymore, .idlerc unaccessible type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 03:09:17 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 15 Aug 2012 01:09:17 +0000 Subject: [issue15543] central documentation for 'universal newlines' In-Reply-To: <1343953234.25.0.0555174882779.issue15543@psf.upfronthosting.co.za> Message-ID: <1344992957.49.0.534350185573.issue15543@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Sure, I'd be happy to do both 2.7 and 3.2. I can upload the patch for the default branch as a delta to apply after the 3.2 change has been forward-ported from 3.2 to default. Thanks for taking an interest in this! ---------- versions: +Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 03:30:19 2012 From: report at bugs.python.org (Michael) Date: Wed, 15 Aug 2012 01:30:19 +0000 Subject: [issue15659] using os.fork() and import user's modules results in errors Message-ID: <1344994219.74.0.135475892924.issue15659@psf.upfronthosting.co.za> New submission from Michael: if I import any python script in the beginning of the code in then I haver next errors: Error in atexit._run_exitfuncs: Traceback (most recent call last): File "/usr/lib/python2.7/atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "/usr/lib/python2.7/multiprocessing/util.py", line 295, in _exit_function p.join() File "/usr/lib/python2.7/multiprocessing/process.py", line 143, in join assert self._parent_pid == os.getpid(), 'can only join a child process' AssertionError: can only join a child process Error in sys.exitfunc: Traceback (most recent call last): File "/usr/lib/python2.7/atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "/usr/lib/python2.7/multiprocessing/util.py", line 295, in _exit_function p.join() File "/usr/lib/python2.7/multiprocessing/process.py", line 143, in join assert self._parent_pid == os.getpid(), 'can only join a child process' AssertionError: can only join a child process ---------- components: None files: mydaemon.py messages: 168251 nosy: michaeluc priority: normal severity: normal status: open title: using os.fork() and import user's modules results in errors type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file26816/mydaemon.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 03:37:04 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 15 Aug 2012 01:37:04 +0000 Subject: [issue15659] using os.fork() and import user's modules results in errors In-Reply-To: <1344994219.74.0.135475892924.issue15659@psf.upfronthosting.co.za> Message-ID: <1344994624.68.0.379332460144.issue15659@psf.upfronthosting.co.za> R. David Murray added the comment: The example you uploaded doesn't call multiprocessing, yet the traceback you show does. Can you provide more details on what you are actually doing? Note that if you are importing a module that does a fork when it is imported, you are doing something wrong. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 03:51:23 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 15 Aug 2012 01:51:23 +0000 Subject: [issue15269] Document dircmp.left and dircmp.right In-Reply-To: <1341635280.22.0.709109531165.issue15269@psf.upfronthosting.co.za> Message-ID: <3WxYYj3WZfzQ7P@mail.python.org> Roundup Robot added the comment: New changeset 7590dec388a7 by R David Murray in branch '3.2': #15269: document dircmp.left and right, and add tests for them. http://hg.python.org/cpython/rev/7590dec388a7 New changeset c592e5a8fa4f by R David Murray in branch 'default': Merge #15269: document dircmp.left and right, and add tests for them. http://hg.python.org/cpython/rev/c592e5a8fa4f New changeset e64d4518b23c by R David Murray in branch '2.7': #15269: document dircmp.left and right. http://hg.python.org/cpython/rev/e64d4518b23c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 03:52:28 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 15 Aug 2012 01:52:28 +0000 Subject: [issue15269] Document dircmp.left and dircmp.right In-Reply-To: <1341635280.22.0.709109531165.issue15269@psf.upfronthosting.co.za> Message-ID: <1344995548.98.0.307497813562.issue15269@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Chris. ---------- nosy: +r.david.murray resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 04:01:05 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 15 Aug 2012 02:01:05 +0000 Subject: [issue15586] Provide some examples for usage of ElementTree methods/attributes In-Reply-To: <1344407679.24.0.102359835139.issue15586@psf.upfronthosting.co.za> Message-ID: <1344996065.35.0.789490867813.issue15586@psf.upfronthosting.co.za> ?ric Araujo added the comment: I noticed a long-standing typo in the latest commit: the country is named Liechtenstein :) ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 04:10:45 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 15 Aug 2012 02:10:45 +0000 Subject: [issue15649] subprocess.Popen.communicate: accept str for input parameter if universal_newlines is False In-Reply-To: <1344959221.38.0.0409924242397.issue15649@psf.upfronthosting.co.za> Message-ID: <1344996645.38.0.401887408888.issue15649@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 04:51:26 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 15 Aug 2012 02:51:26 +0000 Subject: [issue15657] Error in Python 3 docs for PyMethodDef In-Reply-To: <1344970966.7.0.115664419243.issue15657@psf.upfronthosting.co.za> Message-ID: <1344999086.34.0.0031302274021.issue15657@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 04:56:58 2012 From: report at bugs.python.org (Michael) Date: Wed, 15 Aug 2012 02:56:58 +0000 Subject: [issue15659] using os.fork() and import user's modules results in errors In-Reply-To: <1344994219.74.0.135475892924.issue15659@psf.upfronthosting.co.za> Message-ID: <1344999418.98.0.175216910157.issue15659@psf.upfronthosting.co.za> Michael added the comment: thanks David, scripts which I imported were relying on some librarary which I did not understand. I was able to get rid of it and I don't have these errors any more. It was bug in my program. Thank you again. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 05:41:22 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 15 Aug 2012 03:41:22 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1345002082.16.0.116370666944.issue15573@psf.upfronthosting.co.za> Nick Coghlan added the comment: Yeah, as soon as I got your email I realised I'd only been searching for usage *in the patch* rather than the full file. Oops :( More comments in the review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 06:20:40 2012 From: report at bugs.python.org (py.user) Date: Wed, 15 Aug 2012 04:20:40 +0000 Subject: [issue15660] In str.format there is a misleading error message about alignment Message-ID: <1345004440.11.0.680139192916.issue15660@psf.upfronthosting.co.za> New submission from py.user: >>> '{:02}'.format('a') Traceback (most recent call last): File "", line 1, in ValueError: '=' alignment not allowed in string format specifier >>> according to http://docs.python.org/py3k/library/string.html#formatspec the default alignment is '<' or '>' ---------- components: Interpreter Core messages: 168258 nosy: py.user priority: normal severity: normal status: open title: In str.format there is a misleading error message about alignment type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 06:22:52 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 15 Aug 2012 04:22:52 +0000 Subject: [issue15660] In str.format there is a misleading error message about alignment In-Reply-To: <1345004440.11.0.680139192916.issue15660@psf.upfronthosting.co.za> Message-ID: <1345004572.5.0.322992234744.issue15660@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +eric.smith, ezio.melotti stage: -> needs patch versions: +Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 06:27:57 2012 From: report at bugs.python.org (py.user) Date: Wed, 15 Aug 2012 04:27:57 +0000 Subject: [issue15660] In str.format there is a misleading error message about alignment In-Reply-To: <1345004440.11.0.680139192916.issue15660@psf.upfronthosting.co.za> Message-ID: <1345004877.3.0.276782091164.issue15660@psf.upfronthosting.co.za> py.user added the comment: found a small string in the doc about zero padding, which enables alignment equal to = ---------- versions: -Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 07:40:23 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 15 Aug 2012 05:40:23 +0000 Subject: [issue13252] new decumulate() function in itertools module In-Reply-To: <1319409168.22.0.462760902888.issue13252@psf.upfronthosting.co.za> Message-ID: <1345009223.64.0.483038288131.issue13252@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I also agree that the itertools module doesn't need this. (Reasons of "symmetry" are insufficient to make the module fatter that it already is). In addition, there are already a number of simple ways to do this. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 08:15:44 2012 From: report at bugs.python.org (Stefan Behnel) Date: Wed, 15 Aug 2012 06:15:44 +0000 Subject: [issue15623] Init time relative imports no longer work from __init__.so modules In-Reply-To: <1344697325.25.0.880049566038.issue15623@psf.upfronthosting.co.za> Message-ID: <1345011344.2.0.287140564082.issue15623@psf.upfronthosting.co.za> Stefan Behnel added the comment: I tried it and it works to just insert the package module into sys.modules after creation if it's not there yet: #if PY_MAJOR_VERSION < 3 __pyx_m = Py_InitModule4(__Pyx_NAMESTR("my_test_package"), __pyx_methods, 0, 0, PYTHON_API_VERSION); #else __pyx_m = PyModule_Create(&__pyx_moduledef); #endif if (!__pyx_m) {...}; PyObject *modules = PyImport_GetModuleDict(); if (unlikely(!modules)) {...} if (!PyDict_GetItemString(modules, "my_test_package")) if (unlikely(PyDict_SetItemString(modules, "my_test_package", __pyx_m) < 0)) {...} So this is a work-around that we can use in Cython in any case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 08:55:08 2012 From: report at bugs.python.org (Ned Deily) Date: Wed, 15 Aug 2012 06:55:08 +0000 Subject: [issue15661] OS X installer packages should be signed for OS X 10.8 Gatekeeper feature Message-ID: <1345013707.82.0.343684011424.issue15661@psf.upfronthosting.co.za> New submission from Ned Deily: OS 10.8 Mountain Lion includes a new feature that "helps protect users from downloading and installing malicious software" by providing a mechanism for developers to sign their installable objects with a unique Apple-signed Developer ID certificate. The default security policy for 10.8 is to only allow installation of items that have been signed. The user is able to override that policy either persistently for all installs (using System Preferences) or selectively for individual unsigned items (for example, by using control-click and "Open with"). OS X allows various items to be signed, including executables, application bundles, application frameworks, and installer packages. The python.org OS X installations includes all of these. For applications to be made available through the Mac App Store, all of these have to be signed and there are additional requirements, such as sandboxing and restrictions on API usage, that are not compatible with a general-purpose programming environment such as Python provides. Therefore, this issue is only concerned with meeting the requirements for 10.8 Gatekeeper and "Distributing Outside the Mac App Store" (see references below). Each python.org OS X release is delivered via an OS X installer package (.mpkg) within an OS X diskimage file (.dmg) and installed using the standard OS X installer. So, at a minimum, the only entity that needs to be signed is each installer package we produce. Unfortunately, the Python installer build process (as encapsulated in Mac/BuildScript/build-installer.py) currently packages releases in an old deprecated bundle (non-flat) metapackage format that cannot be signed. That means build-installer.py and the manual process surrounding releases need to be updated to produce the newer flat package formats that can then be signed using a unique Developer ID Installer certificate requested from and signed by Apple. Several points: 1. The changes needed to support the newer sign-able installer formats should be able to be limited to python-installer.py itself and so should minimize risk to other releases and Python itself. Likewise, to the end user, the installation process should look (nearly) identical to the current process as the same system installer app is used. Of course, the install process will need to be tested to ensure that the new format packages produce the same results (i.e. files, permissions) on the user system as the old format packages do. It may be possible and desirable to include these changes in the upcoming 3.3.0 release or, if not available in time, in a subsequent 3.3.x maintenance release. (I am currently working on the changes.) 2. There is a process question of what Developer ID(s) to use for requesting Installer certificates for singing. As documented, Apple requires the requestor of a singing certificate to be a member of the Mac Developer Program which normally involves a modest annual fee. One can be a member of the developer program as an individual developer or as a member of a development team associated with a company or other legal entity. This distinction affects how the installation is presented to the user. I believe that we should aim to have a Python Software Foundation development team membership with the builders of python.org releases as team members as needed (currently that means me with Ronald as backup). It is beyond the scope of this issue to define and implement that process. In the immediate future, once the new installer package is supported, in lieu of a PSF-backed certificate, it *may* be desirable to sign the package with an individual certificate (both Ronald and I are individual members of the developer program). That is roughly analogous to the current practice of using individual release team members' PGP keys to sign Python release artifacts (source tar balls and binary installers) that are downloadable from python.org although it may not be as visible to the user as the Gatekeeper signing. We will pursue the development team option outside of this tracker issue with PSF officers. 3. I believe it is the case that the newer flat package formats are not supported on OS X 10.3 and only partially supported on OS X 10.4. For Python 2.7.x and 3.2.x, we have been producing two installers: a 32-bit-only installer for 10.3+ and a 64-bit/32-bit installer for 10.6+. For Python 3.3, we have changed the minimum requirements for the 32-bit-only installer to be 10.5+. So it should be possible to move all 3.3.x installers to the new format and sign them. For older releases, we will have to look at the tradeoffs. Since we have kept the build-installer.py script identical for current releases of Python 2.7.x and Python 3.2.x, additional implementation costs and risks are small: the modified 3.3.0 script should work for 3.2.x and 2.7.x releases as well. Without introducing ABI incompatibilities within a major release cycle, one option may be to: do not change the 2.7.x 32-bit-installer format (so that it is still usable on 10.3 and 10.4), change the 2.7.x 64-bit-installer to the new format so it can be signed, and either do the same for 3.2.x or do nothing new (since 3.2.x will be entering security-fix-only mode sometime after the release of 3.3.0). The open issues should be decided after implementing the new format support and testing to see if the assumptions are correct. References: http://support.apple.com/kb/HT5290 https://developer.apple.com/resources/developer-id/ https://developer.apple.com/programs/mac/team.html ---------- assignee: ned.deily components: Build, Installation, Macintosh messages: 168262 nosy: ned.deily, ronaldoussoren priority: high severity: normal stage: needs patch status: open title: OS X installer packages should be signed for OS X 10.8 Gatekeeper feature type: enhancement versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 09:14:13 2012 From: report at bugs.python.org (Ned Deily) Date: Wed, 15 Aug 2012 07:14:13 +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: <1345014853.6.0.535595434327.issue15661@psf.upfronthosting.co.za> Ned Deily added the comment: An additional point: the 3.3.0 Installer README and python.org web pages need to be updated to incorporate 10.8 installation information as necessary prior to final release. (in progress) Also, s/singing/signing/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 09:19:23 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Wed, 15 Aug 2012 07:19:23 +0000 Subject: [issue15649] subprocess.Popen.communicate: accept str for input parameter if universal_newlines is False In-Reply-To: <1344959221.38.0.0409924242397.issue15649@psf.upfronthosting.co.za> Message-ID: <1345015163.42.0.428871961946.issue15649@psf.upfronthosting.co.za> Ramchandra Apte added the comment: Uhum.. Universal Newlines is being deprecated. ---------- nosy: +ramchandra.apte _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 09:36:57 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 15 Aug 2012 07:36:57 +0000 Subject: [issue15649] subprocess.Popen.communicate: accept str for input parameter if universal_newlines is False In-Reply-To: <1344959221.38.0.0409924242397.issue15649@psf.upfronthosting.co.za> Message-ID: <1345016217.53.0.367079623466.issue15649@psf.upfronthosting.co.za> R. David Murray added the comment: No it isn't. There's some issue about a 'U' parameter somewhere that is being deprecated, but that has nothing to do with this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 10:50:23 2012 From: report at bugs.python.org (Robin Schreiber) Date: Wed, 15 Aug 2012 08:50:23 +0000 Subject: [issue15390] PEP 3121, 384 refactoring applied to datetime module In-Reply-To: <1342647232.82.0.0763290244077.issue15390@psf.upfronthosting.co.za> Message-ID: <1345020623.41.0.301893024126.issue15390@psf.upfronthosting.co.za> Robin Schreiber added the comment: I have now included the changes that Antoine suggested. The _Get_State was used for debugging purposes and is, as I think, no longer necessary. However we have yet to find a solution for the decref inside the dealloc methods. ---------- Added file: http://bugs.python.org/file26817/_datetimemodule_pep3121-384_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 11:00:51 2012 From: report at bugs.python.org (Robin Schreiber) Date: Wed, 15 Aug 2012 09:00:51 +0000 Subject: [issue15655] PEP 384 Refactoring applied to json module In-Reply-To: <1344970398.16.0.223655068768.issue15655@psf.upfronthosting.co.za> Message-ID: <1345021251.03.0.392482080661.issue15655@psf.upfronthosting.co.za> Robin Schreiber added the comment: Removed C++ comment and corresponding codesnipped. Also changed bad-style macro definition. ---------- Added file: http://bugs.python.org/file26818/_json_pep384_v1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 11:05:32 2012 From: report at bugs.python.org (Robin Schreiber) Date: Wed, 15 Aug 2012 09:05:32 +0000 Subject: [issue15662] PEP 3121 refactoring applied to locale module Message-ID: <1345021532.95.0.601509802957.issue15662@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 have now been applied to the locale module! ---------- components: Extension Modules files: _locale_pep3121_v0.patch keywords: patch messages: 168268 nosy: Robin.Schreiber, loewis priority: normal severity: normal status: open title: PEP 3121 refactoring applied to locale module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26819/_locale_pep3121_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 11:20:34 2012 From: report at bugs.python.org (Ned Deily) Date: Wed, 15 Aug 2012 09:20:34 +0000 Subject: [issue15663] Investigate providing Tcl/Tk 8.5 with OS X installers Message-ID: <1345022434.53.0.691858342769.issue15663@psf.upfronthosting.co.za> New submission from Ned Deily: The current situation with Tcl/Tk on OS X is less than ideal. The Apple-supplied versions of the Cocoa-based Aqua Tk 8.5 on 10.6 was unusable with IDLE and most Tkinter applications. The 10.7 and 10.8 versions are better but still have serious crashers that have been more recently fixed. python.org installers currently also support using ActiveTcl release but that is also not ideal as there are license restrictions for some users and a separate download and install is required. We should be able to provide a better out-of-the-box experience if python.org installers included its own copies of up-to-date Tcl/Tk libraries (as is the case with the Windows installers). It would be good to still give users the option to use ActiveTcl for any of its additional features or to use system Python. Also we could also look at providing Tcl/Tk 8.5 for 10.5 users (possibly only Intel ones) which we currently do not. ---------- assignee: ned.deily components: Build, Installation, Macintosh messages: 168269 nosy: ned.deily, ronaldoussoren priority: normal severity: normal status: open title: Investigate providing Tcl/Tk 8.5 with OS X installers type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 11:25:01 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 15 Aug 2012 09:25:01 +0000 Subject: [issue15663] Investigate providing Tcl/Tk 8.5 with OS X installers In-Reply-To: <1345022434.53.0.691858342769.issue15663@psf.upfronthosting.co.za> Message-ID: <1345022701.85.0.547015609473.issue15663@psf.upfronthosting.co.za> Ronald Oussoren added the comment: A major reason for why the current installers don't install Tk as well is that this would significantly increase the size of the installer. There's also the question of what bits of Tcl/Tk should be bundled, although I guess we should ship a minimal install of Tk that still supports everything that is wrapped by the python std lib. Alternatively we could ship the same subset as the Windows installer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 11:38:00 2012 From: report at bugs.python.org (Ned Deily) Date: Wed, 15 Aug 2012 09:38:00 +0000 Subject: [issue15663] Investigate providing Tcl/Tk 8.5 with OS X installers In-Reply-To: <1345022434.53.0.691858342769.issue15663@psf.upfronthosting.co.za> Message-ID: <1345023480.27.0.783474683422.issue15663@psf.upfronthosting.co.za> Ned Deily added the comment: Yes, it would have to be a subset since some of the stuff in the ActiveTcl releases is unavailable anyway. But the current ActiveTcl installer dmgs are around 24Mb while the 3.3.0 installers are a little less than 20Mb. Even if it were to double the size, 40Mb still seems pretty small by today's standards. And following the Windows installer lead would be a good starting point. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 12:31:19 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 15 Aug 2012 10:31:19 +0000 Subject: [issue15664] test_curses not run with 'make test' Message-ID: <1345026679.72.0.767220182308.issue15664@psf.upfronthosting.co.za> New submission from Ronald Oussoren: I noticed that 'test_curses' is not started when performing "make test" on an OSX box: ... [ 42/369] test_curses test_curses skipped -- sys.__stdout__ is not a tty ... The host is a machine running OSX 10.8, fully up-to-date with patches and the current version of Xcode. The same thing happens when starting the testrunning in the same way as used by the test target in the Makefile: $ ./python.exe -W default -bb -E -R -m test -r -w -j 0 -u all,-largefile,-audio,-gui test_curses Using random seed 9471227 [1/1] test_curses test_curses skipped -- sys.__stdout__ is not a tty 1 test skipped: test_curses Those skips are all expected on darwin. ---------- components: Tests messages: 168272 nosy: ronaldoussoren priority: normal severity: normal status: open title: test_curses not run with 'make test' versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 12:31:23 2012 From: report at bugs.python.org (Thomas Miedema) Date: Wed, 15 Aug 2012 10:31:23 +0000 Subject: [issue15535] Fix pickling of named tuples in 2.7.3 In-Reply-To: <1343915086.31.0.252328658724.issue15535@psf.upfronthosting.co.za> Message-ID: <1345026683.82.0.663579176177.issue15535@psf.upfronthosting.co.za> Thomas Miedema added the comment: Attached is a script that shows the problem at hand. Note that my remark that this bug could result in very large pickled files when using nested namedtuples seems not te be true. ---------- Added file: http://bugs.python.org/file26820/show_namedtuple_pickle_fix.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 12:45:02 2012 From: report at bugs.python.org (Ned Deily) Date: Wed, 15 Aug 2012 10:45:02 +0000 Subject: [issue15664] test_curses not run with 'make test' In-Reply-To: <1345026679.72.0.767220182308.issue15664@psf.upfronthosting.co.za> Message-ID: <1345027502.81.0.664868008241.issue15664@psf.upfronthosting.co.za> Ned Deily added the comment: This appears to be the same issue as raised in Issue12669. Apparently it is not fixed. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 12:45:44 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 15 Aug 2012 10:45:44 +0000 Subject: [issue13370] test_ctypes fails when building python with clang In-Reply-To: <1320761474.93.0.268896325495.issue13370@psf.upfronthosting.co.za> Message-ID: <1345027544.83.0.0755572492974.issue13370@psf.upfronthosting.co.za> Ronald Oussoren added the comment: The attached patch syncs libffi_osx with the copy of libffi that's included with PyObjC. With this patch test_ctypes passes for me when using clang to build on OSX 10.8. I haven't run the tests with other python releases yet, and also not on a OSX 10.5 system (where I can test if the patch works with GCC as well) ---------- Added file: http://bugs.python.org/file26821/issue_13370.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 12:52:42 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 15 Aug 2012 10:52:42 +0000 Subject: [issue15664] test_curses not run with 'make test' In-Reply-To: <1345026679.72.0.767220182308.issue15664@psf.upfronthosting.co.za> Message-ID: <1345027962.9.0.757529979059.issue15664@psf.upfronthosting.co.za> Ronald Oussoren added the comment: the test does get run with 'make buildbottest', and then fails with a ValueError exception: $ /Users/ronald/Projects/python/rw/default/tbuild/python.exe -W default -bb -E -R -m test -r -w -j 1 -u all -W --timeout=3600 test_curses Using random seed 2242495 [1/1] test_curses test test_curses crashed -- Traceback (most recent call last): File "/Users/ronald/Projects/python/rw/default/Lib/test/regrtest.py", line 1221, in runtest_inner test_runner() File "/Users/ronald/Projects/python/rw/default/Lib/test/test_curses.py", line 338, in test_main main(stdscr) File "/Users/ronald/Projects/python/rw/default/Lib/test/test_curses.py", line 324, in main test_unget_wch(stdscr) File "/Users/ronald/Projects/python/rw/default/Lib/test/test_curses.py", line 283, in test_unget_wch read = chr(read) ValueError: chr() arg not in range(0x110000) That might be a bug in libcurses on OSX, I haven't tested with a separate install of libcurses yet. BTW. The patch mentioned in Issue12669 looks slightly bogus: as buildbot is a daemon it might not even have a controlling tty. With some luck a proper fix will require the explicit use of a pseudo-tty. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 12:59:51 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Wed, 15 Aug 2012 10:59:51 +0000 Subject: [issue11062] mailbox fails to round-trip a file to a Babyl mailbox In-Reply-To: <1296317976.28.0.825353703674.issue11062@psf.upfronthosting.co.za> Message-ID: <1345028391.69.0.100885479823.issue11062@psf.upfronthosting.co.za> Petri Lehtinen added the comment: This happens because of a bug in Babyl._install_message(). When adding a message from file, the "*** EOOH ***" line is written also after the second set of headers. ---------- nosy: +petri.lehtinen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 13:02:54 2012 From: report at bugs.python.org (Ned Deily) Date: Wed, 15 Aug 2012 11:02:54 +0000 Subject: [issue15664] test_curses not run with 'make test' In-Reply-To: <1345026679.72.0.767220182308.issue15664@psf.upfronthosting.co.za> Message-ID: <1345028574.52.0.565976987159.issue15664@psf.upfronthosting.co.za> Ned Deily added the comment: The "chr() arg not in range(0x110000)" from test_unget_wch is due to a bug in ncurses < 5.8; see Issue15037. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 13:21:00 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 15 Aug 2012 11:21:00 +0000 Subject: [issue15664] test_curses not run with 'make test' In-Reply-To: <1345026679.72.0.767220182308.issue15664@psf.upfronthosting.co.za> Message-ID: <1345029660.34.0.59573271887.issue15664@psf.upfronthosting.co.za> Ronald Oussoren added the comment: I knew the test failure looked familiar, but couldn't find the issue in the tracker. This issue (test_curses not running with make test) is due to '-j0' in the arguments to the test runner: with -j0 the runner uses multiprocessing and the stdout and stderr of the child processes are pipes, hence both sys.stdout and sys.__stdout__ are not tty's and the test isn't started. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 13:27:27 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 15 Aug 2012 11:27:27 +0000 Subject: [issue15586] Provide some examples for usage of ElementTree methods/attributes In-Reply-To: <1344407679.24.0.102359835139.issue15586@psf.upfronthosting.co.za> Message-ID: <3WxpLQ33kFzQBM@mail.python.org> Roundup Robot added the comment: New changeset 8d90fde35cc6 by Eli Bendersky in branch 'default': Issue #15586: typo fix. This commit is accompanied by an apology for all Liechtensteiners out there, and a thanks to Eric Araujo for noticing. http://hg.python.org/cpython/rev/8d90fde35cc6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 13:38:54 2012 From: report at bugs.python.org (Eli Bendersky) Date: Wed, 15 Aug 2012 11:38:54 +0000 Subject: [issue15586] Provide some examples for usage of ElementTree methods/attributes In-Reply-To: <1344407679.24.0.102359835139.issue15586@psf.upfronthosting.co.za> Message-ID: <1345030734.33.0.735511081438.issue15586@psf.upfronthosting.co.za> Eli Bendersky added the comment: Daniel, this looks good except that the section numbering is different from 3.3 where the object/function reference sections were nested under "Reference". Could you fix your patch to align the 2.7 doc to this structure? P.S. ?ric's comment also has to be fixed ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 13:41:31 2012 From: report at bugs.python.org (Eli Bendersky) Date: Wed, 15 Aug 2012 11:41:31 +0000 Subject: [issue15656] "Extending Python with C" page needs update for 3.x In-Reply-To: <1344970665.85.0.951420699824.issue15656@psf.upfronthosting.co.za> Message-ID: <1345030891.68.0.239608819172.issue15656@psf.upfronthosting.co.za> Changes by Eli Bendersky : ---------- nosy: +eli.bendersky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 13:42:20 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 15 Aug 2012 11:42:20 +0000 Subject: [issue11062] mailbox fails to round-trip a file to a Babyl mailbox In-Reply-To: <1296317976.28.0.825353703674.issue11062@psf.upfronthosting.co.za> Message-ID: <3Wxpgb0rKBzQ9T@mail.python.org> Roundup Robot added the comment: New changeset ad8c9725c041 by Petri Lehtinen in branch '2.7': #11062: Fix adding a message from file to Babyl mailbox http://hg.python.org/cpython/rev/ad8c9725c041 New changeset cbc1dc8cda06 by Petri Lehtinen in branch '3.2': #11062: Fix adding a message from file to Babyl mailbox http://hg.python.org/cpython/rev/cbc1dc8cda06 New changeset 7c8c6b905a18 by Petri Lehtinen in branch 'default': #11062: Fix adding a message from file to Babyl mailbox http://hg.python.org/cpython/rev/7c8c6b905a18 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 13:43:29 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Wed, 15 Aug 2012 11:43:29 +0000 Subject: [issue11062] mailbox fails to round-trip a file to a Babyl mailbox In-Reply-To: <1296317976.28.0.825353703674.issue11062@psf.upfronthosting.co.za> Message-ID: <1345031009.18.0.331249257116.issue11062@psf.upfronthosting.co.za> Changes by Petri Lehtinen : ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 13:44:00 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Wed, 15 Aug 2012 11:44:00 +0000 Subject: [issue11062] mailbox fails to round-trip a file to a Babyl mailbox In-Reply-To: <1296317976.28.0.825353703674.issue11062@psf.upfronthosting.co.za> Message-ID: <1345031040.17.0.0597837936436.issue11062@psf.upfronthosting.co.za> Changes by Petri Lehtinen : ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 13:52:27 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 15 Aug 2012 11:52:27 +0000 Subject: [issue15656] "Extending Python with C" page needs update for 3.x In-Reply-To: <1344970665.85.0.951420699824.issue15656@psf.upfronthosting.co.za> Message-ID: <3WxpvG4S07zQBV@mail.python.org> Roundup Robot added the comment: New changeset 599376deeeac by Eli Bendersky in branch '3.2': Issue #15656: fixing code sample in extending doc http://hg.python.org/cpython/rev/599376deeeac ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 13:53:25 2012 From: report at bugs.python.org (Eli Bendersky) Date: Wed, 15 Aug 2012 11:53:25 +0000 Subject: [issue15656] "Extending Python with C" page needs update for 3.x In-Reply-To: <1344970665.85.0.951420699824.issue15656@psf.upfronthosting.co.za> Message-ID: <1345031605.26.0.917910194217.issue15656@psf.upfronthosting.co.za> Eli Bendersky added the comment: Fixed, thanks for the report. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 14:01:06 2012 From: report at bugs.python.org (Eli Bendersky) Date: Wed, 15 Aug 2012 12:01:06 +0000 Subject: [issue15629] Run doctests in Doc/*.rst as part of regrtest In-Reply-To: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za> Message-ID: <1345032066.63.0.487233351032.issue15629@psf.upfronthosting.co.za> Eli Bendersky added the comment: I think implementing this is very important, and +1 to Georg's suggestion, because no one is suddenly going to convert KLOCs of code samples to be testable (many code samples are partial, and will need to be completed in one way or another to be actually runnable). However, do I understand correctly that this is blocked on #10224? ---------- nosy: +eli.bendersky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 14:10:28 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 15 Aug 2012 12:10:28 +0000 Subject: [issue15629] Run doctests in Doc/*.rst as part of regrtest In-Reply-To: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za> Message-ID: <1345032628.71.0.83052233245.issue15629@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I would like the chance to try implementing this without depending on Sphinx and "make doctest". I don't think it would take much work, and it would let us leverage and hook into regrtest's existing options (like test selection by name). I am also okay with exposing this via an option rather than including the doctests by default, which seemed to be the main concern expressed by others. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 14:42:56 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 15 Aug 2012 12:42:56 +0000 Subject: [issue15664] test_curses not run with 'make test' In-Reply-To: <1345026679.72.0.767220182308.issue15664@psf.upfronthosting.co.za> Message-ID: <1345034576.66.0.91160215564.issue15664@psf.upfronthosting.co.za> R. David Murray added the comment: So this should be closed as a duplicate of issue 12669? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 14:59:46 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 15 Aug 2012 12:59:46 +0000 Subject: [issue15664] test_curses not run with 'make test' In-Reply-To: <1345026679.72.0.767220182308.issue15664@psf.upfronthosting.co.za> Message-ID: <1345035586.89.0.464302145228.issue15664@psf.upfronthosting.co.za> Ronald Oussoren added the comment: Yes. I'll add a message to that issue to note that is also affects 'make test' ---------- resolution: -> duplicate stage: -> committed/rejected status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 15:01:07 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 15 Aug 2012 13:01:07 +0000 Subject: [issue12669] test_curses skipped on buildbots In-Reply-To: <1312149135.76.0.0319517534091.issue12669@psf.upfronthosting.co.za> Message-ID: <1345035667.08.0.696024019583.issue12669@psf.upfronthosting.co.za> Ronald Oussoren added the comment: As noted in Issue15664 this issue also affects "make test". ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 15:02:50 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 15 Aug 2012 13:02:50 +0000 Subject: [issue15543] central documentation for 'universal newlines' In-Reply-To: <1343953234.25.0.0555174882779.issue15543@psf.upfronthosting.co.za> Message-ID: <1345035770.94.0.342514459623.issue15543@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Here is the patch for 2.7. ---------- Added file: http://bugs.python.org/file26822/issue-15543-6-py27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 15:03:49 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 15 Aug 2012 13:03:49 +0000 Subject: [issue12669] test_curses skipped on buildbots In-Reply-To: <1312149135.76.0.0319517534091.issue12669@psf.upfronthosting.co.za> Message-ID: <1345035829.98.0.341893364398.issue12669@psf.upfronthosting.co.za> Ronald Oussoren added the comment: Nadeem: is the failure you show in msg141798 with a version of test_curses that uses pty.openpty? If it isn't: I'd expect more test failures on buildbot machines where the buildbot agent is started as a system daemon, in which case the process doesn't have a tty at all. Using pty.openpty it would be possible to ensure that there is a pty that can be used for the test. I'll work on a patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 15:06:03 2012 From: report at bugs.python.org (Robin Schreiber) Date: Wed, 15 Aug 2012 13:06:03 +0000 Subject: [issue15665] PEP 3121, 384 refactoring applied to lsprof module Message-ID: <1345035962.65.0.979590709355.issue15665@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the lsprof module! ---------- components: Extension Modules files: _lsprof_pep3121-384_v0.patch keywords: patch messages: 168292 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121, 384 refactoring applied to lsprof module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26823/_lsprof_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 15:24:14 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 15 Aug 2012 13:24:14 +0000 Subject: [issue12669] test_curses skipped on buildbots In-Reply-To: <1312149135.76.0.0319517534091.issue12669@psf.upfronthosting.co.za> Message-ID: <1345037054.89.0.638642828484.issue12669@psf.upfronthosting.co.za> Ronald Oussoren added the comment: BTW. the documentation for curses.setupterm says: curses.setupterm([termstr, fd]) The first argument is actually named "term" in the C code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 15:24:31 2012 From: report at bugs.python.org (Robin Schreiber) Date: Wed, 15 Aug 2012 13:24:31 +0000 Subject: [issue15666] PEP 3121, 384 refactoring applied to lzma module Message-ID: <1345037071.28.0.307240191092.issue15666@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the lzma module! ---------- components: Extension Modules files: _lzma_pep3121-384_v0.patch keywords: patch messages: 168294 nosy: Robin.Schreiber, nadeem.vawda priority: normal severity: normal status: open title: PEP 3121, 384 refactoring applied to lzma module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26824/_lzma_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 15:55:58 2012 From: report at bugs.python.org (Robin Schreiber) Date: Wed, 15 Aug 2012 13:55:58 +0000 Subject: [issue15667] PEP 3121, 384 refactoring applied to pickle module Message-ID: <1345038957.09.0.78094807427.issue15667@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the pickle module! ---------- components: Extension Modules files: _pickle_pep3121-384_v0.patch keywords: patch messages: 168295 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121, 384 refactoring applied to pickle module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26825/_pickle_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 16:04:46 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 15 Aug 2012 14:04:46 +0000 Subject: [issue15543] central documentation for 'universal newlines' In-Reply-To: <1343953234.25.0.0555174882779.issue15543@psf.upfronthosting.co.za> Message-ID: <1345039486.54.0.871551095629.issue15543@psf.upfronthosting.co.za> Changes by Chris Jerdonek : Added file: http://bugs.python.org/file26826/issue-15543-6-py32.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 16:08:32 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 15 Aug 2012 14:08:32 +0000 Subject: [issue15543] central documentation for 'universal newlines' In-Reply-To: <1343953234.25.0.0555174882779.issue15543@psf.upfronthosting.co.za> Message-ID: <1345039712.45.0.161870590169.issue15543@psf.upfronthosting.co.za> Chris Jerdonek added the comment: And here are the 3.2 patch and the 3.3 "delta" after forward-porting. Note that to forward-port the 3.2 patch to the default 3.3 branch, you can simply drop the changes to the file Doc/library/bz2.rst. I think that is the only conflict. ---------- Added file: http://bugs.python.org/file26827/issue-15543-6-py33-delta.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 16:10:37 2012 From: report at bugs.python.org (Robin Schreiber) Date: Wed, 15 Aug 2012 14:10:37 +0000 Subject: [issue15668] PEP 3121, 384 Refactoring applied to random module Message-ID: <1345039836.78.0.438193538839.issue15668@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the lsprof module! ---------- components: Extension Modules files: _random_pep3121-384_v0.patch keywords: patch messages: 168297 nosy: Robin.Schreiber, rhettinger priority: normal severity: normal status: open title: PEP 3121, 384 Refactoring applied to random module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26828/_random_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 16:18:53 2012 From: report at bugs.python.org (Robin Schreiber) Date: Wed, 15 Aug 2012 14:18:53 +0000 Subject: [issue15669] PEP 3121, 384 Refactoring applied to sre module Message-ID: <1345040333.3.0.897611485757.issue15669@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the sre module! ---------- components: Extension Modules files: _sre_pep3121-384_v0.patch keywords: patch messages: 168298 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121, 384 Refactoring applied to sre module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26829/_sre_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 16:25:02 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 15 Aug 2012 14:25:02 +0000 Subject: [issue15668] PEP 3121, 384 Refactoring applied to random module In-Reply-To: <1345039836.78.0.438193538839.issue15668@psf.upfronthosting.co.za> Message-ID: <1345040702.73.0.4087958572.issue15668@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Martin, does this patch match your intent with PEP3121 and PEP384? ---------- assignee: -> loewis nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 16:26:03 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 15 Aug 2012 14:26:03 +0000 Subject: [issue15643] Support OpenCSW in setup.py In-Reply-To: <1344896135.95.0.0625174180507.issue15643@psf.upfronthosting.co.za> Message-ID: <1345040763.29.0.430453794794.issue15643@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 16:30:30 2012 From: report at bugs.python.org (Robin Schreiber) Date: Wed, 15 Aug 2012 14:30:30 +0000 Subject: [issue15670] PEP 3121, 384 Refactoring applied to ssl module Message-ID: <1345041029.57.0.223670432026.issue15670@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the ssl module! ---------- components: Extension Modules files: _ssl_pep3121-384_v0.patch keywords: patch messages: 168300 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121, 384 Refactoring applied to ssl module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26830/_ssl_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 16:37:20 2012 From: report at bugs.python.org (Stefan Krah) Date: Wed, 15 Aug 2012 14:37:20 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1345041440.32.0.156872638536.issue15573@psf.upfronthosting.co.za> Stefan Krah added the comment: Here is a new patch that hopefully addresses all comments. ---------- Added file: http://bugs.python.org/file26831/issue15573-struct-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 16:42:59 2012 From: report at bugs.python.org (Robin Schreiber) Date: Wed, 15 Aug 2012 14:42:59 +0000 Subject: [issue15671] PEP 3121, 384 Refactoring applied to struct module Message-ID: <1345041779.43.0.428829398339.issue15671@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the struct module! ---------- components: Extension Modules files: _struct_pep3121-384_v0.patch keywords: patch messages: 168302 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121, 384 Refactoring applied to struct module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26832/_struct_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 16:48:28 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 15 Aug 2012 14:48:28 +0000 Subject: [issue15623] Init time relative imports no longer work from __init__.so modules In-Reply-To: <1344697325.25.0.880049566038.issue15623@psf.upfronthosting.co.za> Message-ID: <1345042108.83.0.443976857375.issue15623@psf.upfronthosting.co.za> Brett Cannon added the comment: I'm glad the work-around at least works, but I would still like to find out what the heck 3.2 is doing to see if it's reasonable to replicate in 3.3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 16:51:00 2012 From: report at bugs.python.org (Robin Schreiber) Date: Wed, 15 Aug 2012 14:51:00 +0000 Subject: [issue15672] PEP 3121, 384 Refactoring applied to testbuffer module Message-ID: <1345042259.48.0.277311619921.issue15672@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the testbuffer module! ---------- components: Extension Modules files: _testbuffer_pep3121-384_v0.patch keywords: patch messages: 168304 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121, 384 Refactoring applied to testbuffer module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26833/_testbuffer_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 16:51:37 2012 From: report at bugs.python.org (Robin Schreiber) Date: Wed, 15 Aug 2012 14:51:37 +0000 Subject: [issue15672] PEP 3121, 384 Refactoring applied to testbuffer module In-Reply-To: <1345042259.48.0.277311619921.issue15672@psf.upfronthosting.co.za> Message-ID: <1345042297.86.0.215238921212.issue15672@psf.upfronthosting.co.za> Changes by Robin Schreiber : ---------- nosy: +skrah -Robin.Schreiber _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 16:52:01 2012 From: report at bugs.python.org (Robin Schreiber) Date: Wed, 15 Aug 2012 14:52:01 +0000 Subject: [issue15672] PEP 3121, 384 Refactoring applied to testbuffer module In-Reply-To: <1345042259.48.0.277311619921.issue15672@psf.upfronthosting.co.za> Message-ID: <1345042321.08.0.380141158039.issue15672@psf.upfronthosting.co.za> Changes by Robin Schreiber : ---------- nosy: +Robin.Schreiber _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 16:58:29 2012 From: report at bugs.python.org (Robin Schreiber) Date: Wed, 15 Aug 2012 14:58:29 +0000 Subject: [issue15673] PEP 3121, 384 Refactoring applied to testcapi module Message-ID: <1345042709.67.0.745658134358.issue15673@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the testcapi module! ---------- components: Extension Modules files: _testcapi_pep3121-384_v0.patch keywords: patch messages: 168305 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121, 384 Refactoring applied to testcapi module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26834/_testcapi_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 17:06:23 2012 From: report at bugs.python.org (Robin Schreiber) Date: Wed, 15 Aug 2012 15:06:23 +0000 Subject: [issue15674] PEP 3121, 384 Refactoring applied to thread module Message-ID: <1345043183.1.0.612175209954.issue15674@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the thread module! ---------- components: Extension Modules files: _thread_pep3121-384_v0.patch keywords: patch messages: 168306 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121, 384 Refactoring applied to thread module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26835/_thread_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 17:13:47 2012 From: report at bugs.python.org (Robin Schreiber) Date: Wed, 15 Aug 2012 15:13:47 +0000 Subject: [issue15675] PEP 3121, 384 Refactoring applied to array module Message-ID: <1345043626.95.0.208765115861.issue15675@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the array module! ---------- components: Extension Modules files: array_pep3121-385_v0.patch keywords: patch messages: 168307 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121, 384 Refactoring applied to array module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26836/array_pep3121-385_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 17:23:53 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 15 Aug 2012 15:23:53 +0000 Subject: [issue15543] central documentation for 'universal newlines' In-Reply-To: <1343953234.25.0.0555174882779.issue15543@psf.upfronthosting.co.za> Message-ID: <3WxvbD3R16zPl5@mail.python.org> Roundup Robot added the comment: New changeset 273df9789796 by R David Murray in branch '3.2': #15543: glossary entry for and 'universal newlines', and links to it. http://hg.python.org/cpython/rev/273df9789796 New changeset e67042b6ad02 by R David Murray in branch '3.2': #15543: reflow paragraphs. http://hg.python.org/cpython/rev/e67042b6ad02 New changeset 04a0255de9b8 by R David Murray in branch 'default': Merge #15543: glossary entry for and 'universal newlines', and links to it. http://hg.python.org/cpython/rev/04a0255de9b8 New changeset 37df50bc4ea0 by R David Murray in branch 'default': #15543: additional link in subprocess docs. http://hg.python.org/cpython/rev/37df50bc4ea0 New changeset a2efe5eeb876 by R David Murray in branch 'default': #15543: reflow paragraph. http://hg.python.org/cpython/rev/a2efe5eeb876 New changeset 8795cd3b4c8c by R David Murray in branch '2.7': #15543: glossary entry for and 'universal newlines', and links to it. http://hg.python.org/cpython/rev/8795cd3b4c8c New changeset 35d8a638b0e2 by R David Murray in branch '2.7': #15543: reflow paragraphs. http://hg.python.org/cpython/rev/35d8a638b0e2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 17:25:03 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 15 Aug 2012 15:25:03 +0000 Subject: [issue15543] central documentation for 'universal newlines' In-Reply-To: <1343953234.25.0.0555174882779.issue15543@psf.upfronthosting.co.za> Message-ID: <1345044303.55.0.450147265558.issue15543@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks Chris. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 17:30:41 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 15 Aug 2012 15:30:41 +0000 Subject: [issue15543] central documentation for 'universal newlines' In-Reply-To: <1343953234.25.0.0555174882779.issue15543@psf.upfronthosting.co.za> Message-ID: <1345044641.8.0.636701327415.issue15543@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Good work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 17:30:45 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 15 Aug 2012 15:30:45 +0000 Subject: [issue15543] central documentation for 'universal newlines' In-Reply-To: <1343953234.25.0.0555174882779.issue15543@psf.upfronthosting.co.za> Message-ID: <1345044645.6.0.269655469006.issue15543@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Thanks, David! Also, can/did you check that reflows like these still link to the glossary correctly? + :func:`input` function to allow opening files in binary or :term:`universal + newlines` mode. Another new parameter, *openhook*, lets you use a function I tried to avoid breaking role markups like these to be safe ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 17:33:35 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 15 Aug 2012 15:33:35 +0000 Subject: [issue15543] central documentation for 'universal newlines' In-Reply-To: <1343953234.25.0.0555174882779.issue15543@psf.upfronthosting.co.za> Message-ID: <1345044815.05.0.532678069047.issue15543@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Yes, it is processed correctly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 19:25:04 2012 From: report at bugs.python.org (Stefan Krah) Date: Wed, 15 Aug 2012 17:25:04 +0000 Subject: [issue15625] Support u and w codes in memoryview In-Reply-To: <1344719787.86.0.485615026169.issue15625@psf.upfronthosting.co.za> Message-ID: <1345051504.76.0.71358066623.issue15625@psf.upfronthosting.co.za> Stefan Krah added the comment: Nick's comment in msg167963 got me thinking. Indeed, in Numpy the 'U' specifier is similar to the struct module's 's' format code, only for UCS4. So I'm questioning whether the current semantics of 'u' and 'w' used by array.array were ever intended by the PEP authors: import numpy >>> nd = numpy.array(["A", "B"], dtype='U') >>> nd array(['A', 'B'], dtype='>> nd.tostring() b'A\x00\x00\x00B\x00\x00\x00' >>> >>> nd = numpy.array(["ABC", "D"], dtype='U') >>> nd array(['ABC', 'D'], dtype='>> nd.tostring() b'A\x00\x00\x00B\x00\x00\x00C\x00\x00\x00D\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' >>> Internally, in NumPy 'U' is always UCS4, and the data type is a fixed length string that has the length of the longest initializer element. NumPy's use of 'U' seems vastly more useful for arrays than the behavior of array.array: >>> array.array('u', ['A', 'B']) array('u', 'AB') >>> array.array('u', ['ABC', 'D']) Traceback (most recent call last): File "", line 1, in TypeError: array item must be unicode character In Numpy, arrays of words are possible, with array.array they are not. An additional thought: The convention in the struct module is to use uppercase for unsigned types. So it would be a possibility to use 'C', 'U' and 'W', where '3C' would denote the same as '3s', except for UCS1 instead of bytes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 19:46:34 2012 From: report at bugs.python.org (Steven Willis) Date: Wed, 15 Aug 2012 17:46:34 +0000 Subject: [issue15676] mmap: add empty file check prior to offset check Message-ID: <1345052794.26.0.230448790651.issue15676@psf.upfronthosting.co.za> New submission from Steven Willis: There are a number of issues dealing with the offset and length checks in offset, such as issue12556. I'm running into this issue as well, but with a normal file that happens to be empty. I'm trying to access it with: mmap.mmap(f.fileno(), length=0, access=mmap.ACCESS_READ) So the length and offset should be calculated automatically. The man page for mmap says: "SUSv3 specifies that mmap() should fail if length is 0. However, in kernels before 2.6.12, mmap() succeeded in this case: no mapping was created and the call returned addr. Since kernel 2.6.12, mmap() fails with the error EINVAL for this case." So alright, mmapping an empty file is now allowed. But, could the check for an empty file be done prior to the check for the offset exceeding the size of the file? It would be much clearer in the cases where an empty (regular or otherwise) file was mmapped if the error message were something like "empty files cannot be mapped" insted of "offset is greater than file size" since I didn't even set the offset. ---------- components: Library (Lib) messages: 168314 nosy: Steven.Willis priority: normal severity: normal status: open title: mmap: add empty file check prior to offset check type: behavior versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 20:39:55 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 15 Aug 2012 18:39:55 +0000 Subject: [issue15643] Support OpenCSW in setup.py In-Reply-To: <1344896135.95.0.0625174180507.issue15643@psf.upfronthosting.co.za> Message-ID: <1345055995.44.0.252432432982.issue15643@psf.upfronthosting.co.za> Martin v. L?wis added the comment: LGTM. In the usual case, it is harmless if the system is no Solaris, or OpenCSW is not installed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 21:12:49 2012 From: report at bugs.python.org (Daniel Swanson) Date: Wed, 15 Aug 2012 19:12:49 +0000 Subject: [issue15346] Tkinter extention modules no documentation In-Reply-To: <1342198047.2.0.619885102312.issue15346@psf.upfronthosting.co.za> Message-ID: <1345057969.91.0.300261350219.issue15346@psf.upfronthosting.co.za> Daniel Swanson added the comment: For that matter, none of the following have docs: tkinter.colorchooser tkinter.commondialog tkinter.filedialog tkinter.font tkinter.messagebox tkinter.simpledialog tkinter.dnd Perhaps this should be remidied? One sentence usualy does not describe the use of an entire module. ---------- title: Tkinter dnd has no documentation -> Tkinter extention modules no documentation type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 21:13:23 2012 From: report at bugs.python.org (Daniel Swanson) Date: Wed, 15 Aug 2012 19:13:23 +0000 Subject: [issue15346] Tkinter extention modules have no documentation In-Reply-To: <1342198047.2.0.619885102312.issue15346@psf.upfronthosting.co.za> Message-ID: <1345058003.46.0.791142145145.issue15346@psf.upfronthosting.co.za> Changes by Daniel Swanson : ---------- title: Tkinter extention modules no documentation -> Tkinter extention modules have no documentation _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 21:19:24 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 15 Aug 2012 19:19:24 +0000 Subject: [issue12623] "universal newlines" subprocess support broken with select- and poll-based communicate() In-Reply-To: <1311451893.22.0.0169745025507.issue12623@psf.upfronthosting.co.za> Message-ID: <1345058364.57.0.712893708896.issue12623@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Antoine, can you explain why subprocess support for universal_newlines is broken? As I can see tests for universal_newlines passed and these looks correct. In general I like your idea to get rid of os.write, but maybe that patch should be landed in 3.4? If not ? I will prepare fix ASAP. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 21:27:16 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 15 Aug 2012 19:27:16 +0000 Subject: [issue15625] Support u and w codes in memoryview In-Reply-To: <1344719787.86.0.485615026169.issue15625@psf.upfronthosting.co.za> Message-ID: <1345058836.7.0.796265971147.issue15625@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Travis: can you please comment on what the intended semantics of the 'u' and 'w' specifiers is, in PEP 3118? More specifically: - "an array/memoryview with format 'u' can support exactly one-character values (i.e. unicode strings of length 1)": true or false? - "in a struct, an element of type 'u' will use up two bytes exactly (ignoring padding)": true or false? ---------- nosy: +teoliphant _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 21:34:15 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 15 Aug 2012 19:34:15 +0000 Subject: [issue15656] "Extending Python with C" page needs update for 3.x In-Reply-To: <1344970665.85.0.951420699824.issue15656@psf.upfronthosting.co.za> Message-ID: <1345059255.09.0.989142272219.issue15656@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 21:35:51 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 15 Aug 2012 19:35:51 +0000 Subject: [issue15656] "Extending Python with C" page needs update for 3.x In-Reply-To: <1344970665.85.0.951420699824.issue15656@psf.upfronthosting.co.za> Message-ID: <1345059351.87.0.678713688739.issue15656@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Should this be applied to "default" (3.3) too? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 21:38:32 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 15 Aug 2012 19:38:32 +0000 Subject: [issue12623] "universal newlines" subprocess support broken with select- and poll-based communicate() In-Reply-To: <1311451893.22.0.0169745025507.issue12623@psf.upfronthosting.co.za> Message-ID: <1345059512.74.0.62130558044.issue12623@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Andrew, I'm not sure if this is the issue, but it seems like the only tests in which input is passed to communicate() with universal newlines is when stdin is the only PIPE, i.e.: def test_universal_newlines_communicate_stdin(self): # universal newlines through communicate(), with only stdin IIRC, the select() and poll() implementations are only called when at least two of the streams are PIPE (like in the new input_none test I added recently). Have you tried passing input to communicate() with at least two pipes (e.g. stdin and stdout)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 21:40:16 2012 From: report at bugs.python.org (Sandro Tosi) Date: Wed, 15 Aug 2012 19:40:16 +0000 Subject: [issue15656] "Extending Python with C" page needs update for 3.x In-Reply-To: <1344970665.85.0.951420699824.issue15656@psf.upfronthosting.co.za> Message-ID: <1345059616.8.0.758940164798.issue15656@psf.upfronthosting.co.za> Sandro Tosi added the comment: It's fixed in default too: http://hg.python.org/cpython/rev/f46b4b7b817c It was not shown because the commit message misses the issue reference. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 21:45:40 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 15 Aug 2012 19:45:40 +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: <1345059940.24.7.0233555779e-05.issue15661@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 21:51:46 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 15 Aug 2012 19:51:46 +0000 Subject: [issue12623] "universal newlines" subprocess support broken with select- and poll-based communicate() In-Reply-To: <1311451893.22.0.0169745025507.issue12623@psf.upfronthosting.co.za> Message-ID: <1345060306.77.0.466354527268.issue12623@psf.upfronthosting.co.za> Antoine Pitrou added the comment: As Chris said. Look at the POSIX version of _communicate(), nowhere is input given the newlines/encoding treatment. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 22:06:08 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 15 Aug 2012 20:06:08 +0000 Subject: [issue15676] mmap: add empty file check prior to offset check In-Reply-To: <1345052794.26.0.230448790651.issue15676@psf.upfronthosting.co.za> Message-ID: <1345061168.02.0.6769137907.issue15676@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 22:08:15 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 15 Aug 2012 20:08:15 +0000 Subject: [issue15676] mmap: add empty file check prior to offset check In-Reply-To: <1345052794.26.0.230448790651.issue15676@psf.upfronthosting.co.za> Message-ID: <1345061295.57.0.394540847708.issue15676@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: I do agree. Solaris also returns an error if len=0. Could you please, provide patches for 2.7, 3.2 and 3.3? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 22:10:16 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 15 Aug 2012 20:10:16 +0000 Subject: [issue11062] mailbox fails to round-trip a file to a Babyl mailbox In-Reply-To: <1296317976.28.0.825353703674.issue11062@psf.upfronthosting.co.za> Message-ID: <1345061416.96.0.585408934124.issue11062@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Reopen the issue because Windows tests is failed. Commits for this issue breaks Windows buildbot for 3.2 and 3.3. Looks like problem is: Windows os.linesep different than Unix. I don't know what format expected by protocol. ---------- nosy: +asvetlov status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 22:18:50 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 15 Aug 2012 20:18:50 +0000 Subject: [issue12623] "universal newlines" subprocess support broken with select- and poll-based communicate() In-Reply-To: <1311451893.22.0.0169745025507.issue12623@psf.upfronthosting.co.za> Message-ID: <1345061930.82.0.0175258229102.issue12623@psf.upfronthosting.co.za> Andrew Svetlov added the comment: I've pushed test for piping stdin, stdout and and stderr: 4af2c0687970 What other test we should to add? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 22:19:32 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Wed, 15 Aug 2012 20:19:32 +0000 Subject: [issue11062] mailbox fails to round-trip a file to a Babyl mailbox In-Reply-To: <1296317976.28.0.825353703674.issue11062@psf.upfronthosting.co.za> Message-ID: <1345061972.27.0.133958618424.issue11062@psf.upfronthosting.co.za> Petri Lehtinen added the comment: Yeah. Enabling the Babyl tests discovered yet another bug on a code path that wasn't excercised at all. I'll fix it. ---------- assignee: -> petri.lehtinen resolution: fixed -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 22:20:51 2012 From: report at bugs.python.org (Nadeem Vawda) Date: Wed, 15 Aug 2012 20:20:51 +0000 Subject: [issue15666] PEP 3121, 384 refactoring applied to lzma module In-Reply-To: <1345037071.28.0.307240191092.issue15666@psf.upfronthosting.co.za> Message-ID: <1345062051.22.0.682173598881.issue15666@psf.upfronthosting.co.za> Nadeem Vawda added the comment: Thanks for the patch. Unfortunately I don't have much free time at the moment, so it might be a few weeks before I get a chance to review it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 22:23:39 2012 From: report at bugs.python.org (Nadeem Vawda) Date: Wed, 15 Aug 2012 20:23:39 +0000 Subject: [issue15664] test_curses not run with 'make test' In-Reply-To: <1345026679.72.0.767220182308.issue15664@psf.upfronthosting.co.za> Message-ID: <1345062219.17.0.760765701873.issue15664@psf.upfronthosting.co.za> Changes by Nadeem Vawda : ---------- superseder: -> test_curses skipped on buildbots _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 22:26:04 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 15 Aug 2012 20:26:04 +0000 Subject: [issue12623] "universal newlines" subprocess support broken with select- and poll-based communicate() In-Reply-To: <1311451893.22.0.0169745025507.issue12623@psf.upfronthosting.co.za> Message-ID: <1345062364.43.0.917215694005.issue12623@psf.upfronthosting.co.za> Andrew Svetlov added the comment: ???. I see. Pushing to communicate input with "\r" (see attached patch) produces the error. Will work on fixing. Thanks. ---------- keywords: +patch Added file: http://bugs.python.org/file26837/issue12623_failing_test.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 22:30:24 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 15 Aug 2012 20:30:24 +0000 Subject: [issue12623] "universal newlines" subprocess support broken with select- and poll-based communicate() In-Reply-To: <1311451893.22.0.0169745025507.issue12623@psf.upfronthosting.co.za> Message-ID: <1345062624.1.0.966936890136.issue12623@psf.upfronthosting.co.za> Andrew Svetlov added the comment: I like to set status for the issue to "Release blocker" if Georg Brandl agree with that. ---------- nosy: +georg.brandl priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 22:32:44 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 15 Aug 2012 20:32:44 +0000 Subject: [issue12623] "universal newlines" subprocess support broken with select- and poll-based communicate() In-Reply-To: <1311451893.22.0.0169745025507.issue12623@psf.upfronthosting.co.za> Message-ID: <1345062764.53.0.579529708659.issue12623@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > ???. I see. Pushing to communicate input with "\r" (see attached patch) > produces the error. Hmm, no, it's the reverse. Pushing input with "\n" should produce b"\r\n" on the other side, under Windows. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 22:33:17 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 15 Aug 2012 20:33:17 +0000 Subject: [issue12623] "universal newlines" subprocess support broken with select- and poll-based communicate() In-Reply-To: <1311451893.22.0.0169745025507.issue12623@psf.upfronthosting.co.za> Message-ID: <1345062797.16.0.984960283123.issue12623@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Well, it's not a regression and it may be slightly delicate, so I don't think it should be a release blocker. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 22:35:23 2012 From: report at bugs.python.org (Sandro Tosi) Date: Wed, 15 Aug 2012 20:35:23 +0000 Subject: [issue15677] Gzip/zlib allows for compression level=0 Message-ID: <1345062923.32.0.954619584637.issue15677@psf.upfronthosting.co.za> New submission from Sandro Tosi: As reported at http://mail.python.org/pipermail/docs/2012-August/009837.html gzip/zlib allows for a compression level=0 (that's basically no compression) so the documentation should mention that possibility too. ---------- assignee: docs at python components: Documentation messages: 168332 nosy: docs at python, sandro.tosi priority: normal severity: normal stage: needs patch status: open title: Gzip/zlib allows for compression level=0 versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 22:36:08 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 15 Aug 2012 20:36:08 +0000 Subject: [issue12623] "universal newlines" subprocess support broken with select- and poll-based communicate() In-Reply-To: <1311451893.22.0.0169745025507.issue12623@psf.upfronthosting.co.za> Message-ID: <1345062968.92.0.464447712335.issue12623@psf.upfronthosting.co.za> Andrew Svetlov added the comment: The main question: can be fix applied to 3.3 or it can wait for 3.4? 3.2 has the same problem BTW. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 22:36:24 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 15 Aug 2012 20:36:24 +0000 Subject: [issue15390] PEP 3121, 384 refactoring applied to datetime module In-Reply-To: <1345020623.41.0.301893024126.issue15390@psf.upfronthosting.co.za> Message-ID: <1345062808.3393.5.camel@localhost.localdomain> Antoine Pitrou added the comment: > However we have yet to find a solution for the decref inside the dealloc methods. Perhaps ask for advice on python-dev? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 22:38:29 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 15 Aug 2012 20:38:29 +0000 Subject: [issue12623] "universal newlines" subprocess support broken with select- and poll-based communicate() In-Reply-To: <1311451893.22.0.0169745025507.issue12623@psf.upfronthosting.co.za> Message-ID: <1345063109.29.0.618404854557.issue12623@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > Pushing to communicate input with "\r" (see attached patch) produces the error. Is this a supported use case? In universal newlines, stdin line endings are supposed to be "\n". From the subprocess documentation: "For stdin, line ending characters '\n' in the input will be converted to the default line separator os.linesep." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 22:43:30 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 15 Aug 2012 20:43:30 +0000 Subject: [issue12623] "universal newlines" subprocess support broken with select- and poll-based communicate() In-Reply-To: <1311451893.22.0.0169745025507.issue12623@psf.upfronthosting.co.za> Message-ID: <1345063410.56.0.722721852265.issue12623@psf.upfronthosting.co.za> Andrew Svetlov added the comment: The real test should to put '\n' and subprocess should get '\r\n', right? Looking the code this test will fail on Windows. I cannot check it just now but looks like this is the problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 22:56:03 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Aug 2012 20:56:03 +0000 Subject: [issue15604] PyObject_IsTrue failure checks In-Reply-To: <201208150044.47845.storchaka@gmail.com> Message-ID: <201208152355.24330.storchaka@gmail.com> Serhiy Storchaka added the comment: Patches updated again. ---------- Added file: http://bugs.python.org/file26838/istrue_check-3.3_3.patch Added file: http://bugs.python.org/file26839/istrue_check-3.2_3.patch Added file: http://bugs.python.org/file26840/istrue_check-2.7_3.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 5dc2b4a542f1 Modules/_csv.c --- a/Modules/_csv.c Wed Aug 15 22:53:56 2012 +0300 +++ b/Modules/_csv.c Wed Aug 15 23:48:49 2012 +0300 @@ -196,8 +196,12 @@ { if (src == NULL) *target = dflt; - else - *target = PyObject_IsTrue(src); + else { + int b = PyObject_IsTrue(src); + if (b < 0) + return -1; + *target = b; + } return 0; } diff -r 5dc2b4a542f1 Modules/_io/textio.c --- a/Modules/_io/textio.c Wed Aug 15 22:53:56 2012 +0300 +++ b/Modules/_io/textio.c Wed Aug 15 23:48:49 2012 +0300 @@ -1056,8 +1056,11 @@ res = _PyObject_CallMethodId(buffer, &PyId_seekable, NULL); if (res == NULL) goto error; - self->seekable = self->telling = PyObject_IsTrue(res); + r = PyObject_IsTrue(res); Py_DECREF(res); + if (r < 0) + goto error; + self->seekable = self->telling = r; self->has_read1 = _PyObject_HasAttrId(buffer, &PyId_read1); diff -r 5dc2b4a542f1 Modules/_posixsubprocess.c --- a/Modules/_posixsubprocess.c Wed Aug 15 22:53:56 2012 +0300 +++ b/Modules/_posixsubprocess.c Wed Aug 15 23:48:49 2012 +0300 @@ -503,7 +503,7 @@ subprocess_fork_exec(PyObject* self, PyObject *args) { PyObject *gc_module = NULL; - PyObject *executable_list, *py_close_fds, *py_fds_to_keep; + PyObject *executable_list, *py_fds_to_keep; PyObject *env_list, *preexec_fn; PyObject *process_args, *converted_args = NULL, *fast_args = NULL; PyObject *preexec_fn_args_tuple = NULL; @@ -518,15 +518,14 @@ Py_ssize_t arg_num; if (!PyArg_ParseTuple( - args, "OOOOOOiiiiiiiiiiO:fork_exec", - &process_args, &executable_list, &py_close_fds, &py_fds_to_keep, + args, "OOpOOOiiiiiiiiiiO:fork_exec", + &process_args, &executable_list, &close_fds, &py_fds_to_keep, &cwd_obj, &env_list, &p2cread, &p2cwrite, &c2pread, &c2pwrite, &errread, &errwrite, &errpipe_read, &errpipe_write, &restore_signals, &call_setsid, &preexec_fn)) return NULL; - close_fds = PyObject_IsTrue(py_close_fds); if (close_fds && errpipe_write < 3) { /* precondition */ PyErr_SetString(PyExc_ValueError, "errpipe_write must be >= 3"); return NULL; diff -r 5dc2b4a542f1 Modules/_ssl.c --- a/Modules/_ssl.c Wed Aug 15 22:53:56 2012 +0300 +++ b/Modules/_ssl.c Wed Aug 15 23:48:49 2012 +0300 @@ -1037,15 +1037,15 @@ PyObject *retval = NULL; int len; int verification; - PyObject *binary_mode = Py_None; + int binary_mode = 0; - if (!PyArg_ParseTuple(args, "|O:peer_certificate", &binary_mode)) + if (!PyArg_ParseTuple(args, "|p:peer_certificate", &binary_mode)) return NULL; if (!self->peer_cert) Py_RETURN_NONE; - if (PyObject_IsTrue(binary_mode)) { + if (binary_mode) { /* return cert in DER-encoded format */ unsigned char *bytes_buf = NULL; diff -r 5dc2b4a542f1 Modules/itertoolsmodule.c --- a/Modules/itertoolsmodule.c Wed Aug 15 22:53:56 2012 +0300 +++ b/Modules/itertoolsmodule.c Wed Aug 15 23:48:49 2012 +0300 @@ -1105,11 +1105,13 @@ } ok = PyObject_IsTrue(good); Py_DECREF(good); - if (!ok) { + if (ok == 0) { lz->start = 1; return item; } Py_DECREF(item); + if (ok < 0) + return NULL; } } @@ -1124,7 +1126,7 @@ dropwhile_setstate(dropwhileobject *lz, PyObject *state) { int start = PyObject_IsTrue(state); - if (start == -1) + if (start < 0) return NULL; lz->start = start; Py_RETURN_NONE; @@ -1270,10 +1272,11 @@ } ok = PyObject_IsTrue(good); Py_DECREF(good); - if (ok) + if (ok == 1) return item; Py_DECREF(item); - lz->stop = 1; + if (ok == 0) + lz->stop = 1; return NULL; } @@ -1288,7 +1291,7 @@ takewhile_reduce_setstate(takewhileobject *lz, PyObject *state) { int stop = PyObject_IsTrue(state); - if (stop == -1) + if (stop < 0) return NULL; lz->stop = stop; Py_RETURN_NONE; @@ -3536,7 +3539,7 @@ if (ok == 1) return datum; Py_DECREF(datum); - if (ok == -1) + if (ok < 0) return NULL; } } @@ -3692,9 +3695,11 @@ ok = PyObject_IsTrue(good); Py_DECREF(good); } - if (!ok) + if (ok == 0) return item; Py_DECREF(item); + if (ok < 0) + return NULL; } } diff -r 5dc2b4a542f1 Modules/parsermodule.c --- a/Modules/parsermodule.c Wed Aug 15 22:53:56 2012 +0300 +++ b/Modules/parsermodule.c Wed Aug 15 23:48:49 2012 +0300 @@ -382,36 +382,28 @@ static PyObject* parser_st2tuple(PyST_Object *self, PyObject *args, PyObject *kw) { - PyObject *line_option = 0; - PyObject *col_option = 0; + int line_info = 0; + int col_info = 0; PyObject *res = 0; int ok; static char *keywords[] = {"st", "line_info", "col_info", NULL}; if (self == NULL || PyModule_Check(self)) { - ok = PyArg_ParseTupleAndKeywords(args, kw, "O!|OO:st2tuple", keywords, - &PyST_Type, &self, &line_option, - &col_option); + ok = PyArg_ParseTupleAndKeywords(args, kw, "O!|pp:st2tuple", keywords, + &PyST_Type, &self, &line_info, + &col_info); } else - ok = PyArg_ParseTupleAndKeywords(args, kw, "|OO:totuple", &keywords[1], - &line_option, &col_option); + ok = PyArg_ParseTupleAndKeywords(args, kw, "|pp:totuple", &keywords[1], + &line_info, &col_info); if (ok != 0) { - int lineno = 0; - int col_offset = 0; - if (line_option != NULL) { - lineno = (PyObject_IsTrue(line_option) != 0) ? 1 : 0; - } - if (col_option != NULL) { - col_offset = (PyObject_IsTrue(col_option) != 0) ? 1 : 0; - } /* * Convert ST into a tuple representation. Use Guido's function, * since it's known to work already. */ res = node2tuple(((PyST_Object*)self)->st_node, - PyTuple_New, PyTuple_SetItem, lineno, col_offset); + PyTuple_New, PyTuple_SetItem, line_info, col_info); } return (res); } @@ -426,35 +418,27 @@ static PyObject* parser_st2list(PyST_Object *self, PyObject *args, PyObject *kw) { - PyObject *line_option = 0; - PyObject *col_option = 0; + int line_info = 0; + int col_info = 0; PyObject *res = 0; int ok; static char *keywords[] = {"st", "line_info", "col_info", NULL}; if (self == NULL || PyModule_Check(self)) - ok = PyArg_ParseTupleAndKeywords(args, kw, "O!|OO:st2list", keywords, - &PyST_Type, &self, &line_option, - &col_option); + ok = PyArg_ParseTupleAndKeywords(args, kw, "O!|pp:st2list", keywords, + &PyST_Type, &self, &line_info, + &col_info); else - ok = PyArg_ParseTupleAndKeywords(args, kw, "|OO:tolist", &keywords[1], - &line_option, &col_option); + ok = PyArg_ParseTupleAndKeywords(args, kw, "|pp:tolist", &keywords[1], + &line_info, &col_info); if (ok) { - int lineno = 0; - int col_offset = 0; - if (line_option != 0) { - lineno = PyObject_IsTrue(line_option) ? 1 : 0; - } - if (col_option != NULL) { - col_offset = (PyObject_IsTrue(col_option) != 0) ? 1 : 0; - } /* * Convert ST into a tuple representation. Use Guido's function, * since it's known to work already. */ res = node2tuple(self->st_node, - PyList_New, PyList_SetItem, lineno, col_offset); + PyList_New, PyList_SetItem, line_info, col_info); } return (res); } diff -r 5dc2b4a542f1 Modules/pyexpat.c --- a/Modules/pyexpat.c Wed Aug 15 22:53:56 2012 +0300 +++ b/Modules/pyexpat.c Wed Aug 15 23:48:49 2012 +0300 @@ -1033,14 +1033,11 @@ static PyObject * xmlparse_UseForeignDTD(xmlparseobject *self, PyObject *args) { - PyObject *flagobj = NULL; - XML_Bool flag = XML_TRUE; + int flag = 1; enum XML_Error rc; - if (!PyArg_UnpackTuple(args, "UseForeignDTD", 0, 1, &flagobj)) + if (!PyArg_ParseTuple(args, "p:UseForeignDTD", &flag)) return NULL; - if (flagobj != NULL) - flag = PyObject_IsTrue(flagobj) ? XML_TRUE : XML_FALSE; - rc = XML_UseForeignDTD(self->itself, flag); + rc = XML_UseForeignDTD(self->itself, flag ? XML_TRUE : XML_FALSE); if (rc != XML_ERROR_NONE) { return set_error(self, rc); } @@ -1405,7 +1402,10 @@ } assert(PyUnicode_Check(name)); if (PyUnicode_CompareWithASCIIString(name, "buffer_text") == 0) { - if (PyObject_IsTrue(v)) { + int b = PyObject_IsTrue(v); + if (b < 0) + return -1; + if (b) { if (self->buffer == NULL) { self->buffer = malloc(self->buffer_size); if (self->buffer == NULL) { @@ -1424,25 +1424,25 @@ return 0; } if (PyUnicode_CompareWithASCIIString(name, "namespace_prefixes") == 0) { - if (PyObject_IsTrue(v)) - self->ns_prefixes = 1; - else - self->ns_prefixes = 0; + int b = PyObject_IsTrue(v); + if (b < 0) + return -1; + self->ns_prefixes = b; XML_SetReturnNSTriplet(self->itself, self->ns_prefixes); return 0; } if (PyUnicode_CompareWithASCIIString(name, "ordered_attributes") == 0) { - if (PyObject_IsTrue(v)) - self->ordered_attributes = 1; - else - self->ordered_attributes = 0; + int b = PyObject_IsTrue(v); + if (b < 0) + return -1; + self->ordered_attributes = b; return 0; } if (PyUnicode_CompareWithASCIIString(name, "specified_attributes") == 0) { - if (PyObject_IsTrue(v)) - self->specified_attributes = 1; - else - self->specified_attributes = 0; + int b = PyObject_IsTrue(v); + if (b < 0) + return -1; + self->specified_attributes = b; return 0; } diff -r 5dc2b4a542f1 Objects/typeobject.c --- a/Objects/typeobject.c Wed Aug 15 22:53:56 2012 +0300 +++ b/Objects/typeobject.c Wed Aug 15 23:48:49 2012 +0300 @@ -383,11 +383,15 @@ abc.ABCMeta.__new__, so this function doesn't do anything special to update subclasses. */ - int res; + int abstract, res; if (value != NULL) { + abstract = PyObject_IsTrue(value); + if (abstract < 0) + return -1; res = PyDict_SetItemString(type->tp_dict, "__abstractmethods__", value); } else { + abstract = 0; res = PyDict_DelItemString(type->tp_dict, "__abstractmethods__"); if (res && PyErr_ExceptionMatches(PyExc_KeyError)) { PyErr_SetString(PyExc_AttributeError, "__abstractmethods__"); @@ -396,12 +400,10 @@ } if (res == 0) { PyType_Modified(type); - if (value && PyObject_IsTrue(value)) { + if (abstract) type->tp_flags |= Py_TPFLAGS_IS_ABSTRACT; - } - else { + else type->tp_flags &= ~Py_TPFLAGS_IS_ABSTRACT; - } } return res; } diff -r 5dc2b4a542f1 Python/bltinmodule.c --- a/Python/bltinmodule.c Wed Aug 15 22:53:56 2012 +0300 +++ b/Python/bltinmodule.c Wed Aug 15 23:48:49 2012 +0300 @@ -429,9 +429,11 @@ ok = PyObject_IsTrue(good); Py_DECREF(good); } - if (ok) + if (ok > 0) return item; Py_DECREF(item); + if (ok < 0) + return NULL; } } -------------- next part -------------- diff -r 84899daa4309 Modules/_csv.c --- a/Modules/_csv.c Tue Aug 14 18:41:40 2012 +0300 +++ b/Modules/_csv.c Wed Aug 15 23:52:31 2012 +0300 @@ -166,8 +166,12 @@ { if (src == NULL) *target = dflt; - else - *target = PyObject_IsTrue(src); + else { + int b = PyObject_IsTrue(src); + if (b < 0) + return -1; + *target = b; + } return 0; } diff -r 84899daa4309 Modules/_io/textio.c --- a/Modules/_io/textio.c Tue Aug 14 18:41:40 2012 +0300 +++ b/Modules/_io/textio.c Wed Aug 15 23:52:31 2012 +0300 @@ -1046,8 +1046,11 @@ res = PyObject_CallMethod(buffer, "seekable", NULL); if (res == NULL) goto error; - self->seekable = self->telling = PyObject_IsTrue(res); + r = PyObject_IsTrue(res); Py_DECREF(res); + if (r < 0) + goto error; + self->seekable = self->telling = r; self->has_read1 = PyObject_HasAttrString(buffer, "read1"); diff -r 84899daa4309 Modules/_posixsubprocess.c --- a/Modules/_posixsubprocess.c Tue Aug 14 18:41:40 2012 +0300 +++ b/Modules/_posixsubprocess.c Wed Aug 15 23:52:31 2012 +0300 @@ -525,6 +525,8 @@ return NULL; close_fds = PyObject_IsTrue(py_close_fds); + if (close_fds < 0) + return NULL; if (close_fds && errpipe_write < 3) { /* precondition */ PyErr_SetString(PyExc_ValueError, "errpipe_write must be >= 3"); return NULL; diff -r 84899daa4309 Modules/_ssl.c --- a/Modules/_ssl.c Tue Aug 14 18:41:40 2012 +0300 +++ b/Modules/_ssl.c Wed Aug 15 23:52:31 2012 +0300 @@ -883,6 +883,7 @@ int len; int verification; PyObject *binary_mode = Py_None; + int b; if (!PyArg_ParseTuple(args, "|O:peer_certificate", &binary_mode)) return NULL; @@ -890,7 +891,10 @@ if (!self->peer_cert) Py_RETURN_NONE; - if (PyObject_IsTrue(binary_mode)) { + b = PyObject_IsTrue(binary_mode); + if (b < 0) + return NULL; + if (b) { /* return cert in DER-encoded format */ unsigned char *bytes_buf = NULL; diff -r 84899daa4309 Modules/itertoolsmodule.c --- a/Modules/itertoolsmodule.c Tue Aug 14 18:41:40 2012 +0300 +++ b/Modules/itertoolsmodule.c Wed Aug 15 23:52:31 2012 +0300 @@ -903,11 +903,13 @@ } ok = PyObject_IsTrue(good); Py_DECREF(good); - if (!ok) { + if (ok == 0) { lz->start = 1; return item; } Py_DECREF(item); + if (ok < 0) + return NULL; } } @@ -1043,10 +1045,11 @@ } ok = PyObject_IsTrue(good); Py_DECREF(good); - if (ok) + if (ok > 0) return item; Py_DECREF(item); - lz->stop = 1; + if (ok == 0) + lz->stop = 1; return NULL; } @@ -2959,9 +2962,11 @@ ok = PyObject_IsTrue(good); Py_DECREF(good); } - if (!ok) + if (ok == 0) return item; Py_DECREF(item); + if (ok < 0) + return NULL; } } diff -r 84899daa4309 Modules/parsermodule.c --- a/Modules/parsermodule.c Tue Aug 14 18:41:40 2012 +0300 +++ b/Modules/parsermodule.c Wed Aug 15 23:52:31 2012 +0300 @@ -401,10 +401,14 @@ int lineno = 0; int col_offset = 0; if (line_option != NULL) { - lineno = (PyObject_IsTrue(line_option) != 0) ? 1 : 0; + lineno = PyObject_IsTrue(line_option); + if (lineno < 0) + return NULL; } if (col_option != NULL) { - col_offset = (PyObject_IsTrue(col_option) != 0) ? 1 : 0; + col_offset = PyObject_IsTrue(col_option); + if (col_offset < 0) + return NULL; } /* * Convert ST into a tuple representation. Use Guido's function, @@ -444,10 +448,14 @@ int lineno = 0; int col_offset = 0; if (line_option != 0) { - lineno = PyObject_IsTrue(line_option) ? 1 : 0; + lineno = PyObject_IsTrue(line_option); + if (lineno < 0) + return NULL; } - if (col_option != NULL) { - col_offset = (PyObject_IsTrue(col_option) != 0) ? 1 : 0; + if (col_option != 0) { + col_offset = PyObject_IsTrue(col_option); + if (col_offset < 0) + return NULL; } /* * Convert ST into a tuple representation. Use Guido's function, diff -r 84899daa4309 Modules/pyexpat.c --- a/Modules/pyexpat.c Tue Aug 14 18:41:40 2012 +0300 +++ b/Modules/pyexpat.c Wed Aug 15 23:52:31 2012 +0300 @@ -1033,13 +1033,16 @@ xmlparse_UseForeignDTD(xmlparseobject *self, PyObject *args) { PyObject *flagobj = NULL; - XML_Bool flag = XML_TRUE; + int flag = 1; enum XML_Error rc; - if (!PyArg_UnpackTuple(args, "UseForeignDTD", 0, 1, &flagobj)) + if (!PyArg_ParseTuple(args, "O:UseForeignDTD", &flagobj)) return NULL; - if (flagobj != NULL) - flag = PyObject_IsTrue(flagobj) ? XML_TRUE : XML_FALSE; - rc = XML_UseForeignDTD(self->itself, flag); + if (flagobj != NULL) { + flag = PyObject_IsTrue(flagobj); + if (flag < 0) + return NULL; + } + rc = XML_UseForeignDTD(self->itself, flag ? XML_TRUE : XML_FALSE); if (rc != XML_ERROR_NONE) { return set_error(self, rc); } @@ -1397,7 +1400,10 @@ } assert(PyUnicode_Check(name)); if (PyUnicode_CompareWithASCIIString(name, "buffer_text") == 0) { - if (PyObject_IsTrue(v)) { + int b = PyObject_IsTrue(v); + if (b < 0) + return -1; + if (b) { if (self->buffer == NULL) { self->buffer = malloc(self->buffer_size); if (self->buffer == NULL) { @@ -1416,25 +1422,25 @@ return 0; } if (PyUnicode_CompareWithASCIIString(name, "namespace_prefixes") == 0) { - if (PyObject_IsTrue(v)) - self->ns_prefixes = 1; - else - self->ns_prefixes = 0; + int b = PyObject_IsTrue(v); + if (b < 0) + return -1; + self->ns_prefixes = b; XML_SetReturnNSTriplet(self->itself, self->ns_prefixes); return 0; } if (PyUnicode_CompareWithASCIIString(name, "ordered_attributes") == 0) { - if (PyObject_IsTrue(v)) - self->ordered_attributes = 1; - else - self->ordered_attributes = 0; + int b = PyObject_IsTrue(v); + if (b < 0) + return -1; + self->ordered_attributes = b; return 0; } if (PyUnicode_CompareWithASCIIString(name, "specified_attributes") == 0) { - if (PyObject_IsTrue(v)) - self->specified_attributes = 1; - else - self->specified_attributes = 0; + int b = PyObject_IsTrue(v); + if (b < 0) + return -1; + self->specified_attributes = b; return 0; } diff -r 84899daa4309 Objects/typeobject.c --- a/Objects/typeobject.c Tue Aug 14 18:41:40 2012 +0300 +++ b/Objects/typeobject.c Wed Aug 15 23:52:31 2012 +0300 @@ -340,11 +340,15 @@ abc.ABCMeta.__new__, so this function doesn't do anything special to update subclasses. */ - int res; + int abstract, res; if (value != NULL) { + abstract = PyObject_IsTrue(value); + if (abstract < 0) + return -1; res = PyDict_SetItemString(type->tp_dict, "__abstractmethods__", value); } else { + abstract = 0; res = PyDict_DelItemString(type->tp_dict, "__abstractmethods__"); if (res && PyErr_ExceptionMatches(PyExc_KeyError)) { PyErr_SetString(PyExc_AttributeError, "__abstractmethods__"); @@ -353,12 +357,10 @@ } if (res == 0) { PyType_Modified(type); - if (value && PyObject_IsTrue(value)) { + if (abstract) type->tp_flags |= Py_TPFLAGS_IS_ABSTRACT; - } - else { + else type->tp_flags &= ~Py_TPFLAGS_IS_ABSTRACT; - } } return res; } diff -r 84899daa4309 Python/bltinmodule.c --- a/Python/bltinmodule.c Tue Aug 14 18:41:40 2012 +0300 +++ b/Python/bltinmodule.c Wed Aug 15 23:52:31 2012 +0300 @@ -428,9 +428,11 @@ ok = PyObject_IsTrue(good); Py_DECREF(good); } - if (ok) + if (ok > 0) return item; Py_DECREF(item); + if (ok < 0) + return NULL; } } diff -r 84899daa4309 Python/import.c --- a/Python/import.c Tue Aug 14 18:41:40 2012 +0300 +++ b/Python/import.c Wed Aug 15 23:52:31 2012 +0300 @@ -1338,7 +1338,10 @@ name, pathname); if (cpathname) { PyObject *ro = PySys_GetObject("dont_write_bytecode"); - if (ro == NULL || !PyObject_IsTrue(ro)) + int b = (ro == NULL) ? 0 : PyObject_IsTrue(ro); + if (b < 0) + goto error_exit; + if (!b) write_compiled_module(co, cpathname, &st); } } @@ -2504,7 +2507,13 @@ } if (fromlist != NULL) { - if (fromlist == Py_None || !PyObject_IsTrue(fromlist)) + int b = (fromlist == Py_None) ? 0 : PyObject_IsTrue(fromlist); + if (b < 0) { + Py_DECREF(tail); + Py_DECREF(head); + goto error_exit; + } + if (!b) fromlist = NULL; } -------------- next part -------------- diff -r db1b4aab53eb Modules/_csv.c --- a/Modules/_csv.c Tue Aug 07 11:57:47 2012 -0700 +++ b/Modules/_csv.c Wed Aug 15 23:52:44 2012 +0300 @@ -208,8 +208,12 @@ { if (src == NULL) *target = dflt; - else - *target = PyObject_IsTrue(src); + else { + int b = PyObject_IsTrue(src); + if (b < 0) + return -1; + *target = b; + } return 0; } diff -r db1b4aab53eb Modules/_io/textio.c --- a/Modules/_io/textio.c Tue Aug 07 11:57:47 2012 -0700 +++ b/Modules/_io/textio.c Wed Aug 15 23:52:44 2012 +0300 @@ -1013,8 +1013,11 @@ res = PyObject_CallMethod(buffer, "seekable", NULL); if (res == NULL) goto error; - self->seekable = self->telling = PyObject_IsTrue(res); + r = PyObject_IsTrue(res); Py_DECREF(res); + if (r < 0) + goto error; + self->seekable = self->telling = r; self->encoding_start_of_stream = 0; if (self->seekable && self->encoder) { diff -r db1b4aab53eb Modules/_ssl.c --- a/Modules/_ssl.c Tue Aug 07 11:57:47 2012 -0700 +++ b/Modules/_ssl.c Wed Aug 15 23:52:44 2012 +0300 @@ -1005,6 +1005,7 @@ int len; int verification; PyObject *binary_mode = Py_None; + int b; if (!PyArg_ParseTuple(args, "|O:peer_certificate", &binary_mode)) return NULL; @@ -1012,7 +1013,10 @@ if (!self->peer_cert) Py_RETURN_NONE; - if (PyObject_IsTrue(binary_mode)) { + b = PyObject_IsTrue(binary_mode); + if (b < 0) + return NULL; + if (b) { /* return cert in DER-encoded format */ unsigned char *bytes_buf = NULL; diff -r db1b4aab53eb Modules/cStringIO.c --- a/Modules/cStringIO.c Tue Aug 07 11:57:47 2012 -0700 +++ b/Modules/cStringIO.c Wed Aug 15 23:52:44 2012 +0300 @@ -127,12 +127,16 @@ static PyObject * IO_getval(IOobject *self, PyObject *args) { PyObject *use_pos=Py_None; + int b; Py_ssize_t s; if (!IO__opencheck(self)) return NULL; if (!PyArg_UnpackTuple(args,"getval", 0, 1,&use_pos)) return NULL; - if (PyObject_IsTrue(use_pos)) { + b = PyObject_IsTrue(use_pos); + if (b < 0) + return NULL; + if (b) { s=self->pos; if (s > self->string_size) s=self->string_size; } diff -r db1b4aab53eb Modules/itertoolsmodule.c --- a/Modules/itertoolsmodule.c Tue Aug 07 11:57:47 2012 -0700 +++ b/Modules/itertoolsmodule.c Wed Aug 15 23:52:44 2012 +0300 @@ -903,11 +903,13 @@ } ok = PyObject_IsTrue(good); Py_DECREF(good); - if (!ok) { + if (ok == 0) { lz->start = 1; return item; } Py_DECREF(item); + if (ok < 0) + return NULL; } } @@ -1043,10 +1045,11 @@ } ok = PyObject_IsTrue(good); Py_DECREF(good); - if (ok) + if (ok > 0) return item; Py_DECREF(item); - lz->stop = 1; + if (ok == 0) + lz->stop = 1; return NULL; } @@ -3001,9 +3004,11 @@ ok = PyObject_IsTrue(good); Py_DECREF(good); } - if (ok) + if (ok > 0) return item; Py_DECREF(item); + if (ok < 0) + return NULL; } } @@ -3144,9 +3149,11 @@ ok = PyObject_IsTrue(good); Py_DECREF(good); } - if (!ok) + if (ok == 0) return item; Py_DECREF(item); + if (ok < 0) + return NULL; } } diff -r db1b4aab53eb Modules/parsermodule.c --- a/Modules/parsermodule.c Tue Aug 07 11:57:47 2012 -0700 +++ b/Modules/parsermodule.c Wed Aug 15 23:52:44 2012 +0300 @@ -350,10 +350,14 @@ int lineno = 0; int col_offset = 0; if (line_option != NULL) { - lineno = (PyObject_IsTrue(line_option) != 0) ? 1 : 0; + lineno = PyObject_IsTrue(line_option); + if (lineno < 0) + return NULL; } if (col_option != NULL) { - col_offset = (PyObject_IsTrue(col_option) != 0) ? 1 : 0; + col_offset = PyObject_IsTrue(col_option); + if (col_offset < 0) + return NULL; } /* * Convert ST into a tuple representation. Use Guido's function, @@ -401,10 +405,14 @@ int lineno = 0; int col_offset = 0; if (line_option != 0) { - lineno = PyObject_IsTrue(line_option) ? 1 : 0; + lineno = PyObject_IsTrue(line_option); + if (lineno < 0) + return NULL; } - if (col_option != NULL) { - col_offset = (PyObject_IsTrue(col_option) != 0) ? 1 : 0; + if (col_option != 0) { + col_offset = PyObject_IsTrue(col_option); + if (col_offset < 0) + return NULL; } /* * Convert ST into a tuple representation. Use Guido's function, diff -r db1b4aab53eb Modules/pyexpat.c --- a/Modules/pyexpat.c Tue Aug 07 11:57:47 2012 -0700 +++ b/Modules/pyexpat.c Wed Aug 15 23:52:44 2012 +0300 @@ -1174,13 +1174,16 @@ xmlparse_UseForeignDTD(xmlparseobject *self, PyObject *args) { PyObject *flagobj = NULL; - XML_Bool flag = XML_TRUE; + int flag = 1; enum XML_Error rc; - if (!PyArg_UnpackTuple(args, "UseForeignDTD", 0, 1, &flagobj)) + if (!PyArg_ParseTuple(args, "O:UseForeignDTD", &flagobj)) return NULL; - if (flagobj != NULL) - flag = PyObject_IsTrue(flagobj) ? XML_TRUE : XML_FALSE; - rc = XML_UseForeignDTD(self->itself, flag); + if (flagobj != NULL) { + flag = PyObject_IsTrue(flagobj); + if (flag < 0) + return NULL; + } + rc = XML_UseForeignDTD(self->itself, flag ? XML_TRUE : XML_FALSE); if (rc != XML_ERROR_NONE) { return set_error(self, rc); } @@ -1549,7 +1552,10 @@ return -1; } if (strcmp(name, "buffer_text") == 0) { - if (PyObject_IsTrue(v)) { + int b = PyObject_IsTrue(v); + if (b < 0) + return -1; + if (b) { if (self->buffer == NULL) { self->buffer = malloc(self->buffer_size); if (self->buffer == NULL) { @@ -1568,39 +1574,39 @@ return 0; } if (strcmp(name, "namespace_prefixes") == 0) { - if (PyObject_IsTrue(v)) - self->ns_prefixes = 1; - else - self->ns_prefixes = 0; + int b = PyObject_IsTrue(v); + if (b < 0) + return -1; + self->ns_prefixes = b; XML_SetReturnNSTriplet(self->itself, self->ns_prefixes); return 0; } if (strcmp(name, "ordered_attributes") == 0) { - if (PyObject_IsTrue(v)) - self->ordered_attributes = 1; - else - self->ordered_attributes = 0; + int b = PyObject_IsTrue(v); + if (b < 0) + return -1; + self->ordered_attributes = b; return 0; } if (strcmp(name, "returns_unicode") == 0) { - if (PyObject_IsTrue(v)) { + int b = PyObject_IsTrue(v); + if (b < 0) + return -1; #ifndef Py_USING_UNICODE + if (b) { PyErr_SetString(PyExc_ValueError, "Unicode support not available"); return -1; -#else - self->returns_unicode = 1; + } #endif - } - else - self->returns_unicode = 0; + self->returns_unicode = b; return 0; } if (strcmp(name, "specified_attributes") == 0) { - if (PyObject_IsTrue(v)) - self->specified_attributes = 1; - else - self->specified_attributes = 0; + int b = PyObject_IsTrue(v); + if (b < 0) + return -1; + self->specified_attributes = b; return 0; } diff -r db1b4aab53eb Objects/typeobject.c --- a/Objects/typeobject.c Tue Aug 07 11:57:47 2012 -0700 +++ b/Objects/typeobject.c Wed Aug 15 23:52:44 2012 +0300 @@ -327,11 +327,15 @@ abc.ABCMeta.__new__, so this function doesn't do anything special to update subclasses. */ - int res; + int abstract, res; if (value != NULL) { + abstract = PyObject_IsTrue(value); + if (abstract < 0) + return -1; res = PyDict_SetItemString(type->tp_dict, "__abstractmethods__", value); } else { + abstract = 0; res = PyDict_DelItemString(type->tp_dict, "__abstractmethods__"); if (res && PyErr_ExceptionMatches(PyExc_KeyError)) { PyErr_SetString(PyExc_AttributeError, "__abstractmethods__"); @@ -340,12 +344,10 @@ } if (res == 0) { PyType_Modified(type); - if (value && PyObject_IsTrue(value)) { + if (abstract) type->tp_flags |= Py_TPFLAGS_IS_ABSTRACT; - } - else { + else type->tp_flags &= ~Py_TPFLAGS_IS_ABSTRACT; - } } return res; } diff -r db1b4aab53eb Python/bltinmodule.c --- a/Python/bltinmodule.c Tue Aug 07 11:57:47 2012 -0700 +++ b/Python/bltinmodule.c Wed Aug 15 23:52:44 2012 +0300 @@ -313,7 +313,7 @@ ok = PyObject_IsTrue(good); Py_DECREF(good); } - if (ok) { + if (ok > 0) { if (j < len) PyList_SET_ITEM(result, j, item); else { @@ -324,8 +324,11 @@ } ++j; } - else + else { Py_DECREF(item); + if (ok < 0) + goto Fail_result_it; + } } @@ -2784,12 +2787,15 @@ } ok = PyObject_IsTrue(good); Py_DECREF(good); - if (ok) { + if (ok > 0) { if (PyTuple_SetItem(result, j++, item) < 0) goto Fail_1; } - else + else { Py_DECREF(item); + if (ok < 0) + goto Fail_1; + } } if (_PyTuple_Resize(&result, j) < 0) @@ -2851,7 +2857,7 @@ ok = PyObject_IsTrue(good); Py_DECREF(good); } - if (ok) { + if (ok > 0) { Py_ssize_t reslen; if (!PyString_Check(item)) { PyErr_SetString(PyExc_TypeError, "can't filter str to str:" @@ -2917,6 +2923,8 @@ } } Py_DECREF(item); + if (ok < 0) + goto Fail_1; } if (j < outlen) @@ -2977,7 +2985,7 @@ ok = PyObject_IsTrue(good); Py_DECREF(good); } - if (ok) { + if (ok > 0) { Py_ssize_t reslen; if (!PyUnicode_Check(item)) { PyErr_SetString(PyExc_TypeError, @@ -3032,6 +3040,8 @@ } } Py_DECREF(item); + if (ok < 0) + goto Fail_1; } if (j < outlen) diff -r db1b4aab53eb Python/import.c --- a/Python/import.c Tue Aug 07 11:57:47 2012 -0700 +++ b/Python/import.c Wed Aug 15 23:52:44 2012 +0300 @@ -1043,7 +1043,10 @@ name, pathname); if (cpathname) { PyObject *ro = PySys_GetObject("dont_write_bytecode"); - if (ro == NULL || !PyObject_IsTrue(ro)) + int b = (ro == NULL) ? 0 : PyObject_IsTrue(ro); + if (b < 0) + goto error_exit; + if (!b) write_compiled_module(co, cpathname, &st); } } @@ -2200,7 +2203,13 @@ } if (fromlist != NULL) { - if (fromlist == Py_None || !PyObject_IsTrue(fromlist)) + int b = (fromlist == Py_None) ? 0 : PyObject_IsTrue(fromlist); + if (b < 0) { + Py_DECREF(tail); + Py_DECREF(head); + goto error_exit; + } + if (!b) fromlist = NULL; } From report at bugs.python.org Wed Aug 15 22:57:59 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Aug 2012 20:57:59 +0000 Subject: [issue15490] Correct __sizeof__ support for StringIO In-Reply-To: <1343591617.54.0.289047671129.issue15490@psf.upfronthosting.co.za> Message-ID: <1345064279.09.0.0537703862129.issue15490@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: storchaka -> keywords: +needs review stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 23:00:22 2012 From: report at bugs.python.org (Nadeem Vawda) Date: Wed, 15 Aug 2012 21:00:22 +0000 Subject: [issue12669] test_curses skipped on buildbots In-Reply-To: <1312149135.76.0.0319517534091.issue12669@psf.upfronthosting.co.za> Message-ID: <1345064422.11.0.0229032555872.issue12669@psf.upfronthosting.co.za> Nadeem Vawda added the comment: > Nadeem: is the failure you show in msg141798 with a version of test_curses that uses pty.openpty? Yes, I tried the following change: --- a/Lib/test/test_curses.py +++ b/Lib/test/test_curses.py @@ -328,11 +328,12 @@ curses.resetty() def test_main(): - if not sys.__stdout__.isatty(): - raise unittest.SkipTest("sys.__stdout__ is not a tty") # testing setupterm() inside initscr/endwin # causes terminal breakage - curses.setupterm(fd=sys.__stdout__.fileno()) + #curses.setupterm(fd=sys.__stdout__.fileno()) + import pty + _, pty = pty.openpty() + curses.setupterm(fd=pty) try: stdscr = curses.initscr() main(stdscr) (I've never used openpty, either in Python or in C, so I can't vouch for the correctness of this usage.) > If it isn't: I'd expect more test failures on buildbot machines where the buildbot agent is started as a system daemon, in which case the process doesn't have a tty at all. Using pty.openpty it would be possible to ensure that there is a pty that can be used for the test. Looking at the actual buildbot results, most of the *nix bots I checked are actually skipping this test; the only one I could find that wasn't is the "x86 Ubuntu Shared" bot: ttp://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/6640/steps/test/logs/stdio So it looks like on most of the bots, buildbot is running without a tty. Then, test_main() sees that sys.__stdout__ isn't suitable to run the test, and bails out. It'd be great if you can come up with a fix that gets the test running in this environment, but it'll probably be more complicated than just slotting in a call to openpty(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 23:00:45 2012 From: report at bugs.python.org (Nadeem Vawda) Date: Wed, 15 Aug 2012 21:00:45 +0000 Subject: [issue12669] test_curses skipped on buildbots In-Reply-To: <1312149135.76.0.0319517534091.issue12669@psf.upfronthosting.co.za> Message-ID: <1345064445.74.0.786538713098.issue12669@psf.upfronthosting.co.za> Changes by Nadeem Vawda : ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 23:27:24 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 15 Aug 2012 21:27:24 +0000 Subject: [issue15604] PyObject_IsTrue failure checks In-Reply-To: <1344525855.66.0.08938802791.issue15604@psf.upfronthosting.co.za> Message-ID: <3Wy3fg52CjzPjK@mail.python.org> Roundup Robot added the comment: New changeset ba1c48f8b571 by Antoine Pitrou in branch '2.7': Issue #15604: Update uses of PyObject_IsTrue() to check for and handle errors correctly. http://hg.python.org/cpython/rev/ba1c48f8b571 New changeset 56dc7b09f390 by Antoine Pitrou in branch '3.2': Issue #15604: Update uses of PyObject_IsTrue() to check for and handle errors correctly. http://hg.python.org/cpython/rev/56dc7b09f390 New changeset b878df1d23b1 by Antoine Pitrou in branch 'default': Issue #15604: Update uses of PyObject_IsTrue() to check for and handle errors correctly. http://hg.python.org/cpython/rev/b878df1d23b1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 23:34:44 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 15 Aug 2012 21:34:44 +0000 Subject: [issue12623] "universal newlines" subprocess support broken with select- and poll-based communicate() In-Reply-To: <1311451893.22.0.0169745025507.issue12623@psf.upfronthosting.co.za> Message-ID: <1345066484.33.0.996274153748.issue12623@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > Looking the code this test will fail on Windows. I cannot check it just now but looks like this is the problem. Would it be possible to do something like the following to check this on a non-Windows machine (since the Python implementation of io respects the mutability of os.linesep but perhaps not the C version)? It seems so. >>> import _pyio, io, os >>> io.TextIOWrapper = _pyio.TextIOWrapper >>> os.linesep = "\r\n" etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 23:45:36 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Aug 2012 21:45:36 +0000 Subject: [issue15604] PyObject_IsTrue failure checks In-Reply-To: <1344525855.66.0.08938802791.issue15604@psf.upfronthosting.co.za> Message-ID: <1345067136.81.0.603986385529.issue15604@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Antoine. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 15 23:52:09 2012 From: report at bugs.python.org (Florent Xicluna) Date: Wed, 15 Aug 2012 21:52:09 +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: <1345067529.48.0.927119914838.issue15661@psf.upfronthosting.co.za> Changes by Florent Xicluna : ---------- nosy: +flox _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 00:48:56 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 15 Aug 2012 22:48:56 +0000 Subject: [issue15543] central documentation for 'universal newlines' In-Reply-To: <1343953234.25.0.0555174882779.issue15543@psf.upfronthosting.co.za> Message-ID: <1345070936.44.0.439820558678.issue15543@psf.upfronthosting.co.za> ?ric Araujo added the comment: Great patch! ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 00:52:25 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 15 Aug 2012 22:52:25 +0000 Subject: [issue12436] Missing items in installation/setup instructions In-Reply-To: <1309305395.29.0.101516779086.issue12436@psf.upfronthosting.co.za> Message-ID: <1345071145.35.0.209216016756.issue12436@psf.upfronthosting.co.za> ?ric Araujo added the comment: My computer currently doesn?t boot so I can?t check if I had started or not. You can propose a patch incorporating the various suggestions, or give me some days to read this again and make a summary of what I would have done. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 00:54:15 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 15 Aug 2012 22:54:15 +0000 Subject: [issue7231] Windows installer does not add \Scripts folder to the path In-Reply-To: <1256749152.57.0.801313448944.issue7231@psf.upfronthosting.co.za> Message-ID: <1345071255.06.0.204699858725.issue7231@psf.upfronthosting.co.za> ?ric Araujo added the comment: BTW, any reason to create python27.exe instead of python2.7.exe (so that the unix-centered docs about command lines would also apply to your Pythons)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 03:04:10 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 16 Aug 2012 01:04:10 +0000 Subject: [issue15625] Support u and w codes in memoryview In-Reply-To: <1344719787.86.0.485615026169.issue15625@psf.upfronthosting.co.za> Message-ID: <1345079050.28.0.028981423401.issue15625@psf.upfronthosting.co.za> Nick Coghlan added the comment: I admit that the main thing that bothers me with the proposal in PEP 3118 is the inconsistency between c -> bytes, while u, w -> str This was less of an issue in 2.x (which was the main frame of reference when the PEP was written), with implicit str/unicode interoperability, but seems quite jarring in the 3.x world. Status quo: struct module: 'c' = individual bytes, 's' = multi-byte sequence array module: 'u' typecode may be either 2 bytes or 4 bytes (Py_UNICODE) (the addition of the 'w' typecode has been reverted) My current inclination is still to apply Victor's patch from #13072 (which changes array to export the appropriate integer typecodes for 'u' arrays) and otherwise punt on this for 3.3 and try to sort out the mess for 3.4. For 3.4, I'm inclined to favour Stefan's proposal of C, U, W mapping to multi-point sequences of UCS-1, UCS-2, UCS-4 code points (with corresponding typecodes in the array module). Support for lowercase 'u' would then never become an official part of the buffer API, existing only as an array typecode. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 03:07:16 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 16 Aug 2012 01:07:16 +0000 Subject: [issue15604] PyObject_IsTrue failure checks In-Reply-To: <1344525855.66.0.08938802791.issue15604@psf.upfronthosting.co.za> Message-ID: <1345079236.73.0.778445851499.issue15604@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 03:08:12 2012 From: report at bugs.python.org (Ned Deily) Date: Thu, 16 Aug 2012 01:08:12 +0000 Subject: [issue15678] IDLE menu customization is broken from OS X command lines Message-ID: <1345079292.52.0.381785713034.issue15678@psf.upfronthosting.co.za> New submission from Ned Deily: With 3.3.0b2, when IDLE is started from a command line using an OS X framework build (such as provided by the python.org installers), the Aqua Tk menu customization is no longer being performed, for example, no Preferences menu item, an extra Options menu, etc. It was broken as a side effect of the changes to pythonw.c in b79d276041a8 for #15307. Since sys.executable no longer includes 'Python.app' in the path name, the attached patch tests for a framework build instead. This should give the previous behavior in nearly all cases. Whether the previous behavior is sensible is left as an issue for later releases. IDLE.app behavior was not affected as it does its own manipulation of sys.executable; that should probably also be changed in the future. ---------- assignee: ned.deily components: IDLE, Macintosh files: XXXXX_bin_idle_menus.patch keywords: patch messages: 168346 nosy: ned.deily, ronaldoussoren priority: release blocker severity: normal stage: commit review status: open title: IDLE menu customization is broken from OS X command lines versions: Python 3.3 Added file: http://bugs.python.org/file26841/XXXXX_bin_idle_menus.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 04:19:19 2012 From: report at bugs.python.org (Meador Inge) Date: Thu, 16 Aug 2012 02:19:19 +0000 Subject: [issue15675] PEP 3121, 384 Refactoring applied to array module In-Reply-To: <1345043626.95.0.208765115861.issue15675@psf.upfronthosting.co.za> Message-ID: <1345083559.71.0.288197978583.issue15675@psf.upfronthosting.co.za> Changes by Meador Inge : ---------- nosy: +meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 04:19:41 2012 From: report at bugs.python.org (Meador Inge) Date: Thu, 16 Aug 2012 02:19:41 +0000 Subject: [issue15675] PEP 3121, 384 Refactoring applied to array module In-Reply-To: <1345043626.95.0.208765115861.issue15675@psf.upfronthosting.co.za> Message-ID: <1345083581.86.0.0283978857618.issue15675@psf.upfronthosting.co.za> Changes by Meador Inge : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 04:20:04 2012 From: report at bugs.python.org (Meador Inge) Date: Thu, 16 Aug 2012 02:20:04 +0000 Subject: [issue15671] PEP 3121, 384 Refactoring applied to struct module In-Reply-To: <1345041779.43.0.428829398339.issue15671@psf.upfronthosting.co.za> Message-ID: <1345083604.61.0.0754863632806.issue15671@psf.upfronthosting.co.za> Changes by Meador Inge : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 06:30:14 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 16 Aug 2012 04:30:14 +0000 Subject: [issue11062] mailbox fails to round-trip a file to a Babyl mailbox In-Reply-To: <1296317976.28.0.825353703674.issue11062@psf.upfronthosting.co.za> Message-ID: <3WyF2X4xVDzPsm@mail.python.org> Roundup Robot added the comment: New changeset 770ffc91a82e by Petri Lehtinen in branch '3.2': #11062: Fix universal newline support in Babyl._install_message() http://hg.python.org/cpython/rev/770ffc91a82e New changeset 5206b9dbf1ac by Petri Lehtinen in branch 'default': #11062: Fix universal newline support in Babyl._install_message() http://hg.python.org/cpython/rev/5206b9dbf1ac ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 08:28:06 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 16 Aug 2012 06:28:06 +0000 Subject: [issue13119] Newline for print() is \n on Windows, and not \r\n as expected In-Reply-To: <1317934788.08.0.425265217585.issue13119@psf.upfronthosting.co.za> Message-ID: <1345098486.35.0.0238159178413.issue13119@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > + " newline is '' or '\n', no translation takes place. If newline is any\n" Non-escaped "\n". ---------- nosy: +storchaka status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 08:33:06 2012 From: report at bugs.python.org (Georg Brandl) Date: Thu, 16 Aug 2012 06:33:06 +0000 Subject: [issue13119] Newline for print() is \n on Windows, and not \r\n as expected In-Reply-To: <1317934788.08.0.425265217585.issue13119@psf.upfronthosting.co.za> Message-ID: <1345098786.11.0.0836157243346.issue13119@psf.upfronthosting.co.za> Georg Brandl added the comment: Would be nice to be a bit more specific *where* that line comes from. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 08:54:33 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 16 Aug 2012 06:54:33 +0000 Subject: [issue13119] Newline for print() is \n on Windows, and not \r\n as expected In-Reply-To: <1345098786.11.0.0836157243346.issue13119@psf.upfronthosting.co.za> Message-ID: <201208160954.17520.storchaka@gmail.com> Serhiy Storchaka added the comment: > Would be nice to be a bit more specific *where* that line comes from. Modules/_io/textio.c, changesets 243ad1a6f638 and 083776adcacc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 08:58:04 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 16 Aug 2012 06:58:04 +0000 Subject: [issue13119] Newline for print() is \n on Windows, and not \r\n as expected In-Reply-To: <1317934788.08.0.425265217585.issue13119@psf.upfronthosting.co.za> Message-ID: <1345100284.47.0.931702857207.issue13119@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Oops, I got the wrong issue, sorry. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 09:59:42 2012 From: report at bugs.python.org (Julien Palard) Date: Thu, 16 Aug 2012 07:59:42 +0000 Subject: [issue15679] HTMLParser can fail on unquoted attributes. Message-ID: <1345103982.29.0.499632264668.issue15679@psf.upfronthosting.co.za> New submission from Julien Palard: This is accepted by browsers but raises an exception in HTMLParser : from HTMLParser import HTMLParser HTMLParser().feed("") ---------- components: Library (Lib) messages: 168352 nosy: JulienPalard priority: normal severity: normal status: open title: HTMLParser can fail on unquoted attributes. type: enhancement versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 10:21:55 2012 From: report at bugs.python.org (Robin Schreiber) Date: Thu, 16 Aug 2012 08:21:55 +0000 Subject: [issue15680] PEP 3121 refactoring applied to audioop module Message-ID: <1345105315.06.0.844994480517.issue15680@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 have now been applied to the audioop module! ---------- components: Extension Modules files: audioop_pep3121_v0.patch keywords: patch messages: 168353 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121 refactoring applied to audioop module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26842/audioop_pep3121_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 10:26:52 2012 From: report at bugs.python.org (Robin Schreiber) Date: Thu, 16 Aug 2012 08:26:52 +0000 Subject: [issue15681] PEP 3121 refactoring applied to binascii module Message-ID: <1345105612.5.0.663032219905.issue15681@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 have now been applied to the binascii module! ---------- components: Extension Modules files: binascii_pep3121_v0.patch keywords: patch messages: 168354 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121 refactoring applied to binascii module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26843/binascii_pep3121_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 10:33:46 2012 From: report at bugs.python.org (Robin Schreiber) Date: Thu, 16 Aug 2012 08:33:46 +0000 Subject: [issue15682] PEP 3121 refactoring applied to fpectl module Message-ID: <1345106026.62.0.405677878091.issue15682@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 have now been applied to the fpectl module! ---------- components: Extension Modules files: fpectl_pep3121_v0.patch keywords: patch messages: 168355 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121 refactoring applied to fpectl module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26844/fpectl_pep3121_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 10:34:40 2012 From: report at bugs.python.org (Arvin Moezzi) Date: Thu, 16 Aug 2012 08:34:40 +0000 Subject: [issue15683] add decorator for make functions partial applicable Message-ID: <1345106080.5.0.940498216891.issue15683@psf.upfronthosting.co.za> New submission from Arvin Moezzi: I am not sure if this is the right way to do it but IMHO it would be great to have a function decorator/transformer to make functions partial applicable using functools.partial. Like from functools import partial class partial_applicable(): def __call__(self, func): def __wrapper(*args, **kvargs): try: return func(*args, **kvargs) except TypeError: return partial(func, *args, **kvargs) return __wrapper Then you could do like: @partial_applicable() def substract(left, right): return left - right substract(10, 100) => -90 rclose = substract(right = 1000) => rclose(10) => -990 lclose = substract(1) => lclose(10) => -9 What do you think? ---------- components: Library (Lib) messages: 168356 nosy: Arvin.Moezzi priority: normal severity: normal status: open title: add decorator for make functions partial applicable type: enhancement versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 10:39:13 2012 From: report at bugs.python.org (Robin Schreiber) Date: Thu, 16 Aug 2012 08:39:13 +0000 Subject: [issue15684] PEP 3121 refactoring applied to fpetest module Message-ID: <1345106353.01.0.354070403229.issue15684@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the fpetest module! ---------- components: Extension Modules files: fpetest_pep3121_v0.patch keywords: patch messages: 168357 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121 refactoring applied to fpetest module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26845/fpetest_pep3121_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 10:44:58 2012 From: report at bugs.python.org (Arvin Moezzi) Date: Thu, 16 Aug 2012 08:44:58 +0000 Subject: [issue15683] add decorator for make functions partial applicable In-Reply-To: <1345106080.5.0.940498216891.issue15683@psf.upfronthosting.co.za> Message-ID: <1345106698.85.0.891934481025.issue15683@psf.upfronthosting.co.za> Arvin Moezzi added the comment: Or maybe even class partial_applicable(): def __call__(self, func): def __wrapper(*args, **kvargs): try: return func(*args, **kvargs) except TypeError: partial_func = partial(func, *args, **kvargs) return partial_applicable()(partial_func) return __wrapper ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 10:52:10 2012 From: report at bugs.python.org (Robin Schreiber) Date: Thu, 16 Aug 2012 08:52:10 +0000 Subject: [issue15685] PEP 3121, 384 Refactoring applied to itertools module Message-ID: <1345107130.15.0.109791509014.issue15685@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the itertools module! ---------- components: Extension Modules files: itertools_pep3121-384_v0.patch keywords: patch messages: 168359 nosy: Robin.Schreiber, rhettinger priority: normal severity: normal status: open title: PEP 3121, 384 Refactoring applied to itertools module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26846/itertools_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 10:56:34 2012 From: report at bugs.python.org (Robin Schreiber) Date: Thu, 16 Aug 2012 08:56:34 +0000 Subject: [issue15686] PEP 3121, 384 Refactoring applied to md5 module Message-ID: <1345107394.8.0.322253629344.issue15686@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the md5 module! ---------- components: Extension Modules files: md5_pep3121-384_v0.patch keywords: patch messages: 168360 nosy: Robin.Schreiber, gregory.p.smith priority: normal severity: normal status: open title: PEP 3121, 384 Refactoring applied to md5 module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26847/md5_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 11:04:14 2012 From: report at bugs.python.org (Robin Schreiber) Date: Thu, 16 Aug 2012 09:04:14 +0000 Subject: [issue15687] PEP 3121, 384 Refactoring applied to mmap module Message-ID: <1345107854.44.0.304444585248.issue15687@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the mmap module! ---------- components: Extension Modules files: mmap_pep3121-384_v0.patch keywords: patch messages: 168361 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121, 384 Refactoring applied to mmap module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26848/mmap_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 11:07:10 2012 From: report at bugs.python.org (Robin Schreiber) Date: Thu, 16 Aug 2012 09:07:10 +0000 Subject: [issue15688] PEP 3121 Refactoring applied to nis module Message-ID: <1345108030.82.0.709168426802.issue15688@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the nis module! ---------- components: Extension Modules files: nis_pep3121_v0.patch keywords: patch messages: 168362 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121 Refactoring applied to nis module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26849/nis_pep3121_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 11:11:10 2012 From: report at bugs.python.org (Robin Schreiber) Date: Thu, 16 Aug 2012 09:11:10 +0000 Subject: [issue15689] PEP 3121, 384 Refactoring applied to operator module Message-ID: <1345108270.08.0.792336890272.issue15689@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the operator module! ---------- components: Extension Modules files: operator_pep3121-384_v0.patch keywords: patch messages: 168363 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121, 384 Refactoring applied to operator module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26850/operator_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 11:22:47 2012 From: report at bugs.python.org (Robin Schreiber) Date: Thu, 16 Aug 2012 09:22:47 +0000 Subject: [issue15690] PEP 3121, 384 Refactoring applied to parser module Message-ID: <1345108967.12.0.878524641332.issue15690@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the parser module! ---------- components: Extension Modules files: parser_pep3121-384_v0.patch keywords: patch messages: 168364 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121, 384 Refactoring applied to parser module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26851/parser_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 11:39:35 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 16 Aug 2012 09:39:35 +0000 Subject: [issue15625] Support u and w codes in memoryview In-Reply-To: <1345079050.28.0.028981423401.issue15625@psf.upfronthosting.co.za> Message-ID: <20120816113933.Horde.N-twJNjz9kRQLL-Vuqew9MA@webmail.df.eu> Martin v. L?wis added the comment: > My current inclination is still to apply Victor's patch from #13072 > (which changes array to export the appropriate integer typecodes for > 'u' arrays) and otherwise punt on this for 3.3 and try to sort out > the mess for 3.4. I think this would be the worst choice. It would mean that we change the format for exported array.arrays now for 3.3, and then change it in 3.4 again. So anybody who cares about this would have to deal with three different behaviors. Note that the array module had been using 'u' and 'w' essentially "forever" (i.e. since 3.0). > For 3.4, I'm inclined to favour Stefan's proposal of C, U, W mapping > to multi-point sequences of UCS-1, UCS-2, UCS-4 code points (with > corresponding typecodes in the array module). Fine with me in principle, although I see a problem when NumPy uses 'U' for UCS-4, yet CPython declares it to be UCS-2. I also think that Travis' explicit agreement must be sought. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 11:40:16 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Thu, 16 Aug 2012 09:40:16 +0000 Subject: [issue11062] mailbox fails to round-trip a file to a Babyl mailbox In-Reply-To: <1296317976.28.0.825353703674.issue11062@psf.upfronthosting.co.za> Message-ID: <1345110016.75.0.561822332428.issue11062@psf.upfronthosting.co.za> Petri Lehtinen added the comment: Tests are now passing on Windows, too. Closing. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 11:48:05 2012 From: report at bugs.python.org (Robin Schreiber) Date: Thu, 16 Aug 2012 09:48:05 +0000 Subject: [issue15691] PEP 3121, 384 Refactoring applied to posix module Message-ID: <1345110485.53.0.856598198463.issue15691@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the posix module! ---------- components: Extension Modules files: posix_pep3121-384_v0.patch keywords: patch messages: 168367 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121, 384 Refactoring applied to posix module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26852/posix_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 12:30:22 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 16 Aug 2012 10:30:22 +0000 Subject: [issue15625] Support u and w codes in memoryview In-Reply-To: <1344719787.86.0.485615026169.issue15625@psf.upfronthosting.co.za> Message-ID: <1345113022.81.0.173485184838.issue15625@psf.upfronthosting.co.za> Nick Coghlan added the comment: I wouldn't change the export formats used for the 'u' typecode at all in 3.4 - I'd add new typecodes to array that match any new struct format characters and are exported accordingly. 'u' would *never* become a formally defined struct character, instead lingering in the array module as a legacy of the narrow/wide build distinction. And good point that U would need to match UCS-4 to be consistent with NumPy. Perhaps we can just add 'U' in 3.4 and forget about UCS-2 entirely? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 12:41:48 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 16 Aug 2012 10:41:48 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1317341390.65.0.255779328054.issue13072@psf.upfronthosting.co.za> Message-ID: <1345113708.34.0.661924646241.issue13072@psf.upfronthosting.co.za> Nick Coghlan added the comment: Adding a link to #15625, which is discussing the other end of this issue (whether or not memorview should support 'u' as a typecode). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 12:57:30 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 16 Aug 2012 10:57:30 +0000 Subject: [issue15625] Support u and w codes in memoryview In-Reply-To: <1345113022.81.0.173485184838.issue15625@psf.upfronthosting.co.za> Message-ID: <20120816125729.Horde.5GaUHdjz9kRQLNIZNywB4EA@webmail.df.eu> Martin v. L?wis added the comment: > I wouldn't change the export formats used for the 'u' typecode at > all in 3.4 - I'd add new typecodes to array that match any new > struct format characters and are exported accordingly. 'u' would > *never* become a formally defined struct character, instead > lingering in the array module as a legacy of the narrow/wide build > distinction. I think it is a desirable property that for an array A and an index I, that A[I] == memoryview(A)[I]. Exporting the elements of an 'u' array as integers would break that property. So if we do want to support Unicode arrays (which some people apparently want to see - I haven't heard anybody saying they actually *need* such a type), the buffer type of it should be "unicode", in some form, not "number". I would be fine with deprecating the 'u' type arrays, acknowledging that the Py_UNICODE element type is even more useless now than before. If that is done, there is no point in fixing anything about it. If it exports using the 'u' and 'w' codes - fine. If then memoryview doesn't work properly - fine; this is a deprecated feature. It should be fixed only if we want to support it "properly" (which I believe this patch would do). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 13:13:00 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 16 Aug 2012 11:13:00 +0000 Subject: [issue15625] Support u and w codes in memoryview In-Reply-To: <1344719787.86.0.485615026169.issue15625@psf.upfronthosting.co.za> Message-ID: <1345115580.63.0.856753127223.issue15625@psf.upfronthosting.co.za> Nick Coghlan added the comment: I guess the main alternative to deprecation that preserves the invariant you describe would be to propagate the "u == Py_UNICODE" definition to memoryview. Since we're trying to phase out Py_UNICODE, deprecation seems the more sensible course. Perhaps just a documented deprecation for now, like the rest of the Py_UNICODE based APIs? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 13:34:17 2012 From: report at bugs.python.org (Stefan Krah) Date: Thu, 16 Aug 2012 11:34:17 +0000 Subject: [issue15625] Support u and w codes in memoryview In-Reply-To: <20120816125729.Horde.5GaUHdjz9kRQLNIZNywB4EA@webmail.df.eu> Message-ID: <20120816113418.GA14971@sleipnir.bytereef.org> Stefan Krah added the comment: Martin v. Loewis wrote: > I would be fine with deprecating the 'u' type arrays, acknowledging > that the Py_UNICODE element type is even more useless now than before. > If that is done, there is no point in fixing anything about it. If > it exports using the 'u' and 'w' codes - fine. If then memoryview > doesn't work properly - fine; this is a deprecated feature. >From the perspective of memoryview backwards compatibility, deprecation is fine. In 3.2, memoryview could really only handle one-dimensional buffers of unsigned bytes: >>> import array >>> a = array.array('u', "ABC") >>> x = memoryview(a) >>> a[0] == x[0] False >>> a[0] 'A' # Indexing returns bytes instead of str: >>> x[0] b'A\x00' >>> # Index assignment attempts to do slice assignment: >>> x[0] = 'Z' Traceback (most recent call last): File "", line 1, in TypeError: 'str' does not support the buffer interface >>> I'm +1 for deprecating 'u' and 'w' in the array module, accept that memoryview cannot handle 'u' and 'w' and fix the situation properly in 3.4. I agree that the latter would require people to come up with actual use cases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 13:46:24 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 16 Aug 2012 11:46:24 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1317341390.65.0.255779328054.issue13072@psf.upfronthosting.co.za> Message-ID: <1345117584.08.0.995084618212.issue13072@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Based on the discussion in #15625, it seems that the consensus is to take no action on the format codes in this issue for 3.3, and reconsider in 3.4, to determine in what way the struct module should support Unicode. Instead, the 'u' array code will be deprecated, in the same way in which the rest of the Py_UNICODE API is deprecated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 13:47:12 2012 From: report at bugs.python.org (Stefan Krah) Date: Thu, 16 Aug 2012 11:47:12 +0000 Subject: [issue15035] array.array of UCS2 values In-Reply-To: <1339147370.98.0.5823346157.issue15035@psf.upfronthosting.co.za> Message-ID: <1345117632.19.0.296529050885.issue15035@psf.upfronthosting.co.za> Stefan Krah added the comment: This one should be fixed by #13072. Could you check again? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 13:47:47 2012 From: report at bugs.python.org (Stefan Krah) Date: Thu, 16 Aug 2012 11:47:47 +0000 Subject: [issue15625] Support u and w codes in memoryview In-Reply-To: <1344719787.86.0.485615026169.issue15625@psf.upfronthosting.co.za> Message-ID: <1345117667.1.0.381098297924.issue15625@psf.upfronthosting.co.za> Stefan Krah added the comment: Well, apparently people do use 'u', see #15035. ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 13:54:36 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 16 Aug 2012 11:54:36 +0000 Subject: [issue15035] array.array of UCS2 values In-Reply-To: <1339147370.98.0.5823346157.issue15035@psf.upfronthosting.co.za> Message-ID: <1345118076.66.0.944289360939.issue15035@psf.upfronthosting.co.za> Nick Coghlan added the comment: As Stefan noted, so long as Py_UNICODE is 16 bits in the Mac OS X builds, then this should now be back to the 3.2 behaviour. ---------- nosy: +ncoghlan priority: low -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 13:57:46 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 16 Aug 2012 11:57:46 +0000 Subject: [issue15625] Support u and w codes in memoryview In-Reply-To: <1344719787.86.0.485615026169.issue15625@psf.upfronthosting.co.za> Message-ID: <1345118266.32.0.619459825785.issue15625@psf.upfronthosting.co.za> Martin v. L?wis added the comment: #15035 indicates that there is a need for UCS-2 arrays, using 'u' arrays was technically incorrect, since it is based on Py_UNICODE, whereas the API in question uses UniChar (which apparently is a two-byte type). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 14:07:14 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 16 Aug 2012 12:07:14 +0000 Subject: [issue15035] array.array of UCS2 values In-Reply-To: <1339147370.98.0.5823346157.issue15035@psf.upfronthosting.co.za> Message-ID: <1345118834.69.0.247405611513.issue15035@psf.upfronthosting.co.za> Martin v. L?wis added the comment: It's not back to the 3.2 behavior. In 3.3, Py_UNICODE is always equal to wchar_t, which is a 4-byte type on Darwin. However, CFString is based on UniChar, which is a 2-byte type. That this worked in 3.2 was by accident - it would work only in "narrow" builds. Python's configure in 3.2 and before wouldn't default to using wchar_t on Darwin since it didn't consider wchar_t "usable", which in turn happened because wchar_t is signed on Darwin, but Py_UNICODE was understood to be unsigned. Since it's too late to add an 'U' code to 3.3, as a work-around, you would have to use a 'H' array, and initialize it with map(ord, the_string)). Chances are good that a proper UCS-2 array code gets added to 3.4. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 14:09:01 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Thu, 16 Aug 2012 12:09:01 +0000 Subject: [issue15035] array.array of UCS2 values In-Reply-To: <1339147370.98.0.5823346157.issue15035@psf.upfronthosting.co.za> Message-ID: <1345118941.58.0.634028657272.issue15035@psf.upfronthosting.co.za> Ronald Oussoren added the comment: Py_UNICODE is an typedef for wchar_t and that type is 4 bytes long: >>> a.tobytes() b'h\x00\x00\x00e\x00\x00\x00l\x00\x00\x00l\x00\x00\x00o\x00\x00\x00 \x00\x00\x00w\x00\x00\x00o\x00\x00\x00r\x00\x00\x00l\x00\x00\x00d\x00\x00\x00' >>> a = array.array('u', 'bar') >>> a.tobytes() b'b\x00\x00\x00a\x00\x00\x00r\x00\x00\x00' >>> len(a.tobytes()) 12 >>> This is with a checkout that was created yesterday. The issue is not resolved, there now is no way to easily create a UCS2 buffer; while there was in earlier releases of Python (with the default narrow build) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 14:25:04 2012 From: report at bugs.python.org (Stefan Krah) Date: Thu, 16 Aug 2012 12:25:04 +0000 Subject: [issue15625] Support u and w codes in memoryview In-Reply-To: <1345118266.32.0.619459825785.issue15625@psf.upfronthosting.co.za> Message-ID: <20120816122505.GA15033@sleipnir.bytereef.org> Stefan Krah added the comment: Martin v. L??wis wrote: > #15035 indicates that there is a need for UCS-2 arrays, using 'u' arrays was technically incorrect, since it is based on Py_UNICODE, whereas the API in question uses UniChar (which apparently is a two-byte type). Right, thanks for clearing that up. Then #15035 would indeed support deprecating 'u' and 'w' and moving on to UCS2 and UCS4 arrays. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 17:17:07 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 16 Aug 2012 15:17:07 +0000 Subject: [issue15679] HTMLParser can fail on unquoted attributes. In-Reply-To: <1345103982.29.0.499632264668.issue15679@psf.upfronthosting.co.za> Message-ID: <1345130227.25.0.353599646153.issue15679@psf.upfronthosting.co.za> R. David Murray added the comment: This is fixed in more recent versions of Python (2.7, 3.2+). ---------- nosy: +r.david.murray resolution: -> out of date stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 17:23:09 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 16 Aug 2012 15:23:09 +0000 Subject: [issue15683] add decorator for make functions partial applicable In-Reply-To: <1345106080.5.0.940498216891.issue15683@psf.upfronthosting.co.za> Message-ID: <1345130589.58.0.644556201455.issue15683@psf.upfronthosting.co.za> R. David Murray added the comment: YAGNI, is what I think. Or if you do need it, put it in your application. (To tell you the truth, it just looks confusing to me...it strikes me as too magical.) Regardless, this is more of a python-ideas kind of issue, so I suggest raising it there if you want to pursue it. ---------- nosy: +r.david.murray stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 17:29:36 2012 From: report at bugs.python.org (Daniel Ellis) Date: Thu, 16 Aug 2012 15:29:36 +0000 Subject: [issue15586] Provide some examples for usage of ElementTree methods/attributes In-Reply-To: <1344407679.24.0.102359835139.issue15586@psf.upfronthosting.co.za> Message-ID: <1345130976.94.0.332432000406.issue15586@psf.upfronthosting.co.za> Daniel Ellis added the comment: Made changes in structure in 2.7 branch to match 3.3 based on Eli's comments. Updated input prompt in examples per Ezio's review (though the default branch will still need this update). ---------- Added file: http://bugs.python.org/file26853/2.7_branch_etree_doc_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 17:30:12 2012 From: report at bugs.python.org (=?utf-8?q?Bj=C3=B6rn_Dahlgren?=) Date: Thu, 16 Aug 2012 15:30:12 +0000 Subject: [issue15692] Unexpected exponentiation in lambda function Message-ID: <1345131012.45.0.334354772161.issue15692@psf.upfronthosting.co.za> New submission from Bj?rn Dahlgren: Hi, I hope this is not a false positive but I cannot help thinking this is a bug, consider: Python 2.7.3 (default, Aug 1 2012, 05:14:39) [GCC 4.6.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> -3.2**0 -1.0 >>> sign=lambda x: x**0 >>> sign(-3.2) 1.0 Python 3.2.3 (default, May 3 2012, 15:51:42) [GCC 4.6.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> -3.2**0 -1.0 >>> sign=lambda x: x**0 >>> sign(-3.2) 1.0 Or is this expected? Best regards, Bj?rn Dahlgren ---------- components: None messages: 168384 nosy: bjodah priority: normal severity: normal status: open title: Unexpected exponentiation in lambda function versions: Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 17:38:58 2012 From: report at bugs.python.org (Arvin Moezzi) Date: Thu, 16 Aug 2012 15:38:58 +0000 Subject: [issue15683] add decorator for make functions partial applicable In-Reply-To: <1345106080.5.0.940498216891.issue15683@psf.upfronthosting.co.za> Message-ID: <1345131538.33.0.0576692451466.issue15683@psf.upfronthosting.co.za> Arvin Moezzi added the comment: Thanks for your feedback. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 17:43:48 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 16 Aug 2012 15:43:48 +0000 Subject: [issue15683] add decorator for make functions partial applicable In-Reply-To: <1345106080.5.0.940498216891.issue15683@psf.upfronthosting.co.za> Message-ID: <1345131828.15.0.569379159786.issue15683@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks for your suggestion, even though I'm rejecting the suggestion as a bug tracker issue. (I should have said that at the start of my answer.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 17:45:01 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 16 Aug 2012 15:45:01 +0000 Subject: [issue15692] Unexpected exponentiation in lambda function In-Reply-To: <1345131012.45.0.334354772161.issue15692@psf.upfronthosting.co.za> Message-ID: <1345131901.5.0.164494892216.issue15692@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: -3.2**0 == -(3.2**0) >>> (-3.2)**0 1.0 ---------- nosy: +storchaka resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 17:48:28 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 16 Aug 2012 15:48:28 +0000 Subject: [issue15693] expose glossary link on hover Message-ID: <1345132108.78.0.567099034623.issue15693@psf.upfronthosting.co.za> New submission from Chris Jerdonek: It would be nice if hovering over the right side of the header to a glossary entry would expose a link in the same way that it does for function definitions, etc. http://docs.python.org/dev/glossary.html#glossary Otherwise, there doesn't seem to be a convenient way to get a direct link to a glossary entry. I'm not sure if this issue should also be filed with Sphinx. ---------- assignee: docs at python components: Documentation messages: 168388 nosy: cjerdonek, docs at python priority: normal severity: normal status: open title: expose glossary link on hover type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 17:51:19 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 16 Aug 2012 15:51:19 +0000 Subject: [issue15693] expose glossary link on hover In-Reply-To: <1345132108.78.0.567099034623.issue15693@psf.upfronthosting.co.za> Message-ID: <1345132279.09.0.222114763969.issue15693@psf.upfronthosting.co.za> R. David Murray added the comment: I think it probably should be filed with sphinx instead, rather than also. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 17:51:20 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 16 Aug 2012 15:51:20 +0000 Subject: [issue14669] test_multiprocessing failure on OS X Tiger In-Reply-To: <1335370611.47.0.977907847024.issue14669@psf.upfronthosting.co.za> Message-ID: <3WyX8R3PljzQ1H@mail.python.org> Roundup Robot added the comment: New changeset 4307b985209b by Richard Oudkerk in branch 'default': Issue #14669: Fix pickling of connections and sockets on MacOSX http://hg.python.org/cpython/rev/4307b985209b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 18:02:05 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 16 Aug 2012 16:02:05 +0000 Subject: [issue15693] expose glossary link on hover In-Reply-To: <1345132108.78.0.567099034623.issue15693@psf.upfronthosting.co.za> Message-ID: <1345132925.14.0.605228338539.issue15693@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Do we pin the version of Sphinx that we use to generate the documentation? If Sphinx fixes the issue, would we need to make a corresponding change here to reflect the fix? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 18:06:31 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 16 Aug 2012 16:06:31 +0000 Subject: [issue15694] link to "file object" glossary entry in open() and io docs Message-ID: <1345133191.76.0.682782918752.issue15694@psf.upfronthosting.co.za> New submission from Chris Jerdonek: It would be nice if the first sentence of the documentation for the open() built-in function: "Open file and return a corresponding stream. If the file cannot be opened, an OSError is raised." http://docs.python.org/dev/library/functions.html#open linked to the glossary entry for "file object": http://docs.python.org/dev/glossary.html#term-file-object Incidentally, this would be similar to what was done 2.7 documentation of open(): http://docs.python.org/library/functions.html#open Similarly, the introductory overview section of the io module should also link to the glossary entry for "file object": "Concrete objects belonging to any of these categories will often be called streams; another common term is file-like objects." (from http://docs.python.org/dev/library/io.html#overview ) ---------- assignee: docs at python components: Documentation messages: 168392 nosy: cjerdonek, docs at python priority: normal severity: normal status: open title: link to "file object" glossary entry in open() and io docs type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 18:06:44 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 16 Aug 2012 16:06:44 +0000 Subject: [issue15694] link to "file object" glossary entry in open() and io docs In-Reply-To: <1345133191.76.0.682782918752.issue15694@psf.upfronthosting.co.za> Message-ID: <1345133204.15.0.532926974744.issue15694@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- keywords: +easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 18:12:10 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 16 Aug 2012 16:12:10 +0000 Subject: [issue15693] expose glossary link on hover In-Reply-To: <1345132108.78.0.567099034623.issue15693@psf.upfronthosting.co.za> Message-ID: <1345133530.82.0.983839586419.issue15693@psf.upfronthosting.co.za> R. David Murray added the comment: We do pin it, but we generally have no problem with upgrading. I think we generally upgrade it exactly when there is a new Sphinx feature we want for our docs :) We don't maintain local patches to Sphinx (though we do have code that is specific to our docs, using Sphinx's extension mechanisms). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 18:18:49 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 16 Aug 2012 16:18:49 +0000 Subject: [issue15693] expose glossary link on hover In-Reply-To: <1345132108.78.0.567099034623.issue15693@psf.upfronthosting.co.za> Message-ID: <1345133929.43.0.823845880197.issue15693@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > I think we generally upgrade it exactly when there is a new Sphinx feature we want for our docs :) :) Would the appropriate way to handle it be then to create an issue to "upgrade Sphinx when XXX issue is resolved" and link to the corresponding Sphinx issue? I also see value in Python being able to track and possibly assist Sphinx in fixing an issue that we want. Incidentally, issue 15455 may fall into the same category now that I know more. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 18:40:13 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 16 Aug 2012 16:40:13 +0000 Subject: [issue15693] expose glossary link on hover In-Reply-To: <1345132108.78.0.567099034623.issue15693@psf.upfronthosting.co.za> Message-ID: <1345135213.12.0.127011378241.issue15693@psf.upfronthosting.co.za> R. David Murray added the comment: Well, I think it depends on what we consider the priority of the issue. So, I personally would count this one as low, and would be happy that it gets fixed whenever we happen to upgrade to a version of Sphinx that fixes it. If it is an issue we consider higher priority, then yes linking to the corresponding Sphinx issue here would be appropriate, and we have done that in the past. (My notions are of course not the sole determining factor on the priority.) In case you don't know, Georg is the primary author/maintainer of Sphinx, and I'm sure he'll be happy for any help you (or others) want to provide :). By the way, although I use it on my own site I'm not by any means a Sphinx expert, so my thoughts about where this should be changed could be wrong. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 20:06:49 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Thu, 16 Aug 2012 18:06:49 +0000 Subject: [issue6484] No unit test for mailcap module In-Reply-To: <1247596747.53.0.161658367753.issue6484@psf.upfronthosting.co.za> Message-ID: <1345140409.25.0.112460183029.issue6484@psf.upfronthosting.co.za> Petri Lehtinen added the comment: Any reason why this hasn't been backported to 3.2 or 2.7? ---------- nosy: +petri.lehtinen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 20:11:36 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 16 Aug 2012 18:11:36 +0000 Subject: [issue6484] No unit test for mailcap module In-Reply-To: <1247596747.53.0.161658367753.issue6484@psf.upfronthosting.co.za> Message-ID: <1345140696.84.0.278731024631.issue6484@psf.upfronthosting.co.za> R. David Murray added the comment: There are divided opinions about the advisability of backporting tests that are not part of a bug fix. In this case, there is also the fact that it includes a test that fails without a bug fix that was not backported. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 21:10:30 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 16 Aug 2012 19:10:30 +0000 Subject: [issue15693] expose glossary link on hover In-Reply-To: <1345132108.78.0.567099034623.issue15693@psf.upfronthosting.co.za> Message-ID: <1345144230.77.0.297343157808.issue15693@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I created a Sphinx issue for this here: https://bitbucket.org/birkenfeld/sphinx/issue/996/expose-glossary-entry-link-on-hover ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 21:13:36 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 16 Aug 2012 19:13:36 +0000 Subject: [issue15695] Correct __sizeof__ support for StgDict Message-ID: <1345144416.71.0.984691068113.issue15695@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Here is a patch that implements correct __sizeof__ for StgDict (a dictionary subclass used in ctypes). There are no tests because I don't know how to create and use StgDict. So I'm not sure that the code works correctly. Please help me with tests. ---------- components: Library (Lib) files: stgdict_sizeof-3.3.patch keywords: patch messages: 168399 nosy: amaury.forgeotdarc, belopolsky, meador.inge, storchaka priority: normal severity: normal stage: patch review status: open title: Correct __sizeof__ support for StgDict type: behavior versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file26854/stgdict_sizeof-3.3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 21:14:08 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 16 Aug 2012 19:14:08 +0000 Subject: [issue15695] Correct __sizeof__ support for StgDict In-Reply-To: <1345144416.71.0.984691068113.issue15695@psf.upfronthosting.co.za> Message-ID: <1345144448.42.0.392585084809.issue15695@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file26855/stgdict_sizeof-3.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 21:15:07 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 16 Aug 2012 19:15:07 +0000 Subject: [issue15695] Correct __sizeof__ support for StgDict In-Reply-To: <1345144416.71.0.984691068113.issue15695@psf.upfronthosting.co.za> Message-ID: <1345144507.89.0.972721637187.issue15695@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: patch review -> test needed Added file: http://bugs.python.org/file26856/stgdict_sizeof-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 21:17:27 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 16 Aug 2012 19:17:27 +0000 Subject: [issue15455] index entries not showing up in glossary In-Reply-To: <1343292936.36.0.839564467916.issue15455@psf.upfronthosting.co.za> Message-ID: <1345144647.03.0.748807205622.issue15455@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I created a Sphinx issue for this here: https://bitbucket.org/birkenfeld/sphinx/issue/997/index-targets-not-getting-created-in ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 21:31:34 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 16 Aug 2012 19:31:34 +0000 Subject: [issue15694] link to "file object" glossary entry in open() and io docs In-Reply-To: <1345133191.76.0.682782918752.issue15694@psf.upfronthosting.co.za> Message-ID: <1345145494.59.0.875369672824.issue15694@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Attaching patch. I also added two index entries for "file object" and made a couple wording adjustments to the intro paragraph of the io module. ---------- keywords: +patch stage: -> patch review versions: +Python 3.2 Added file: http://bugs.python.org/file26857/issue-15694-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 21:31:39 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 16 Aug 2012 19:31:39 +0000 Subject: [issue15696] Correct __sizeof__ support for mmap Message-ID: <1345145499.47.0.489635799937.issue15696@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Here is a patch that implements correct __sizeof__ for mmap under Windows. I have not tested it because it is Windows-only issue. Please test it. ---------- components: Library (Lib), Windows files: mmap_sizeof-3.x.patch keywords: patch messages: 168402 nosy: storchaka priority: normal severity: normal status: open title: Correct __sizeof__ support for mmap versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file26858/mmap_sizeof-3.x.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 21:32:24 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 16 Aug 2012 19:32:24 +0000 Subject: [issue15696] Correct __sizeof__ support for mmap In-Reply-To: <1345145499.47.0.489635799937.issue15696@psf.upfronthosting.co.za> Message-ID: <1345145544.14.0.98979808832.issue15696@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file26859/mmap_sizeof-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 21:37:27 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 16 Aug 2012 19:37:27 +0000 Subject: [issue15696] Correct __sizeof__ support for mmap In-Reply-To: <1345145499.47.0.489635799937.issue15696@psf.upfronthosting.co.za> Message-ID: <1345145847.01.0.515266452934.issue15696@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: -> patch review type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 21:42:50 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 16 Aug 2012 19:42:50 +0000 Subject: [issue15625] Support u and w codes in memoryview In-Reply-To: <1344719787.86.0.485615026169.issue15625@psf.upfronthosting.co.za> Message-ID: <1345146170.8.0.241030331865.issue15625@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 21:44:37 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 16 Aug 2012 19:44:37 +0000 Subject: [issue15035] array.array of UCS2 values In-Reply-To: <1339147370.98.0.5823346157.issue15035@psf.upfronthosting.co.za> Message-ID: <1345146277.64.0.269648249307.issue15035@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 21:47:53 2012 From: report at bugs.python.org (Robin Schreiber) Date: Thu, 16 Aug 2012 19:47:53 +0000 Subject: [issue15697] PEP 3121 refactoring applied to pwd module Message-ID: <1345146472.99.0.450289405214.issue15697@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 have now been applied to the pwd module! ---------- components: Extension Modules files: pwd_pep3121_v0.patch keywords: patch messages: 168403 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121 refactoring applied to pwd module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26860/pwd_pep3121_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 21:55:01 2012 From: report at bugs.python.org (Robin Schreiber) Date: Thu, 16 Aug 2012 19:55:01 +0000 Subject: [issue15698] PEP 3121, 384 Refactoring applied to pyexpat module Message-ID: <1345146901.0.0.136939773234.issue15698@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the pyexpat module! ---------- components: Extension Modules files: pyexpat_pep3121-384_v0.patch keywords: patch messages: 168404 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121, 384 Refactoring applied to pyexpat module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26861/pyexpat_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 22:03:02 2012 From: report at bugs.python.org (Robin Schreiber) Date: Thu, 16 Aug 2012 20:03:02 +0000 Subject: [issue15699] PEP 3121, 384 Refactoring applied to readline module Message-ID: <1345147381.91.0.560597639191.issue15699@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the readline module! ---------- components: Extension Modules files: readline_pep3121-384_v0.patch keywords: patch messages: 168405 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121, 384 Refactoring applied to readline module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26862/readline_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 22:07:56 2012 From: report at bugs.python.org (Robin Schreiber) Date: Thu, 16 Aug 2012 20:07:56 +0000 Subject: [issue15700] PEP 3121, 384 Refactoring applied to resource module Message-ID: <1345147675.99.0.556449209112.issue15700@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the resource module! ---------- components: Extension Modules files: resource_pep3121-384_v0.patch keywords: patch messages: 168406 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121, 384 Refactoring applied to resource module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26863/resource_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 22:35:57 2012 From: report at bugs.python.org (Jody McIntyre) Date: Thu, 16 Aug 2012 20:35:57 +0000 Subject: [issue15701] AttributeError from HTTPError when using digest auth Message-ID: <1345149357.77.0.903430006119.issue15701@psf.upfronthosting.co.za> New submission from Jody McIntyre: I attempted to connect to a site using urllib2 and digest authentication and it raised an HTTPError (due to an incorrect username and password, which is expected). I attempted to run the info() method of the HTTPError to get more information, but it failed with an AttributeError (this is the bug). $ ./reproducer.py Traceback (most recent call last): File "./reproducer.py", line 16, in print e.info() File "/usr/lib/python2.6/urllib.py", line 987, in info return self.headers AttributeError: 'HTTPError' object has no attribute 'headers' $ python --version Python 2.6.6 ---------- files: reproducer.py messages: 168407 nosy: scjody priority: normal severity: normal status: open title: AttributeError from HTTPError when using digest auth type: crash versions: Python 2.6 Added file: http://bugs.python.org/file26864/reproducer.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 22:41:48 2012 From: report at bugs.python.org (James Hutchison) Date: Thu, 16 Aug 2012 20:41:48 +0000 Subject: [issue15702] Multiprocessing Pool deadlocks on join after empty map operation Message-ID: <1345149708.12.0.561360753996.issue15702@psf.upfronthosting.co.za> New submission from James Hutchison: Following code deadlocks on Windows 7 64-bit, Python 3.2.3 If you have a pool issue a map operation over an empty iterable then try to join later, it will deadlock. If there is no map operation or blah in the code below isn't empty, it does not deadlock from multiprocessing import Pool def main(): p = Pool(); blah = []; print("Mapping"); p.map(dummy, blah); p.close(); p.join(); # deadlocks here print("Done"); def dummy(x): pass; if __name__ == "__main__": main(); ---------- components: Library (Lib) messages: 168408 nosy: Jimbofbx priority: normal severity: normal status: open title: Multiprocessing Pool deadlocks on join after empty map operation type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 22:57:36 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 16 Aug 2012 20:57:36 +0000 Subject: [issue15702] Multiprocessing Pool deadlocks on join after empty map operation In-Reply-To: <1345149708.12.0.561360753996.issue15702@psf.upfronthosting.co.za> Message-ID: <1345150656.82.0.37716496136.issue15702@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 22:58:28 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 16 Aug 2012 20:58:28 +0000 Subject: [issue11062] mailbox fails to round-trip a file to a Babyl mailbox In-Reply-To: <1296317976.28.0.825353703674.issue11062@psf.upfronthosting.co.za> Message-ID: <1345150708.39.0.861443931879.issue11062@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Thank you, Petri. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 23:01:10 2012 From: report at bugs.python.org (Robin Schreiber) Date: Thu, 16 Aug 2012 21:01:10 +0000 Subject: [issue15703] PEP 3121, 384 Refactoring applied to select module Message-ID: <1345150869.96.0.605458116599.issue15703@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the select module! ---------- components: Extension Modules files: select_pep3121-384_v0.patch keywords: patch messages: 168410 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121, 384 Refactoring applied to select module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26865/select_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 23:03:54 2012 From: report at bugs.python.org (Robin Schreiber) Date: Thu, 16 Aug 2012 21:03:54 +0000 Subject: [issue15704] PEP 3121, 384 Refactoring applied to sha1 module Message-ID: <1345151034.85.0.141930979711.issue15704@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the sha1 module! ---------- components: Extension Modules files: sha1_pep3121-384_v0.patch keywords: patch messages: 168411 nosy: Robin.Schreiber, gregory.p.smith priority: normal severity: normal status: open title: PEP 3121, 384 Refactoring applied to sha1 module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26866/sha1_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 23:07:34 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 16 Aug 2012 21:07:34 +0000 Subject: [issue6696] Profile objects should be documented In-Reply-To: <1250182637.82.0.304646827828.issue6696@psf.upfronthosting.co.za> Message-ID: <1345151254.43.0.75556081608.issue6696@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 23:08:59 2012 From: report at bugs.python.org (Robin Schreiber) Date: Thu, 16 Aug 2012 21:08:59 +0000 Subject: [issue15705] PEP 3121, 384 Refactoring applied to sha256 module Message-ID: <1345151339.81.0.44810343177.issue15705@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the sha256 module! ---------- components: Extension Modules files: sha256_pep3121-384_v0.patch keywords: patch messages: 168412 nosy: Robin.Schreiber, gregory.p.smith priority: normal severity: normal status: open title: PEP 3121, 384 Refactoring applied to sha256 module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26867/sha256_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 23:12:53 2012 From: report at bugs.python.org (Robin Schreiber) Date: Thu, 16 Aug 2012 21:12:53 +0000 Subject: [issue15706] PEP 3121, 384 Refactoring applied to sha512 module Message-ID: <1345151573.12.0.0841074756342.issue15706@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the sha512 module! ---------- components: Extension Modules files: sha512_pep3121-384_v0.patch keywords: patch messages: 168413 nosy: Robin.Schreiber, gregory.p.smith priority: normal severity: normal status: open title: PEP 3121, 384 Refactoring applied to sha512 module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26868/sha512_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 23:16:04 2012 From: report at bugs.python.org (Jeff Knupp) Date: Thu, 16 Aug 2012 21:16:04 +0000 Subject: [issue15702] Multiprocessing Pool deadlocks on join after empty map operation In-Reply-To: <1345149708.12.0.561360753996.issue15702@psf.upfronthosting.co.za> Message-ID: <1345151764.09.0.476879321202.issue15702@psf.upfronthosting.co.za> Jeff Knupp added the comment: This is a duplicate of http://bugs.python.org/issue12157, which was fixed. ---------- nosy: +Jeff.Knupp _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 23:19:27 2012 From: report at bugs.python.org (Robin Schreiber) Date: Thu, 16 Aug 2012 21:19:27 +0000 Subject: [issue15707] PEP 3121, 384 Refactoring applied to signal module Message-ID: <1345151967.47.0.247832517362.issue15707@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the signal module! ---------- components: Extension Modules files: signal_pep3121-384_v0.patch keywords: patch messages: 168415 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121, 384 Refactoring applied to signal module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26869/signal_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 23:26:28 2012 From: report at bugs.python.org (Robin Schreiber) Date: Thu, 16 Aug 2012 21:26:28 +0000 Subject: [issue15708] PEP 3121, 384 Refactoring applied to socket module Message-ID: <1345152388.23.0.37223742756.issue15708@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the socket module! ---------- components: Extension Modules files: socket_pep3121-384_v0.patch keywords: patch messages: 168416 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121, 384 Refactoring applied to socket module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26870/socket_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 23:32:49 2012 From: report at bugs.python.org (Robin Schreiber) Date: Thu, 16 Aug 2012 21:32:49 +0000 Subject: [issue15709] PEP 3121, 384 Refactoring applied to termios module Message-ID: <1345152769.02.0.418210098076.issue15709@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the termios module! ---------- components: Extension Modules files: termios_pep3121-384_v0.patch keywords: patch messages: 168417 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121, 384 Refactoring applied to termios module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26871/termios_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 23:33:59 2012 From: report at bugs.python.org (Tobin Baker) Date: Thu, 16 Aug 2012 21:33:59 +0000 Subject: [issue15710] logging module crashes in Python 2.7.3 for handler.setLevel(long) Message-ID: <1345152839.48.0.661799461902.issue15710@psf.upfronthosting.co.za> New submission from Tobin Baker: I'm using a 3rd-party library (ESAPI) which defines a log level as the literal -2**31. This worked fine until I upgraded to Python 2.7.3, which, unlike all previous versions of Python, coerces that literal to long rather than int. The following code in the logging module then throws a TypeError: def _checkLevel(level): if isinstance(level, int): rv = level elif str(level) == level: if level not in _levelNames: raise ValueError("Unknown level: %r" % level) rv = _levelNames[level] else: raise TypeError("Level not an integer or a valid string: %r" % level) return rv Although this is certainly an unusual use case, it seems that as just a matter of principle, the module should be using the check isinstance(level, (int, long)) rather than just isinstance(level, int). Here's the relevant part of the traceback: File "/usr/lib/python2.7/logging/__init__.py", line 710, in setLevel self.level = _checkLevel(level) File "/usr/lib/python2.7/logging/__init__.py", line 190, in _checkLevel raise TypeError("Level not an integer or a valid string: %r" % level) TypeError: Level not an integer or a valid string: -2147483648L ---------- components: Library (Lib) messages: 168418 nosy: tobin.baker priority: normal severity: normal status: open title: logging module crashes in Python 2.7.3 for handler.setLevel(long) type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 23:34:52 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 16 Aug 2012 21:34:52 +0000 Subject: [issue15710] logging module crashes in Python 2.7.3 for handler.setLevel(long) In-Reply-To: <1345152839.48.0.661799461902.issue15710@psf.upfronthosting.co.za> Message-ID: <1345152892.88.0.38128880643.issue15710@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 23:36:08 2012 From: report at bugs.python.org (Robin Schreiber) Date: Thu, 16 Aug 2012 21:36:08 +0000 Subject: [issue15711] PEP 3121, 384 Refactoring applied to time module Message-ID: <1345152968.9.0.714502729899.issue15711@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the time module! ---------- components: Extension Modules files: time_pep3121-384_v0.patch keywords: patch messages: 168419 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121, 384 Refactoring applied to time module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26872/time_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 23:46:20 2012 From: report at bugs.python.org (Robin Schreiber) Date: Thu, 16 Aug 2012 21:46:20 +0000 Subject: [issue15712] PEP 3121, 384 Refactoring applied to unicodedata module Message-ID: <1345153580.3.0.0817770117233.issue15712@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the unicodedata module! ---------- components: Extension Modules files: unicodedate_pep3121-384_v0.patch keywords: patch messages: 168420 nosy: Robin.Schreiber, effbot, lemburg, loewis priority: normal severity: normal status: open title: PEP 3121, 384 Refactoring applied to unicodedata module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26873/unicodedate_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 23:53:56 2012 From: report at bugs.python.org (Robin Schreiber) Date: Thu, 16 Aug 2012 21:53:56 +0000 Subject: [issue15713] PEP 3121, 384 Refactoring applied to zipimport module Message-ID: <1345154035.4.0.564693100383.issue15713@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the zipimport module! ---------- components: Extension Modules files: zipimport_pep3121-384_v0.patch keywords: patch messages: 168421 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121, 384 Refactoring applied to zipimport module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26874/zipimport_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 16 23:55:58 2012 From: report at bugs.python.org (Robin Schreiber) Date: Thu, 16 Aug 2012 21:55:58 +0000 Subject: [issue15714] PEP 3121, 384 Refactoring applied to grp module Message-ID: <1345154158.03.0.0313015513164.issue15714@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the grp module! ---------- components: Extension Modules files: grp_pep3121-384_v0.patch keywords: patch messages: 168422 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121, 384 Refactoring applied to grp module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26875/grp_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 00:42:08 2012 From: report at bugs.python.org (Simon Feltman) Date: Thu, 16 Aug 2012 22:42:08 +0000 Subject: [issue15715] __import__ now raises with non-existing items in fromlist in 3.3 Message-ID: <1345156928.79.0.203974969225.issue15715@psf.upfronthosting.co.za> New submission from Simon Feltman: This came up while trying to build pygobject with Python 3.3. The problem is there are some erroneous imports in the fromlist with these bindings that can easily be fixed. But it is a behavioral change so I just wanted to raise awareness if it is not already known. $ python3.2 -c "__import__('http', fromlist=['blah'])" (works) $ python3.3 -c "__import__('http', fromlist=['blah'])" Traceback (most recent call last): File "", line 1, in ImportError: No module named 'http.blah' Note this is also the case when using the C API: PyImport_ImportModuleEx ---------- components: None messages: 168423 nosy: sfeltman priority: normal severity: normal status: open title: __import__ now raises with non-existing items in fromlist in 3.3 versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 00:50:31 2012 From: report at bugs.python.org (Simon Feltman) Date: Thu, 16 Aug 2012 22:50:31 +0000 Subject: [issue15715] __import__ now raises with non-existing items in fromlist in 3.3 In-Reply-To: <1345156928.79.0.203974969225.issue15715@psf.upfronthosting.co.za> Message-ID: <1345157431.28.0.861759902787.issue15715@psf.upfronthosting.co.za> Changes by Simon Feltman : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 01:14:42 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 16 Aug 2012 23:14:42 +0000 Subject: [issue15715] __import__ now raises with non-existing items in fromlist in 3.3 In-Reply-To: <1345156928.79.0.203974969225.issue15715@psf.upfronthosting.co.za> Message-ID: <1345158882.66.0.441315747075.issue15715@psf.upfronthosting.co.za> Eric Snow added the comment: While this is a regression, 3.3 definitely puts an increased emphasis on using importlib.import_module() instead of builtins.__import__(). Any reason why import_module() isn't used? As to the regression, while the current behavior makes more sense, it is contrary to a common idiom when using __import__(). However, given the push away from using __import__(), perhaps it can just stay this way. Oh backward compatibility... ---------- nosy: +brett.cannon, eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 01:31:23 2012 From: report at bugs.python.org (Simon Feltman) Date: Thu, 16 Aug 2012 23:31:23 +0000 Subject: [issue15715] __import__ now raises with non-existing items in fromlist in 3.3 In-Reply-To: <1345156928.79.0.203974969225.issue15715@psf.upfronthosting.co.za> Message-ID: <1345159883.01.0.0536098267623.issue15715@psf.upfronthosting.co.za> Simon Feltman added the comment: I think pygobject still supports Python 2.5 which it look like importlib is available. I've submitted a patch to pygobject which will work regardless of if this regression is fixed or not: https://bugzilla.gnome.org/show_bug.cgi?id=682051 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 01:32:35 2012 From: report at bugs.python.org (Simon Feltman) Date: Thu, 16 Aug 2012 23:32:35 +0000 Subject: [issue15715] __import__ now raises with non-existing items in fromlist in 3.3 In-Reply-To: <1345156928.79.0.203974969225.issue15715@psf.upfronthosting.co.za> Message-ID: <1345159955.69.0.111135146602.issue15715@psf.upfronthosting.co.za> Simon Feltman added the comment: Should have been "...Python 2.5 which it looks like importlib is NOT available." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 01:57:16 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 16 Aug 2012 23:57:16 +0000 Subject: [issue15715] __import__ now raises with non-existing items in fromlist in 3.3 In-Reply-To: <1345156928.79.0.203974969225.issue15715@psf.upfronthosting.co.za> Message-ID: <1345161436.2.0.665912017575.issue15715@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Unless it is difficult to fix, I think this regression should be addressed before 3.3 final. Georg? ---------- components: +Interpreter Core, Library (Lib) -None nosy: +pitrou priority: normal -> release blocker stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 01:57:22 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 16 Aug 2012 23:57:22 +0000 Subject: [issue15715] __import__ now raises with non-existing items in fromlist in 3.3 In-Reply-To: <1345156928.79.0.203974969225.issue15715@psf.upfronthosting.co.za> Message-ID: <1345161442.76.0.45449306972.issue15715@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 02:39:41 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 17 Aug 2012 00:39:41 +0000 Subject: [issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation In-Reply-To: <1322181994.22.0.955887054946.issue13475@psf.upfronthosting.co.za> Message-ID: <1345163981.52.0.990468323456.issue13475@psf.upfronthosting.co.za> Gregory P. Smith added the comment: I'd also like a command line flag to override PYTHONPATH (which could also be used in combination with -E so that you could still set the PYTHONPATH while ignoring everything else). I'll file a separate feature request for that. ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 02:40:27 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 17 Aug 2012 00:40:27 +0000 Subject: [issue15716] Ability to specify the PYTHONPATH via a command line flag Message-ID: <1345164027.44.0.397805734201.issue15716@psf.upfronthosting.co.za> New submission from Gregory P. Smith: I'd like a command line flag to override PYTHONPATH. It could also be used in combination with -E so that you could still set the PYTHONPATH while ignoring everything else from the environment. ---------- messages: 168429 nosy: gregory.p.smith priority: normal severity: normal status: open title: Ability to specify the PYTHONPATH via a command line flag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 03:47:27 2012 From: report at bugs.python.org (Eric Snow) Date: Fri, 17 Aug 2012 01:47:27 +0000 Subject: [issue15716] Ability to specify the PYTHONPATH via a command line flag In-Reply-To: <1345164027.44.0.397805734201.issue15716@psf.upfronthosting.co.za> Message-ID: <1345168047.47.0.0972105012607.issue15716@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 05:18:22 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 17 Aug 2012 03:18:22 +0000 Subject: [issue15355] generator docs should mention already-executing exception In-Reply-To: <1342312261.31.0.534711044354.issue15355@psf.upfronthosting.co.za> Message-ID: <1345173502.17.0.884510478474.issue15355@psf.upfronthosting.co.za> R. David Murray added the comment: Chris, if Nick is too busy to reply right now and you want to move this along, you could write some tests (not necessarily for inclusion in the test suite) to confirm that the doc you are adding is correct. I don't know enough about generators to comment myself, I'd have to write tests :) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 06:34:27 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Fri, 17 Aug 2012 04:34:27 +0000 Subject: [issue4253] Maildir dumpmessage on In-Reply-To: <1225700324.91.0.938996340802.issue4253@psf.upfronthosting.co.za> Message-ID: <1345178067.05.0.077832664633.issue4253@psf.upfronthosting.co.za> Petri Lehtinen added the comment: No reply in two years, closing. ---------- nosy: +petri.lehtinen resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 07:04:23 2012 From: report at bugs.python.org (Eric Snow) Date: Fri, 17 Aug 2012 05:04:23 +0000 Subject: [issue15715] __import__ now raises with non-existing items in fromlist in 3.3 In-Reply-To: <1345156928.79.0.203974969225.issue15715@psf.upfronthosting.co.za> Message-ID: <1345179863.32.0.111937043219.issue15715@psf.upfronthosting.co.za> Eric Snow added the comment: The failure output with -v: ... # /home/esnow/projects/cpython/Lib/http/__pycache__/__init__.cpython-33.pyc matches /home/esnow/projects/cpython/Lib/http/__init__.py # code object from /home/esnow/projects/cpython/Lib/http/__pycache__/__init__.cpython-33.pyc import 'http' # <_frozen_importlib.SourceFileLoader object at 0x7ff82770d450> Traceback (most recent call last): File "", line 1, in File "", line 1578, in _handle_fromlist File "", line 310, in _call_with_frames_removed File "", line 1530, in _find_and_load File "", line 1494, in _find_and_load_unlocked ImportError: No module named 'http.blah' ... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 07:35:34 2012 From: report at bugs.python.org (Eric Snow) Date: Fri, 17 Aug 2012 05:35:34 +0000 Subject: [issue15715] __import__ now raises with non-existing items in fromlist in 3.3 In-Reply-To: <1345156928.79.0.203974969225.issue15715@psf.upfronthosting.co.za> Message-ID: <1345181734.54.0.659810286683.issue15715@psf.upfronthosting.co.za> Eric Snow added the comment: Here's a simple patch the allows bogus names in the fromlist. I'm going to verify that this matches the 3.2 semantics, which may not be so cut-and-dry. ---------- keywords: +patch Added file: http://bugs.python.org/file26876/issue15715.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 08:01:43 2012 From: report at bugs.python.org (Eric Snow) Date: Fri, 17 Aug 2012 06:01:43 +0000 Subject: [issue15715] __import__ now raises with non-existing items in fromlist in 3.3 In-Reply-To: <1345156928.79.0.203974969225.issue15715@psf.upfronthosting.co.za> Message-ID: <1345183303.01.0.117761664839.issue15715@psf.upfronthosting.co.za> Eric Snow added the comment: The following seems to indicate that an ImportError should be raised as expected. I'm guessing that somewhere along the line the exception gets silently eaten. ------------------ (3.2) Python/import.c:ensure_fromlist() [1] submod = import_submodule(mod, subname, buf); Py_DECREF(item8); Py_XDECREF(submod); if (submod == NULL) { Py_DECREF(item); return 0; } [1] http://hg.python.org/cpython/file/3.2/Python/import.c#l2875 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 08:19:24 2012 From: report at bugs.python.org (Georg Brandl) Date: Fri, 17 Aug 2012 06:19:24 +0000 Subject: [issue15715] __import__ now raises with non-existing items in fromlist in 3.3 In-Reply-To: <1345156928.79.0.203974969225.issue15715@psf.upfronthosting.co.za> Message-ID: <1345184364.69.0.472623643777.issue15715@psf.upfronthosting.co.za> Georg Brandl added the comment: I agree that we should match 3.2 behavior here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 10:24:53 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 17 Aug 2012 08:24:53 +0000 Subject: [issue15668] PEP 3121, 384 Refactoring applied to random module In-Reply-To: <1345039836.78.0.438193538839.issue15668@psf.upfronthosting.co.za> Message-ID: <1345191893.94.0.912731069487.issue15668@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Sure; I've mentored Robin throughout the summer with this, and this is his GSoC project. As for the specific change: this is primarily to support PEP 3121, and allowing multiple interpreters to use a module without fear of global variables being shared across interpreters. In the current implementation, the Random type would be shared across all interpreters, with the change, each interpreter gets its own copy of the Random type. For that, the type needs to become a heap type, which is best done with the PEP 384 API (even though ABI stability is irrelevant for the random module). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 12:21:05 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Fri, 17 Aug 2012 10:21:05 +0000 Subject: [issue14977] mailcap does not respect precedence in the presence of wildcards In-Reply-To: <1338542933.25.0.233529643572.issue14977@psf.upfronthosting.co.za> Message-ID: <1345198865.41.0.487135704267.issue14977@psf.upfronthosting.co.za> Petri Lehtinen added the comment: Sounds like a bug to me. It's not too straightforward to fix, though. The order of MIME types is lost because they are stored as keys of a dict. AFAICS, it wouldn't help to use OrderedDict and checking for the wildcard type first if its index is smaller. Example: image/*; foo %s; test=/bin/false image/jpeg; bar %s; test=/bin/true image/*; baz %s; test=/bin/true In this case, the image/jpeg entry should be returned, but both image/* entries get grouped together, so they would be evaluated first and the "baz %s" entry would be returned. The API expects the result of getcaps() (a dict) to be passed to findmatch(), which makes it very hard to change the caps representation. The only way I can think of would be to change the representation to a dict subclass with extra semantics. Plain dict would still have to be supported for backwards compatibility, though. ---------- nosy: +petri.lehtinen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 12:22:33 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Fri, 17 Aug 2012 10:22:33 +0000 Subject: [issue14977] mailcap does not respect precedence in the presence of wildcards In-Reply-To: <1338542933.25.0.233529643572.issue14977@psf.upfronthosting.co.za> Message-ID: <1345198953.16.0.165815662659.issue14977@psf.upfronthosting.co.za> Changes by Petri Lehtinen : ---------- keywords: -easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 13:17:37 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 17 Aug 2012 11:17:37 +0000 Subject: [issue15702] Multiprocessing Pool deadlocks on join after empty map operation In-Reply-To: <1345149708.12.0.561360753996.issue15702@psf.upfronthosting.co.za> Message-ID: <1345202257.36.0.798820989862.issue15702@psf.upfronthosting.co.za> Changes by Richard Oudkerk : ---------- resolution: -> duplicate stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 13:17:59 2012 From: report at bugs.python.org (Rostyslav Dzinko) Date: Fri, 17 Aug 2012 11:17:59 +0000 Subject: [issue15718] Possible OverflowError in __len__ method undocumented (when called via len() function) Message-ID: <1345202279.02.0.767068523185.issue15718@psf.upfronthosting.co.za> New submission from Rostyslav Dzinko: I've encountered that OverflowError which can happen in __len__ method is still undocumented, though one issue on this problem: http://bugs.python.org/issue12159 ended up with "need to be documented" comment. Link to documentation: http://docs.python.org/reference/datamodel.html#object.__len__ I think it must be clarified that __len__ return value is constrained to upper boundary (Py_ssize_t c type) when you plan to call it via len() built-in function. ---------- assignee: docs at python components: Documentation messages: 168439 nosy: Rostyslav.Dzinko, docs at python priority: normal severity: normal status: open title: Possible OverflowError in __len__ method undocumented (when called via len() function) versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 13:18:15 2012 From: report at bugs.python.org (Rostyslav Dzinko) Date: Fri, 17 Aug 2012 11:18:15 +0000 Subject: [issue15718] Possible OverflowError in __len__ method undocumented (when called via len() function) In-Reply-To: <1345202279.02.0.767068523185.issue15718@psf.upfronthosting.co.za> Message-ID: <1345202295.62.0.562462463603.issue15718@psf.upfronthosting.co.za> Changes by Rostyslav Dzinko : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 13:48:31 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 17 Aug 2012 11:48:31 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1345204111.42.0.419684326018.issue15573@psf.upfronthosting.co.za> Stefan Krah added the comment: There is still one corner case involving NaNs: Released memoryviews always compare equal. I took that over from the 3.2 implementation. >>> import array >>> a = array.array('d', [float('nan')]) >>> m = memoryview(a) >>> m == m False >>> m.release() >>> m == m True I guess we have to live with that, since it is of course impossible to access the values of a released view. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 14:25:03 2012 From: report at bugs.python.org (Florent Xicluna) Date: Fri, 17 Aug 2012 12:25:03 +0000 Subject: [issue15635] memory leak with generators In-Reply-To: <1344849931.31.0.449386115809.issue15635@psf.upfronthosting.co.za> Message-ID: <1345206303.48.0.87774157841.issue15635@psf.upfronthosting.co.za> Florent Xicluna added the comment: Thank you for digging into this. I close the issue. I discover now that this kind of problem is quite common in the Mac world. Other references: http://news.ycombinator.com/item?id=3879194 http://www.markvanda.net/apple/mac-os-x-memory-issues/ ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 15:07:57 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 17 Aug 2012 13:07:57 +0000 Subject: [issue15528] Better support for finalization with weakrefs In-Reply-To: <1343837927.06.0.561023898829.issue15528@psf.upfronthosting.co.za> Message-ID: <1345208877.33.0.70915912427.issue15528@psf.upfronthosting.co.za> Richard Oudkerk added the comment: Updated patch. ---------- Added file: http://bugs.python.org/file26879/finalize.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 15:43:36 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 17 Aug 2012 13:43:36 +0000 Subject: [issue14501] Error initialising BaseManager class with 'authkey' argument of string type. In-Reply-To: <1333608355.05.0.964001699487.issue14501@psf.upfronthosting.co.za> Message-ID: <3Wz5GZ51wMzPyX@mail.python.org> Roundup Robot added the comment: New changeset 636f75da4b9e by Richard Oudkerk in branch '3.2': Issue #14501: Clarify that authentication keys are byte strings http://hg.python.org/cpython/rev/636f75da4b9e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 15:52:24 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 17 Aug 2012 13:52:24 +0000 Subject: [issue14501] Error initialising BaseManager class with 'authkey' argument of string type. In-Reply-To: <1333608355.05.0.964001699487.issue14501@psf.upfronthosting.co.za> Message-ID: <1345211544.87.0.961346577508.issue14501@psf.upfronthosting.co.za> Richard Oudkerk added the comment: I have fixed the documentation and examples to say that authentication keys are byte strings. ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 16:03:21 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 17 Aug 2012 14:03:21 +0000 Subject: [issue15477] test_cmath failures on OS X 10.8 In-Reply-To: <1343469837.83.0.840988569572.issue15477@psf.upfronthosting.co.za> Message-ID: <1345212201.47.0.695862209905.issue15477@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Without looking into the details of the issue: conditionalizing a work-around on OSX sounds right. On the one hand, it may penalize OSX releases which get it right. OTOH, it's all Apple's fault (IIUC), so they deserve it :-) Further, using a build-time check for the OS release is inappropriate, since the binary should work on other releases as well; a run-time check is probably more costly than the work-around. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 16:06:50 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 17 Aug 2012 14:06:50 +0000 Subject: [issue15412] Note in documentation for weakrefs In-Reply-To: <1342863718.26.0.49587627068.issue15412@psf.upfronthosting.co.za> Message-ID: <3Wz5nN6ZKmzQ0J@mail.python.org> Roundup Robot added the comment: New changeset 78b0f294674c by Richard Oudkerk in branch '2.7': Issue #15412: Remove erroneous note about weakrefs http://hg.python.org/cpython/rev/78b0f294674c New changeset 24b13be81d61 by Richard Oudkerk in branch '3.2': Issue #15412: Remove erroneous note about weakrefs http://hg.python.org/cpython/rev/24b13be81d61 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 16:08:30 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 17 Aug 2012 14:08:30 +0000 Subject: [issue15412] Note in documentation for weakrefs In-Reply-To: <1342863718.26.0.49587627068.issue15412@psf.upfronthosting.co.za> Message-ID: <1345212510.16.0.130915408532.issue15412@psf.upfronthosting.co.za> Changes by Richard Oudkerk : ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 18:08:35 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 17 Aug 2012 16:08:35 +0000 Subject: [issue15715] __import__ now raises with non-existing items in fromlist in 3.3 In-Reply-To: <1345156928.79.0.203974969225.issue15715@psf.upfronthosting.co.za> Message-ID: <1345219715.45.0.164558074799.issue15715@psf.upfronthosting.co.za> Brett Cannon added the comment: And this is why we have said people should use the idiom of ``__import__('http.blah'); mod = sys.modules['http.blah']`` if importlib is not used (which is on PyPI and works as far back as Python 2.3), else you will deal with an AttributeError later instead of an ImportError upfront. Darn backwards-compatibility. Eric's patch looks fine, so I will get it committed today. ---------- assignee: -> brett.cannon stage: needs patch -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 18:20:01 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 17 Aug 2012 16:20:01 +0000 Subject: [issue15627] Add a method to importlib.abc.SourceLoader for converting source to a code object In-Reply-To: <1344732276.83.0.543554641885.issue15627@psf.upfronthosting.co.za> Message-ID: <1345220401.64.0.938148269786.issue15627@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 18:28:09 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 17 Aug 2012 16:28:09 +0000 Subject: [issue15640] Document importlib.abc.Finder as deprecated In-Reply-To: <1344887238.09.0.248857343378.issue15640@psf.upfronthosting.co.za> Message-ID: <1345220889.81.0.444798582313.issue15640@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 18:34:00 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 17 Aug 2012 16:34:00 +0000 Subject: [issue15641] Clean up importlib for Python 3.4 In-Reply-To: <1344888035.57.0.935580041455.issue15641@psf.upfronthosting.co.za> Message-ID: <1345221240.81.0.408032952805.issue15641@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 18:34:46 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 17 Aug 2012 16:34:46 +0000 Subject: [issue15642] Integrate pickle protocol version 4 GSoC work by Stefan Mihaila In-Reply-To: <1344890920.23.0.695633734046.issue15642@psf.upfronthosting.co.za> Message-ID: <1345221286.01.0.574685250591.issue15642@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 18:36:00 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 17 Aug 2012 16:36:00 +0000 Subject: [issue15645] 2to3 Grammar pickles not created when upgrading to 3.3.0b2 In-Reply-To: <1344932180.41.0.826216341416.issue15645@psf.upfronthosting.co.za> Message-ID: <1345221360.61.0.339226099941.issue15645@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 18:36:40 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 17 Aug 2012 16:36:40 +0000 Subject: [issue15650] PEP 3121, 384 refactoring applied to dbm module In-Reply-To: <1344968074.48.0.47544287235.issue15650@psf.upfronthosting.co.za> Message-ID: <1345221400.42.0.846058521954.issue15650@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 18:36:58 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 17 Aug 2012 16:36:58 +0000 Subject: [issue15651] PEP 3121, 384 refactoring applied to elementtree module In-Reply-To: <1344968721.44.0.689766020196.issue15651@psf.upfronthosting.co.za> Message-ID: <1345221418.74.0.204124738421.issue15651@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 18:37:05 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 17 Aug 2012 16:37:05 +0000 Subject: [issue15653] PEP 3121, 384 refactoring applied to hashopenssl module In-Reply-To: <1344969733.85.0.308586175776.issue15653@psf.upfronthosting.co.za> Message-ID: <1345221425.86.0.281714239211.issue15653@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 18:37:26 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 17 Aug 2012 16:37:26 +0000 Subject: [issue15652] PEP 3121, 384 refactoring applied to gdbm module In-Reply-To: <1344969100.54.0.643991722265.issue15652@psf.upfronthosting.co.za> Message-ID: <1345221446.18.0.867696911863.issue15652@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 18:37:35 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 17 Aug 2012 16:37:35 +0000 Subject: [issue15654] PEP 384 Refactoring applied to bz2 module In-Reply-To: <1344970058.86.0.178955604138.issue15654@psf.upfronthosting.co.za> Message-ID: <1345221455.35.0.201337360298.issue15654@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 18:37:56 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 17 Aug 2012 16:37:56 +0000 Subject: [issue15655] PEP 384 Refactoring applied to json module In-Reply-To: <1344970398.16.0.223655068768.issue15655@psf.upfronthosting.co.za> Message-ID: <1345221476.0.0.689620028504.issue15655@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 18:39:29 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 17 Aug 2012 16:39:29 +0000 Subject: [issue15657] Error in Python 3 docs for PyMethodDef In-Reply-To: <1344970966.7.0.115664419243.issue15657@psf.upfronthosting.co.za> Message-ID: <1345221569.62.0.474356812047.issue15657@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 18:40:07 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 17 Aug 2012 16:40:07 +0000 Subject: [issue15662] PEP 3121 refactoring applied to locale module In-Reply-To: <1345021532.95.0.601509802957.issue15662@psf.upfronthosting.co.za> Message-ID: <1345221607.34.0.797368273034.issue15662@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 18:40:20 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 17 Aug 2012 16:40:20 +0000 Subject: [issue15665] PEP 3121, 384 refactoring applied to lsprof module In-Reply-To: <1345035962.65.0.979590709355.issue15665@psf.upfronthosting.co.za> Message-ID: <1345221620.6.0.659463603902.issue15665@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 18:40:36 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 17 Aug 2012 16:40:36 +0000 Subject: [issue15666] PEP 3121, 384 refactoring applied to lzma module In-Reply-To: <1345037071.28.0.307240191092.issue15666@psf.upfronthosting.co.za> Message-ID: <1345221636.9.0.357954366994.issue15666@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 18:40:48 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 17 Aug 2012 16:40:48 +0000 Subject: [issue15667] PEP 3121, 384 refactoring applied to pickle module In-Reply-To: <1345038957.09.0.78094807427.issue15667@psf.upfronthosting.co.za> Message-ID: <1345221648.95.0.270537195992.issue15667@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 18:40:57 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 17 Aug 2012 16:40:57 +0000 Subject: [issue15669] PEP 3121, 384 Refactoring applied to sre module In-Reply-To: <1345040333.3.0.897611485757.issue15669@psf.upfronthosting.co.za> Message-ID: <1345221657.93.0.495781782317.issue15669@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 18:41:04 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 17 Aug 2012 16:41:04 +0000 Subject: [issue15670] PEP 3121, 384 Refactoring applied to ssl module In-Reply-To: <1345041029.57.0.223670432026.issue15670@psf.upfronthosting.co.za> Message-ID: <1345221664.64.0.337444122137.issue15670@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 18:41:20 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 17 Aug 2012 16:41:20 +0000 Subject: [issue15671] PEP 3121, 384 Refactoring applied to struct module In-Reply-To: <1345041779.43.0.428829398339.issue15671@psf.upfronthosting.co.za> Message-ID: <1345221680.72.0.0230712678387.issue15671@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 18:41:31 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 17 Aug 2012 16:41:31 +0000 Subject: [issue15672] PEP 3121, 384 Refactoring applied to testbuffer module In-Reply-To: <1345042259.48.0.277311619921.issue15672@psf.upfronthosting.co.za> Message-ID: <1345221691.43.0.141144497158.issue15672@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 18:41:41 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 17 Aug 2012 16:41:41 +0000 Subject: [issue15673] PEP 3121, 384 Refactoring applied to testcapi module In-Reply-To: <1345042709.67.0.745658134358.issue15673@psf.upfronthosting.co.za> Message-ID: <1345221701.63.0.628660188469.issue15673@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 18:41:54 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 17 Aug 2012 16:41:54 +0000 Subject: [issue15674] PEP 3121, 384 Refactoring applied to thread module In-Reply-To: <1345043183.1.0.612175209954.issue15674@psf.upfronthosting.co.za> Message-ID: <1345221714.38.0.876446492589.issue15674@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 18:42:02 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 17 Aug 2012 16:42:02 +0000 Subject: [issue15675] PEP 3121, 384 Refactoring applied to array module In-Reply-To: <1345043626.95.0.208765115861.issue15675@psf.upfronthosting.co.za> Message-ID: <1345221722.79.0.300718745651.issue15675@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 19:21:24 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 17 Aug 2012 17:21:24 +0000 Subject: [issue15715] __import__ now raises with non-existing items in fromlist in 3.3 In-Reply-To: <1345156928.79.0.203974969225.issue15715@psf.upfronthosting.co.za> Message-ID: <3WzB5t60mfzPxN@mail.python.org> Roundup Robot added the comment: New changeset 0d52f125dd32 by Brett Cannon in branch 'default': Issue #15715: Ignore failed imports triggered by the use of fromlist. http://hg.python.org/cpython/rev/0d52f125dd32 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 19:21:49 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 17 Aug 2012 17:21:49 +0000 Subject: [issue15715] __import__ now raises with non-existing items in fromlist in 3.3 In-Reply-To: <1345156928.79.0.203974969225.issue15715@psf.upfronthosting.co.za> Message-ID: <1345224109.89.0.88164990552.issue15715@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 19:30:30 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 17 Aug 2012 17:30:30 +0000 Subject: [issue15653] PEP 3121, 384 refactoring applied to hashopenssl module In-Reply-To: <1344969733.85.0.308586175776.issue15653@psf.upfronthosting.co.za> Message-ID: <1345224630.27.0.0367899548305.issue15653@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Antoine: Py_DECREF calls tp_dealloc directly, so the type needs to be DECREFed in the course of tp_dealloc. I don't think there is any alternative to that. One may wonder why regular extension types don't do that: this is because of a hack that excludes static (non-heap) types from being reference counted in their instances. Heap types do refcount their types, consequently, subtype_dealloc also DECREFs the type. I certainly agree that this is muddy, in particular when it comes to subtyping where the derived subtype calls the base tp_dealloc. In an ideal world, object_dealloc would decref the type, and subtypes would be required to call the base type's dealloc. However, I feel that this cannot be changed before Python 4. So I'd propose that it is actually the leaf subtype which decrefs ob_type. The check whether you are the leaf type is then done by checking whether tp_dealloc is the one you are "in" right now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 19:36:04 2012 From: report at bugs.python.org (Eric Snow) Date: Fri, 17 Aug 2012 17:36:04 +0000 Subject: [issue15715] __import__ now raises with non-existing items in fromlist in 3.3 In-Reply-To: <1345156928.79.0.203974969225.issue15715@psf.upfronthosting.co.za> Message-ID: <1345224964.28.0.723379661615.issue15715@psf.upfronthosting.co.za> Eric Snow added the comment: When people want to import modules with "runtime" names, they regrettably turn to __import__() and likely will for a while. What a source of headaches! If it were less convenient to use __import__(), perhaps fewer people would use it. Could we remove it from .__builtins__, so that it would not be found during the lookup chain? We could still expose it in the builtins module or move it to imp. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 19:37:55 2012 From: report at bugs.python.org (Mark Shannon) Date: Fri, 17 Aug 2012 17:37:55 +0000 Subject: [issue5765] stack overflow evaluating eval("()" * 30000) In-Reply-To: <1239838657.22.0.326859227165.issue5765@psf.upfronthosting.co.za> Message-ID: <1345225075.22.0.262935676209.issue5765@psf.upfronthosting.co.za> Mark Shannon added the comment: I've re-reviewed Andrea's patch (I was looking over Andrea's shoulder at the EuroPython sprint when he wrote it). It looks good and applies cleanly. Could someone commit it please. ---------- nosy: +Mark.Shannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 19:49:52 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 17 Aug 2012 17:49:52 +0000 Subject: [issue15717] Mail System Error - Returned Mail In-Reply-To: <1345182438.99.0.586131298899.issueNone@psf.upfronthosting.co.za> Message-ID: <1345225792.2.0.79278472682.issue15717@psf.upfronthosting.co.za> Changes by ?ric Araujo : Removed file: http://bugs.python.org/file26877/file.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 19:49:58 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 17 Aug 2012 17:49:58 +0000 Subject: [issue15717] Mail System Error - Returned Mail In-Reply-To: <1345182438.99.0.586131298899.issueNone@psf.upfronthosting.co.za> Message-ID: <1345225798.83.0.794151786515.issue15717@psf.upfronthosting.co.za> Changes by ?ric Araujo : Removed file: http://bugs.python.org/file26878/unnamed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 19:50:23 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 17 Aug 2012 17:50:23 +0000 Subject: [issue15717] Mail System Error - Returned Mail In-Reply-To: <1345182438.99.0.586131298899.issueNone@psf.upfronthosting.co.za> Message-ID: <1345225823.31.0.741791368366.issue15717@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +ezio.melotti resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 19:51:08 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 17 Aug 2012 17:51:08 +0000 Subject: [issue15710] logging module crashes in Python 2.7.3 for handler.setLevel(long) In-Reply-To: <1345152839.48.0.661799461902.issue15710@psf.upfronthosting.co.za> Message-ID: <1345225868.94.0.42631474074.issue15710@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 19:54:10 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 17 Aug 2012 17:54:10 +0000 Subject: [issue15694] link to "file object" glossary entry in open() and io docs In-Reply-To: <1345133191.76.0.682782918752.issue15694@psf.upfronthosting.co.za> Message-ID: <1345226050.48.0.890584087034.issue15694@psf.upfronthosting.co.za> ?ric Araujo added the comment: LGTM. ---------- nosy: +eric.araujo, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 19:54:31 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 17 Aug 2012 17:54:31 +0000 Subject: [issue15715] __import__ now raises with non-existing items in fromlist in 3.3 In-Reply-To: <1345156928.79.0.203974969225.issue15715@psf.upfronthosting.co.za> Message-ID: <1345226071.58.0.583146452197.issue15715@psf.upfronthosting.co.za> Brett Cannon added the comment: We might be able to hide it in Python 3 since importlib.import_module() has been available since Python 3.1 (and 3.0 is dead anyway). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 20:08:31 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 17 Aug 2012 18:08:31 +0000 Subject: [issue15640] Document importlib.abc.Finder as deprecated In-Reply-To: <1344887238.09.0.248857343378.issue15640@psf.upfronthosting.co.za> Message-ID: <3WzC8G54VQzQ3d@mail.python.org> Roundup Robot added the comment: New changeset 4bbb1ff4f7ea by Brett Cannon in branch 'default': Issue #15640: Document importlib.abc.Finder as deprecated. http://hg.python.org/cpython/rev/4bbb1ff4f7ea ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 20:08:52 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 17 Aug 2012 18:08:52 +0000 Subject: [issue15640] Document importlib.abc.Finder as deprecated In-Reply-To: <1344887238.09.0.248857343378.issue15640@psf.upfronthosting.co.za> Message-ID: <1345226932.84.0.0462337179892.issue15640@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 20:08:55 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 17 Aug 2012 18:08:55 +0000 Subject: [issue15643] Support OpenCSW in setup.py In-Reply-To: <1344896135.95.0.0625174180507.issue15643@psf.upfronthosting.co.za> Message-ID: <1345226935.37.0.527727169078.issue15643@psf.upfronthosting.co.za> ?ric Araujo added the comment: +1 ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 20:09:09 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 17 Aug 2012 18:09:09 +0000 Subject: [issue15629] Run doctests in Doc/*.rst as part of regrtest In-Reply-To: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za> Message-ID: <1345226949.24.0.0706922717811.issue15629@psf.upfronthosting.co.za> Terry J. Reedy added the comment: On Windows, .rst files are not part of the install, so running doctests on .rst files cannot be a required part of the standard regrtest. ---------- nosy: +terry.reedy versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 20:10:08 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 17 Aug 2012 18:10:08 +0000 Subject: [issue15031] Split .pyc parsing from module loading In-Reply-To: <1339096213.71.0.334524050625.issue15031@psf.upfronthosting.co.za> Message-ID: <1345227008.61.0.183206918542.issue15031@psf.upfronthosting.co.za> Brett Cannon added the comment: While thinking about terminology, source files/modules vs. bytecode files/modules make the distinction clear enough to differentiate just straight bytecode for an object (i.e. what dis outputs) vs. bytecode plsu the other stuff that goes with .pyc files. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 20:11:44 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 17 Aug 2012 18:11:44 +0000 Subject: [issue15636] base64.decodebytes is only available in Python3.1+ In-Reply-To: <1344858430.17.0.615853795219.issue15636@psf.upfronthosting.co.za> Message-ID: <1345227104.6.0.637415153871.issue15636@psf.upfronthosting.co.za> ?ric Araujo added the comment: 3.0 is considered an alpha release by python-dev, is is not officially supported and is basically dead. 3.1 was released very soon after, mostly to fix the slow I/O. That?s why the docs don?t detail what?s new in 3.1, as this version is considered the first Python 3 version. If this explanation satisfies you, I will close this bug. Thanks for the report anyway. ---------- nosy: +eric.araujo resolution: -> invalid stage: -> committed/rejected status: open -> pending versions: -Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 20:12:43 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 17 Aug 2012 18:12:43 +0000 Subject: [issue15631] Python 3.3 beta 1 installation issue lib/lib64 folders In-Reply-To: <1344794304.26.0.478120841355.issue15631@psf.upfronthosting.co.za> Message-ID: <1345227163.67.0.116601099713.issue15631@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 20:13:33 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 17 Aug 2012 18:13:33 +0000 Subject: [issue15634] Add serialized decorator to the threading module In-Reply-To: <1344845068.87.0.536585589553.issue15634@psf.upfronthosting.co.za> Message-ID: <1345227213.19.0.0606112657544.issue15634@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- title: synchronized decorator for the threading module -> Add serialized decorator to the threading module _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 20:15:31 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 17 Aug 2012 18:15:31 +0000 Subject: [issue15717] Mail System Error - Returned Mail In-Reply-To: <1345182438.99.0.586131298899.issueNone@psf.upfronthosting.co.za> Message-ID: <1345227331.29.0.745147946261.issue15717@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 20:28:05 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 17 Aug 2012 18:28:05 +0000 Subject: [issue15717] Mail System Error - Returned Mail In-Reply-To: <1345182438.99.0.586131298899.issueNone@psf.upfronthosting.co.za> Message-ID: <1345228085.73.0.310966333391.issue15717@psf.upfronthosting.co.za> Martin v. L?wis added the comment: This is spam/a virus. Please don't just unlink the file, as it still remains accessible, and will ultimately result in Google (and perhaps other search engines) declare the bug tracker as a spam host. Instead, the proper action is to select the "mark as spam" button on each file and each message (which I just did). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 20:28:08 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 17 Aug 2012 18:28:08 +0000 Subject: [issue15636] base64.decodebytes is only available in Python3.1+ In-Reply-To: <1344858430.17.0.615853795219.issue15636@psf.upfronthosting.co.za> Message-ID: <1345228088.7.0.45161680488.issue15636@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Once a version goes off normal maintenance, we stop patching the manual except for changes related to security fixes. So the 3.1 manual is also frozen (except for possible security fixes). The same is true of 2.6 and will be true of 3.2 when its final maintenance release comes out. Andrew, we recommend that you ignore 3.0 even if you are trying to write multi-version 3.x code. ---------- nosy: +terry.reedy status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 20:32:52 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 17 Aug 2012 18:32:52 +0000 Subject: [issue15717] Mail System Error - Returned Mail In-Reply-To: <1345182438.99.0.586131298899.issueNone@psf.upfronthosting.co.za> Message-ID: <1345228372.87.0.808964261185.issue15717@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 20:39:50 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 17 Aug 2012 18:39:50 +0000 Subject: [issue15717] Mail System Error - Returned Mail In-Reply-To: <1345182438.99.0.586131298899.issueNone@psf.upfronthosting.co.za> Message-ID: <1345228790.66.0.894000826977.issue15717@psf.upfronthosting.co.za> ?ric Araujo added the comment: It seems the spam controls are only accessible to tracker devs. Is there a list somewhere to let bug triagers know who should be added to nosy to take action? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 20:39:57 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 17 Aug 2012 18:39:57 +0000 Subject: [issue15636] base64.decodebytes is only available in Python3.1+ In-Reply-To: <1344858430.17.0.615853795219.issue15636@psf.upfronthosting.co.za> Message-ID: <1345228797.25.0.998651104215.issue15636@psf.upfronthosting.co.za> R. David Murray added the comment: We have plenty of "versionadded" and "versionchanged" tags for 3.1 in the docs. We should add one for this as well to the 3.2 and 3.3 docs. ---------- nosy: +r.david.murray resolution: invalid -> stage: committed/rejected -> needs patch status: closed -> open type: enhancement -> behavior versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 20:41:36 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 17 Aug 2012 18:41:36 +0000 Subject: [issue15657] Error in Python 3 docs for PyMethodDef In-Reply-To: <1344970966.7.0.115664419243.issue15657@psf.upfronthosting.co.za> Message-ID: <1345228896.22.0.492263057169.issue15657@psf.upfronthosting.co.za> Andrew Svetlov added the comment: I think we can change PyCFunction_Call to accept METH_KEYWORDS as alias for METH_VARARGS | METH_KEYWORDS. It cannot make incompatibility with existing code base. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 20:42:19 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 17 Aug 2012 18:42:19 +0000 Subject: [issue15717] Mail System Error - Returned Mail In-Reply-To: <1345182438.99.0.586131298899.issueNone@psf.upfronthosting.co.za> Message-ID: <1345228939.46.0.942605908739.issue15717@psf.upfronthosting.co.za> Ezio Melotti added the comment: http://psf.upfronthosting.co.za/roundup/meta/issue120 should fix the problem. Why did the message come from python-dev though? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 20:42:39 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 17 Aug 2012 18:42:39 +0000 Subject: [issue15645] 2to3 Grammar pickles not created when upgrading to 3.3.0b2 In-Reply-To: <1344932180.41.0.826216341416.issue15645@psf.upfronthosting.co.za> Message-ID: <1345228959.33.0.187200189266.issue15645@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Your OS and distribution/version might be relevant information. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 20:50:03 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 17 Aug 2012 18:50:03 +0000 Subject: [issue15717] Mail System Error - Returned Mail In-Reply-To: <1345182438.99.0.586131298899.issueNone@psf.upfronthosting.co.za> Message-ID: <1345229403.24.0.401553083691.issue15717@psf.upfronthosting.co.za> R. David Murray added the comment: Because the spammer faked that address, presumably. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 21:02:13 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 17 Aug 2012 19:02:13 +0000 Subject: [issue15717] Mail System Error - Returned Mail In-Reply-To: <1345182438.99.0.586131298899.issueNone@psf.upfronthosting.co.za> Message-ID: <1345230133.74.0.324459193579.issue15717@psf.upfronthosting.co.za> Martin v. L?wis added the comment: ?ric, while issue 120 is being considered, I have given you the "Coordinator". Use your new powers carefully :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 21:13:31 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 17 Aug 2012 19:13:31 +0000 Subject: [issue15660] In str.format there is a misleading error message about alignment In-Reply-To: <1345004440.11.0.680139192916.issue15660@psf.upfronthosting.co.za> Message-ID: <1345230811.79.0.11932824136.issue15660@psf.upfronthosting.co.za> Terry J. Reedy added the comment: As I read the docs, the error message is correct and this issue is invalid as a behavior issue. I read the OP's second message as more or less saying this also. "'=' Forces the padding to be placed after the sign (if any) but before the digits. This is used for printing fields in the form ?+000000120?. This alignment option is only valid for numeric types." "If the width field is preceded by a zero ('0') character, this enables zero-padding. This is equivalent to an alignment type of '=' and a fill character of '0'." So ":02" is equivalent to ":0=2", which is invalid. >>> '{:02d}'.format(1) '01' works fine. I decided make this a doc issue and add " for numeric types" after "this enables zero-padding" before closing this. ---------- assignee: -> docs at python components: +Documentation -Interpreter Core nosy: +docs at python, terry.reedy versions: +Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 21:24:16 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 17 Aug 2012 19:24:16 +0000 Subject: [issue15694] link to "file object" glossary entry in open() and io docs In-Reply-To: <1345133191.76.0.682782918752.issue15694@psf.upfronthosting.co.za> Message-ID: <1345231456.95.0.895267680234.issue15694@psf.upfronthosting.co.za> Antoine Pitrou added the comment: LGTM too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 21:39:25 2012 From: report at bugs.python.org (Trent Nelson) Date: Fri, 17 Aug 2012 19:39:25 +0000 Subject: [issue15477] test_cmath failures on OS X 10.8 In-Reply-To: <1343469837.83.0.840988569572.issue15477@psf.upfronthosting.co.za> Message-ID: <1345232365.46.0.555730288556.issue15477@psf.upfronthosting.co.za> Trent Nelson added the comment: I ran into this last night and posted to python-dev before realizing this bug had been raised: http://mail.python.org/pipermail/python-dev/2012-August/121359.html I'll reproduce it here as I made a few observations that haven't yet been mentioned in this issue: The Mountain Lion build slave I set up earlier this evening fails on test_cmath: ====================================================================== FAIL: test_specific_values (test.test_cmath.CMathTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Volumes/bay2/buildslave/cpython/2.7.snakebite-mountainlion-amd64/build/Lib/test/test_cmath.py", line 352, in test_specific_values msg=error_message) File "/Volumes/bay2/buildslave/cpython/2.7.snakebite-mountainlion-amd64/build/Lib/test/test_cmath.py", line 94, in rAssertAlmostEqual 'got {!r}'.format(a, b)) AssertionError: atan0000: atan(complex(0.0, 0.0)) Expected: complex(0.0, 0.0) Received: complex(0.0, -0.0) Received value insufficiently close to expected value. Mountain Lion's atan/log1p appear to drop the negative sign when passed in -0.0, whereas previous versions of OS X didn't: Mountain Lion: % ~/log1p-viper log1p_drops_zero_sign_test: atan2(log1p(-0.), -1.) != atan2(-0., -1.) 3.14159 vs -3.14159 atan_drops_zero_sign_test: atan2(-0., 0.): -0.00000 atan2( 0., -0.): 3.14159 atan2(-0., -0.): -3.14159 atan2( 0., 0.): 0.00000 log1p(-0.): 0.00000 log1p( 0.): 0.00000 Lion: % ./log1p log1p_drops_zero_sign_test: atan2(log1p(-0.), -1.) == atan2(-0., -1.) -3.14159 vs -3.14159 atan_drops_zero_sign_test: atan2(-0., 0.): -0.00000 atan2( 0., -0.): 3.14159 atan2(-0., -0.): -3.14159 atan2( 0., 0.): 0.00000 log1p(-0.): -0.00000 log1p( 0.): 0.00000 (The C code for that is below.) configure.ac already has a test for this (it makes mention of AIX having similar behaviour), and the corresponding sysconfig entry named 'LOG1P_DROPS_ZERO_SIGN' is already being used on a few tests, i.e.: # The algorithm used for atan and atanh makes use of the system # log1p function; If that system function doesn't respect the sign # of zero, then atan and atanh will also have difficulties with # the sign of complex zeros. @requires_IEEE_754 @unittest.skipIf(sysconfig.get_config_var('LOG1P_DROPS_ZERO_SIGN'), "system log1p() function doesn't preserve the sign") def testAtanSign(self): for z in complex_zeros: self.assertComplexIdentical(cmath.atan(z), z) @requires_IEEE_754 @unittest.skipIf(sysconfig.get_config_var('LOG1P_DROPS_ZERO_SIGN'), "system log1p() function doesn't preserve the sign") def testAtanhSign(self): for z in complex_zeros: self.assertComplexIdentical(cmath.atanh(z), z) Taking a look at cmath_testcases.txt, and we can see this: -- These are tested in testAtanSign in test_cmath.py -- atan0000 atan 0.0 0.0 -> 0.0 0.0 -- atan0001 atan 0.0 -0.0 -> 0.0 -0.0 -- atan0002 atan -0.0 0.0 -> -0.0 0.0 -- atan0003 atan -0.0 -0.0 -> -0.0 -0.0 However, a few lines down, those tests crop up again: -- special values atan1000 atan -0.0 0.0 -> -0.0 0.0 atan1014 atan 0.0 0.0 -> 0.0 0.0 ....which is what causes the current test failures. I hacked test_cmath.py a bit to spit out all the errors it finds after it's finished parsing the test file (instead of bombing out on the first one), and it yielded this: FAIL: test_specific_values (test.test_cmath.CMathTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Volumes/bay2/buildslave/cpython/3.2.snakebite-mountainlion-amd64/build/Lib/test/test_cmath.py", line 446, in test_specific_values self.fail("\n".join(failures)) AssertionError: atan1000: atan(complex(-0.0, 0.0)) Expected: complex(-0.0, 0.0) Received: complex(-0.0, -0.0) Received value insufficiently close to expected value. atan1014: atan(complex(0.0, 0.0)) Expected: complex(0.0, 0.0) Received: complex(0.0, -0.0) Received value insufficiently close to expected value. atanh0225: atanh(complex(-0.0, 5.6067e-320)) Expected: complex(-0.0, 5.6067e-320) Received: complex(0.0, 5.6067e-320) Received value insufficiently close to expected value. atanh0227: atanh(complex(-0.0, -3.0861101e-316)) Expected: complex(-0.0, -3.0861101e-316) Received: complex(0.0, -3.0861101e-316) Received value insufficiently close to expected value. atanh1024: atanh(complex(-0.0, -0.0)) Expected: complex(-0.0, -0.0) Received: complex(0.0, -0.0) Received value insufficiently close to expected value. atanh1034: atanh(complex(-0.0, 0.0)) Expected: complex(-0.0, 0.0) Received: complex(0.0, 0.0) Received value insufficiently close to expected value. This is the patch I came up with against test_cmath.py: xenon% hg diff Lib/test/test_cmath.py diff -r ce49599b9fdf Lib/test/test_cmath.py --- a/Lib/test/test_cmath.py Thu Aug 16 22:14:43 2012 +0200 +++ b/Lib/test/test_cmath.py Fri Aug 17 07:54:05 2012 +0000 @@ -121,8 +121,10 @@ # if both a and b are zero, check whether they have the same sign # (in theory there are examples where it would be legitimate for a # and b to have opposite signs; in practice these hardly ever - # occur). - if not a and not b: + # occur) -- the exception to this is if we're on a system that drops + # the sign on zeros. + drops_zero_sign = sysconfig.get_config_var('LOG1P_DROPS_ZERO_SIGN') + if not drops_zero_sign and not a and not b: if math.copysign(1., a) != math.copysign(1., b): self.fail(msg or 'zero has wrong sign: expected {!r}, ' 'got {!r}'.format(a, b)) With that applied, all the test_cmath tests pass again (without any changes to the test file). Thoughts? Trent. -- C code for the example earlier: #include #include int main(int argc, char **argv) { printf("\nlog1p_drops_zero_sign_test:\n"); if (atan2(log1p(-0.), -1.) == atan2(-0., -1.)) printf(" atan2(log1p(-0.), -1.) == atan2(-0., -1.)\n"); else printf(" atan2(log1p(-0.), -1.) != atan2(-0., -1.)\n"); printf( " %.5f vs %.5f\n", atan2(log1p(-0.), -1.), atan2(-0., -1.) ); printf("\natan_drops_zero_sign_test:\n"); printf(" atan2(-0., 0.): %0.5f\n", atan2(-0., 0.)); printf(" atan2( 0., -0.): %0.5f\n", atan2( 0., -0.)); printf(" atan2(-0., -0.): %0.5f\n", atan2(-0., -0.)); printf(" atan2( 0., 0.): %0.5f\n", atan2( 0., 0.)); printf(" log1p(-0.): %0.5f\n", log1p(-0.)); printf(" log1p( 0.): %0.5f\n", log1p( 0.)); } /* vim:set ts=8 sw=4 sts=4 tw=78 et: */ After thinking about it a bit longer, I think patching rAssertAlmostEqual is unnecessarily hacky. The problem is that the 'special value' atan tests in the cmath test file shouldn't have any zero tests -- these are handled in testAtanSign, which is what cmath_testcase.txt states: --------------------------- -- atan: Inverse tangent -- --------------------------- -- zeros -- These are tested in testAtanSign in test_cmath.py -- atan0000 atan 0.0 0.0 -> 0.0 0.0 -- atan0001 atan 0.0 -0.0 -> 0.0 -0.0 -- atan0002 atan -0.0 0.0 -> -0.0 0.0 -- atan0003 atan -0.0 -0.0 -> -0.0 -0.0 So, given, that, let's review the affected tests further down in cmath_testcase.txt: AssertionError: atan1000: atan(complex(-0.0, 0.0)) Expected: complex(-0.0, 0.0) Received: complex(-0.0, -0.0) Received value insufficiently close to expected value. atan1014: atan(complex(0.0, 0.0)) Expected: complex(0.0, 0.0) Received: complex(0.0, -0.0) Received value insufficiently close to expected value. atanh0225: atanh(complex(-0.0, 5.6067e-320)) Expected: complex(-0.0, 5.6067e-320) Received: complex(0.0, 5.6067e-320) Received value insufficiently close to expected value. atanh0227: atanh(complex(-0.0, -3.0861101e-316)) Expected: complex(-0.0, -3.0861101e-316) Received: complex(0.0, -3.0861101e-316) Received value insufficiently close to expected value. atanh1024: atanh(complex(-0.0, -0.0)) Expected: complex(-0.0, -0.0) Received: complex(0.0, -0.0) Received value insufficiently close to expected value. atanh1034: atanh(complex(-0.0, 0.0)) Expected: complex(-0.0, 0.0) Received: complex(0.0, 0.0) Received value insufficiently close to expected value. I propose we remove the faulty zero tests as follows: % hg diff diff -r 05274ab06182 Lib/test/cmath_testcases.txt --- a/Lib/test/cmath_testcases.txt Sat May 05 21:57:17 2012 -0700 +++ b/Lib/test/cmath_testcases.txt Fri Aug 17 18:58:03 2012 +0000 @@ -849,7 +849,6 @@ atan0304 atan -9.9998886718268301e-321 -1.0 -> -0.78539816339744828 -368.76019403576692 -- special values -atan1000 atan -0.0 0.0 -> -0.0 0.0 atan1001 atan nan 0.0 -> nan 0.0 atan1002 atan -0.0 1.0 -> -0.0 inf divide-by-zero atan1003 atan -inf 0.0 -> -1.5707963267948966 0.0 @@ -863,7 +862,6 @@ atan1011 atan -2.2999999999999998 nan -> nan nan atan1012 atan -inf nan -> -1.5707963267948966 0.0 ignore-imag-sign atan1013 atan nan nan -> nan nan -atan1014 atan 0.0 0.0 -> 0.0 0.0 atan1015 atan 0.0 1.0 -> 0.0 inf divide-by-zero atan1016 atan inf 0.0 -> 1.5707963267948966 0.0 atan1017 atan inf 2.2999999999999998 -> 1.5707963267948966 0.0 @@ -873,7 +871,6 @@ atan1021 atan 0.0 nan -> nan nan atan1022 atan 2.2999999999999998 nan -> nan nan atan1023 atan inf nan -> 1.5707963267948966 0.0 ignore-imag-sign -atan1024 atan 0.0 -0.0 -> 0.0 -0.0 atan1025 atan nan -0.0 -> nan -0.0 atan1026 atan 0.0 -1.0 -> 0.0 -inf divide-by-zero atan1027 atan inf -0.0 -> 1.5707963267948966 -0.0 @@ -883,7 +880,6 @@ atan1031 atan 2.2999999999999998 -inf -> 1.5707963267948966 -0.0 atan1032 atan inf -inf -> 1.5707963267948966 -0.0 atan1033 atan nan -inf -> nan -0.0 -atan1034 atan -0.0 -0.0 -> -0.0 -0.0 atan1035 atan -0.0 -1.0 -> -0.0 -inf divide-by-zero atan1036 atan -inf -0.0 -> -1.5707963267948966 -0.0 atan1037 atan -inf -2.2999999999999998 -> -1.5707963267948966 -0.0 That leaves us with: atanh0225: atanh(complex(-0.0, 5.6067e-320)) Expected: complex(-0.0, 5.6067e-320) Received: complex(0.0, 5.6067e-320) Received value insufficiently close to expected value. atanh0227: atanh(complex(-0.0, -3.0861101e-316)) Expected: complex(-0.0, -3.0861101e-316) Received: complex(0.0, -3.0861101e-316) Received value insufficiently close to expected value. Those aren't duplicate tests like the 0.0 -> -0.0 ones, so, how should they be handled? The proposed patch to rAssertAlmostEqual will skip these ones, but perhaps something like this would be more appropriate: diff -r 12c062dbe746 Lib/test/cmath_testcases.txt --- a/Lib/test/cmath_testcases.txt Thu Aug 16 22:18:37 2012 +0200 +++ b/Lib/test/cmath_testcases.txt Fri Aug 17 15:37:11 2012 -0400 @@ -849,7 +849,6 @@ atan0304 atan -9.9998886718268301e-321 -1.0 -> -0.78539816339744828 -368.76019403576692 -- special values -atan1000 atan -0.0 0.0 -> -0.0 0.0 atan1001 atan nan 0.0 -> nan 0.0 atan1002 atan -0.0 1.0 -> -0.0 inf divide-by-zero atan1003 atan -inf 0.0 -> -1.5707963267948966 0.0 @@ -863,7 +862,6 @@ atan1011 atan -2.2999999999999998 nan -> nan nan atan1012 atan -inf nan -> -1.5707963267948966 0.0 ignore-imag-sign atan1013 atan nan nan -> nan nan -atan1014 atan 0.0 0.0 -> 0.0 0.0 atan1015 atan 0.0 1.0 -> 0.0 inf divide-by-zero atan1016 atan inf 0.0 -> 1.5707963267948966 0.0 atan1017 atan inf 2.2999999999999998 -> 1.5707963267948966 0.0 @@ -873,7 +871,6 @@ atan1021 atan 0.0 nan -> nan nan atan1022 atan 2.2999999999999998 nan -> nan nan atan1023 atan inf nan -> 1.5707963267948966 0.0 ignore-imag-sign -atan1024 atan 0.0 -0.0 -> 0.0 -0.0 atan1025 atan nan -0.0 -> nan -0.0 atan1026 atan 0.0 -1.0 -> 0.0 -inf divide-by-zero atan1027 atan inf -0.0 -> 1.5707963267948966 -0.0 @@ -883,7 +880,6 @@ atan1031 atan 2.2999999999999998 -inf -> 1.5707963267948966 -0.0 atan1032 atan inf -inf -> 1.5707963267948966 -0.0 atan1033 atan nan -inf -> nan -0.0 -atan1034 atan -0.0 -0.0 -> -0.0 -0.0 atan1035 atan -0.0 -1.0 -> -0.0 -inf divide-by-zero atan1036 atan -inf -0.0 -> -1.5707963267948966 -0.0 atan1037 atan -inf -2.2999999999999998 -> -1.5707963267948966 -0.0 @@ -1011,9 +1007,7 @@ atanh0222 atanh -5.9656816081325078e-317 9.9692253555416263e-313 -> -5.9656816081325078e-317 9.9692253555416263e-313 atanh0223 atanh -6.5606671178400239e-313 -2.1680936406357335e-309 -> -6.5606671178400239e-313 -2.1680936406357335e-309 atanh0224 atanh 0.0 2.5230944401820779e-319 -> 0.0 2.5230944401820779e-319 -atanh0225 atanh -0.0 5.6066569490064658e-320 -> -0.0 5.6066569490064658e-320 atanh0226 atanh 0.0 -2.4222487249468377e-317 -> 0.0 -2.4222487249468377e-317 -atanh0227 atanh -0.0 -3.0861101089206037e-316 -> -0.0 -3.0861101089206037e-316 atanh0228 atanh 3.1219222884393986e-310 0.0 -> 3.1219222884393986e-310 0.0 atanh0229 atanh 9.8926337564976196e-309 -0.0 -> 9.8926337564976196e-309 -0.0 atanh0230 atanh -1.5462535092918154e-312 0.0 -> -1.5462535092918154e-312 0.0 @@ -1051,7 +1045,6 @@ atanh1021 atanh nan -0.0 -> nan nan atanh1022 atanh nan -2.3 -> nan nan atanh1023 atanh nan -inf -> 0.0 -1.5707963267948966 ignore-real-sign -atanh1024 atanh -0.0 -0.0 -> -0.0 -0.0 atanh1025 atanh -0.0 nan -> -0.0 nan atanh1026 atanh -1.0 -0.0 -> -inf -0.0 divide-by-zero atanh1027 atanh -0.0 -inf -> -0.0 -1.5707963267948966 @@ -1061,7 +1054,6 @@ atanh1031 atanh -inf -2.3 -> -0.0 -1.5707963267948966 atanh1032 atanh -inf -inf -> -0.0 -1.5707963267948966 atanh1033 atanh -inf nan -> -0.0 nan -atanh1034 atanh -0.0 0.0 -> -0.0 0.0 atanh1035 atanh -1.0 0.0 -> -inf 0.0 divide-by-zero atanh1036 atanh -0.0 inf -> -0.0 1.5707963267948966 atanh1037 atanh -2.3 inf -> -0.0 1.5707963267948966 diff -r 12c062dbe746 Lib/test/test_cmath.py --- a/Lib/test/test_cmath.py Thu Aug 16 22:18:37 2012 +0200 +++ b/Lib/test/test_cmath.py Fri Aug 17 15:37:11 2012 -0400 @@ -532,6 +532,36 @@ for z in complex_zeros: self.assertComplexIdentical(cmath.atanh(z), z) + @requires_IEEE_754 + @unittest.skipIf(sysconfig.get_config_var('LOG1P_DROPS_ZERO_SIGN'), + "system log1p() function doesn't preserve the sign") + def testAtanhSignNearZero(self): + for z in (-30861101e-316, 5.6067e-320): + expected = complex(-0.0, z) + actual = cmath.atanh(complex(-0.0, z)) + error_message = ( + 'Expected: complex({!r}, {!r})\n' + 'Received: complex({!r}, {!r})\n' + 'Received value insufficiently close to expected value.' + ).format( + expected.real, + expected.imag, + actual.real, + actual.imag + ) + + self.rAssertAlmostEqual( + expected.real, + actual.real, + abs_err=5e-323, + msg=error_message, + ) + + self.rAssertAlmostEqual( + expected.imag, + actual.imag, + msg=error_message, + ) def test_main(): run_unittest(CMathTests) With this patch applied, test_cmath passes on both Mountain Lion and Lion. I've attached this patch as issue15477.patch. Thoughts? ---------- keywords: +patch nosy: +trent Added file: http://bugs.python.org/file26880/issue15477.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 21:42:51 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 17 Aug 2012 19:42:51 +0000 Subject: [issue15660] In str.format there is a misleading error message about alignment In-Reply-To: <1345004440.11.0.680139192916.issue15660@psf.upfronthosting.co.za> Message-ID: <3WzFF633m2zQ61@mail.python.org> Roundup Robot added the comment: New changeset 85cd54b2d3a1 by Terry Jan Reedy in branch '2.7': Issue 15660: Clarify 0 prefix for width field in str.format doc. http://hg.python.org/cpython/rev/85cd54b2d3a1 New changeset 6bc14974024f by Terry Jan Reedy in branch '3.2': Issue 15660: Clarify 0 prefix for width field in str.format doc. http://hg.python.org/cpython/rev/6bc14974024f New changeset f181dd088e63 by Terry Jan Reedy in branch 'default': Merge with 3.2 #15660 http://hg.python.org/cpython/rev/f181dd088e63 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 21:43:49 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 17 Aug 2012 19:43:49 +0000 Subject: [issue15660] In str.format there is a misleading error message about alignment In-Reply-To: <1345004440.11.0.680139192916.issue15660@psf.upfronthosting.co.za> Message-ID: <1345232629.88.0.964864902356.issue15660@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 21:44:32 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 17 Aug 2012 19:44:32 +0000 Subject: [issue15660] Clarify 0 prefix for width specifier in str.format doc, In-Reply-To: <1345004440.11.0.680139192916.issue15660@psf.upfronthosting.co.za> Message-ID: <1345232672.78.0.744259450374.issue15660@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- stage: needs patch -> committed/rejected status: open -> closed title: In str.format there is a misleading error message about alignment -> Clarify 0 prefix for width specifier in str.format doc, _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 21:45:05 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 17 Aug 2012 19:45:05 +0000 Subject: [issue15660] Clarify 0 prefix for width specifier in str.format doc, In-Reply-To: <1345004440.11.0.680139192916.issue15660@psf.upfronthosting.co.za> Message-ID: <1345232705.3.0.659436287171.issue15660@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- assignee: docs at python -> terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 21:51:22 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 17 Aug 2012 19:51:22 +0000 Subject: [issue15623] Init time relative imports no longer work from __init__.so modules In-Reply-To: <1344697325.25.0.880049566038.issue15623@psf.upfronthosting.co.za> Message-ID: <1345233082.05.0.234436927977.issue15623@psf.upfronthosting.co.za> Brett Cannon added the comment: So I can't reproduce under 3.2. First off, building the example code in test.tgz fails thanks to __Py_ZeroStruct not being found (this is with using both an installed Python 3.2 and a checkout build). Second, when I just make audioop a package in Python 3.2 it still grabs the __init__.py file, so I can't reproduce that way either. Third, I hand-traced the import code starting in load_module() in Python 3.2 and if you follow:: import.c:load_module() -> importdl.c:_PyImport_GetDynLoadFunc() -> import.c:_PyImport_FixupExtensionUnicode() you will find where a new module gets set in sys.modules (through PyImport_GetModuleDict()) and it's after the PyInit function for the extension module is called. So if there is some magical path that is deep in import.c that is setting the module in sys.modules when there is a __init__.py next to an __init__.so I will need someone who has actually made this work with an empty __init__.py figure out how it's all happening since _PyImport_GetDynLoadFunc() would short-circuit if the module was already in sys.modules and entirely skip executing the PyInit for the extension module. Fourth, if you go with the work-around, Stefan, just make sure that on error anywhere in your PyInit you remove the module from sys.modules that you injected. Because of all of this I am making this pending as "won't fix". If someone can figure out what is happening in Python 3.2 I will leave it open until we decide how to handle this, else I will close this before rc1. ---------- resolution: -> wont fix status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 22:18:45 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 17 Aug 2012 20:18:45 +0000 Subject: [issue15718] Possible OverflowError in __len__ method undocumented (when called via len() function) In-Reply-To: <1345202279.02.0.767068523185.issue15718@psf.upfronthosting.co.za> Message-ID: <1345234725.38.0.207786420347.issue15718@psf.upfronthosting.co.za> Terry J. Reedy added the comment: In #12159, Victor correctly labelled this an implementation (IE, CPython) detail (limitation). I don't believe any implementation has to limit the range of len(). So the question is whether we should add a CPython implementation limit note, including the possibility of OverflowError, and if so, to both len() and __len__() entries. I am not sure of the current doc policy. The second sentence of the len entry is out of date. " The argument may be a sequence (string, tuple or list) or a mapping (dictionary)." Sets and any collections with a size (__len__ method) can also be arguments. I am not sure how to revise that either. ---------- nosy: +benjamin.peterson, georg.brandl, haypo, terry.reedy stage: -> needs patch versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 22:23:24 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 17 Aug 2012 20:23:24 +0000 Subject: [issue15307] Patch for --symlink support in pyvenv with framework python In-Reply-To: <1341846821.48.0.167902068293.issue15307@psf.upfronthosting.co.za> Message-ID: <3WzG7t1rJzzQ4G@mail.python.org> Roundup Robot added the comment: New changeset 4610ac42130e by Ned Deily in branch 'default': Issue #15678: Fix menu customization for IDLE started from OS X http://hg.python.org/cpython/rev/4610ac42130e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 22:23:27 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 17 Aug 2012 20:23:27 +0000 Subject: [issue15678] IDLE menu customization is broken from OS X command lines In-Reply-To: <1345079292.52.0.381785713034.issue15678@psf.upfronthosting.co.za> Message-ID: <3WzG7v0HxbzQ4H@mail.python.org> Roundup Robot added the comment: New changeset 4610ac42130e by Ned Deily in branch 'default': Issue #15678: Fix menu customization for IDLE started from OS X http://hg.python.org/cpython/rev/4610ac42130e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 22:25:58 2012 From: report at bugs.python.org (Ned Deily) Date: Fri, 17 Aug 2012 20:25:58 +0000 Subject: [issue15678] IDLE menu customization is broken from OS X command lines In-Reply-To: <1345079292.52.0.381785713034.issue15678@psf.upfronthosting.co.za> Message-ID: <1345235158.39.0.427178849239.issue15678@psf.upfronthosting.co.za> Ned Deily added the comment: Applied for 3.3.0rc1 ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 22:44:53 2012 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 17 Aug 2012 20:44:53 +0000 Subject: [issue15719] Sort dict items in urlencode() Message-ID: <1345236293.12.0.120802358061.issue15719@psf.upfronthosting.co.za> New submission from Guido van Rossum: >From http://mail.python.org/pipermail/python-dev/2012-August/121364.html : """ I just fixed a unittest for some code used at Google that was comparing a url generated by urllib.encode() to a fixed string. The problem was caused by turning on PYTHONHASHSEED=1. Because of this, the code under test would generate a textually different URL each time the test was run, but the intention of the test was just to check that all the query parameters were present and equal to the expected values. The solution was somewhat painful, I had to parse the url, split the query parameters, and compare them to a known dict. I wonder if it wouldn't make sense to change urlencode() to generate URLs that don't depend on the hash order, for all versions of Python that support PYTHONHASHSEED? It seems a one-line fix: query = query.items() with this: query = sorted(query.items()) This would not prevent breakage of unit tests, but it would make a much simpler fix possible: simply sort the parameters in the URL. """ MvL's response (http://mail.python.org/pipermail/python-dev/2012-August/121366.html) seems to suggest that this can go in as a bugfix in 3.2 and later if augmented with a check for type(query) is dict and a check for whether dict hashing is enabled. Does anyone want to turn this idea into a patch? ---------- keywords: easy messages: 168477 nosy: gvanrossum priority: normal severity: normal status: open title: Sort dict items in urlencode() versions: Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 23:01:54 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 17 Aug 2012 21:01:54 +0000 Subject: [issue15355] generator docs should mention already-executing exception In-Reply-To: <1342312261.31.0.534711044354.issue15355@psf.upfronthosting.co.za> Message-ID: <1345237314.03.0.0700693433442.issue15355@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Good suggestion, David. Here is such sample test code. It is adapted from the sample code for "ValueError: generator already executing" included in PEP 255: def test_gen(call_gen_method): def gen(): call_gen_method(me) yield 1 me = gen() try: me.__next__() except Exception as e: print(repr(e)) test_gen(lambda g: g.__next__()) test_gen(lambda g: g.send(1)) test_gen(lambda g: g.throw(OSError)) test_gen(lambda g: g.close()) This outputs: ValueError('generator already executing',) ValueError('generator already executing',) ValueError('generator already executing',) ValueError('generator already executing',) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 23:07:25 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 17 Aug 2012 21:07:25 +0000 Subject: [issue15719] Sort dict items in urlencode() In-Reply-To: <1345236293.12.0.120802358061.issue15719@psf.upfronthosting.co.za> Message-ID: <1345237645.6.0.265556408814.issue15719@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 23:14:38 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 17 Aug 2012 21:14:38 +0000 Subject: [issue15632] regrtest.py: spurious leaks with -R option In-Reply-To: <1344799906.56.0.0975538971998.issue15632@psf.upfronthosting.co.za> Message-ID: <3WzHH11PtfzQ6W@mail.python.org> Roundup Robot added the comment: New changeset dc18d73e67a5 by Stefan Krah in branch 'default': Closes #15632: regrtest.py: fix spurious refleaks due to various caches http://hg.python.org/cpython/rev/dc18d73e67a5 ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 23:21:12 2012 From: report at bugs.python.org (Stefan Holek) Date: Fri, 17 Aug 2012 21:21:12 +0000 Subject: [issue15645] 2to3 Grammar pickles not created when upgrading to 3.3.0b2 In-Reply-To: <1344932180.41.0.826216341416.issue15645@psf.upfronthosting.co.za> Message-ID: <1345238472.67.0.0121471153037.issue15645@psf.upfronthosting.co.za> Stefan Holek added the comment: Mac OS X 10.6.8 (Snow Leopard) Xcode Tools 3.2.6 ./configure --prefix=/usr/local/python3.3 make sudo make install ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 23:29:47 2012 From: report at bugs.python.org (Alexandre Vassalotti) Date: Fri, 17 Aug 2012 21:29:47 +0000 Subject: [issue15642] Integrate pickle protocol version 4 GSoC work by Stefan Mihaila In-Reply-To: <1344890920.23.0.695633734046.issue15642@psf.upfronthosting.co.za> Message-ID: <1345238987.78.0.772117602833.issue15642@psf.upfronthosting.co.za> Changes by Alexandre Vassalotti : Added file: http://bugs.python.org/file26881/pickle4-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 23:40:39 2012 From: report at bugs.python.org (Alexandre Vassalotti) Date: Fri, 17 Aug 2012 21:40:39 +0000 Subject: [issue15642] Integrate pickle protocol version 4 GSoC work by Stefan Mihaila In-Reply-To: <1344890920.23.0.695633734046.issue15642@psf.upfronthosting.co.za> Message-ID: <1345239639.51.0.789022405977.issue15642@psf.upfronthosting.co.za> Changes by Alexandre Vassalotti : ---------- dependencies: +Unbinding of methods _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 17 23:52:13 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 17 Aug 2012 21:52:13 +0000 Subject: [issue15599] test_circular_imports() of test_threaded_import fails on FreeBSD 9.0 In-Reply-To: <1344473974.14.0.584788696764.issue15599@psf.upfronthosting.co.za> Message-ID: <1345240333.87.0.48029693531.issue15599@psf.upfronthosting.co.za> Stefan Krah added the comment: Reproduced by another FreeBSD bot: http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%20dtrace%203.x/builds/238/steps/test/logs/stdio ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 00:39:33 2012 From: report at bugs.python.org (Alexandre Vassalotti) Date: Fri, 17 Aug 2012 22:39:33 +0000 Subject: [issue15642] Integrate pickle protocol version 4 GSoC work by Stefan Mihaila In-Reply-To: <1344890920.23.0.695633734046.issue15642@psf.upfronthosting.co.za> Message-ID: <1345243173.26.0.783296868007.issue15642@psf.upfronthosting.co.za> Changes by Alexandre Vassalotti : Removed file: http://bugs.python.org/file26881/pickle4-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 00:40:16 2012 From: report at bugs.python.org (Alexandre Vassalotti) Date: Fri, 17 Aug 2012 22:40:16 +0000 Subject: [issue15642] Integrate pickle protocol version 4 GSoC work by Stefan Mihaila In-Reply-To: <1344890920.23.0.695633734046.issue15642@psf.upfronthosting.co.za> Message-ID: <1345243216.02.0.498273201134.issue15642@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: Oops, wrong patch. Uploading the right one. ---------- Added file: http://bugs.python.org/file26882/pickle4-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 00:45:57 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 17 Aug 2012 22:45:57 +0000 Subject: [issue15645] 2to3 Grammar pickles not created when upgrading to 3.3.0b2 In-Reply-To: <1344932180.41.0.826216341416.issue15645@psf.upfronthosting.co.za> Message-ID: <1345243557.7.0.197396891983.issue15645@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I believe there are known problems with 3.3 and mac, so I added the mac experts. ---------- nosy: +hynek, ned.deily, ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 00:59:32 2012 From: report at bugs.python.org (Ned Deily) Date: Fri, 17 Aug 2012 22:59:32 +0000 Subject: [issue15645] 2to3 Grammar pickles not created when upgrading to 3.3.0b2 In-Reply-To: <1344932180.41.0.826216341416.issue15645@psf.upfronthosting.co.za> Message-ID: <1345244372.31.0.0985585563237.issue15645@psf.upfronthosting.co.za> Ned Deily added the comment: I took a quick look at the issue and I could reproduce by doing a "make install" of 3.3.0b1 then a build and "make install" of 3.3.0b2 in the same locations. Doing a clean 3.3.0b2 build and install produce the expected results. It appears to be a unix Makefile issue that shouldn't be unique to OS X. I don't have time to look further into it right at the moment, though. (And I'm not sure what "known problems with 3.3 and mac" means; the buildbots are happy.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 01:14:25 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 17 Aug 2012 23:14:25 +0000 Subject: [issue15694] link to "file object" glossary entry in open() and io docs In-Reply-To: <1345133191.76.0.682782918752.issue15694@psf.upfronthosting.co.za> Message-ID: <1345245265.1.0.74977677466.issue15694@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Thanks. Could either one of you commit this for me? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 02:40:19 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 Aug 2012 00:40:19 +0000 Subject: [issue15694] link to "file object" glossary entry in open() and io docs In-Reply-To: <1345133191.76.0.682782918752.issue15694@psf.upfronthosting.co.za> Message-ID: <3WzMrJ3G91zQ6q@mail.python.org> Roundup Robot added the comment: New changeset 1d5c451a1365 by R David Murray in branch '3.2': #15694: Link discussion of file objects to glossary entry. http://hg.python.org/cpython/rev/1d5c451a1365 New changeset 977606940531 by R David Murray in branch 'default': Merge #15694: Link discussion of file objects to glossary entry. http://hg.python.org/cpython/rev/977606940531 New changeset 083c37e75c49 by R David Murray in branch '3.2': #15694: reflow paragraph. http://hg.python.org/cpython/rev/083c37e75c49 New changeset d57ea50bc526 by R David Murray in branch 'default': Merge #15694: reflow paragraph. http://hg.python.org/cpython/rev/d57ea50bc526 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 02:40:55 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 18 Aug 2012 00:40:55 +0000 Subject: [issue15694] link to "file object" glossary entry in open() and io docs In-Reply-To: <1345133191.76.0.682782918752.issue15694@psf.upfronthosting.co.za> Message-ID: <1345250455.57.0.430045134391.issue15694@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Chris. ---------- nosy: +r.david.murray resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 02:50:45 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 Aug 2012 00:50:45 +0000 Subject: [issue15355] generator docs should mention already-executing exception In-Reply-To: <1342312261.31.0.534711044354.issue15355@psf.upfronthosting.co.za> Message-ID: <3WzN4J5H1wzQ2P@mail.python.org> Roundup Robot added the comment: New changeset dc4b00f51c48 by R David Murray in branch '3.2': #15355: Mention already-executing Exception in generator docs. http://hg.python.org/cpython/rev/dc4b00f51c48 New changeset 73f1ba3319dd by R David Murray in branch 'default': Merge #15355: Mention already-executing Exception in generator docs. http://hg.python.org/cpython/rev/73f1ba3319dd New changeset a62309ae88a2 by R David Murray in branch '2.7': #15355: Mention already-executing Exception in generator docs. http://hg.python.org/cpython/rev/a62309ae88a2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 02:52:13 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 18 Aug 2012 00:52:13 +0000 Subject: [issue15355] generator docs should mention already-executing exception In-Reply-To: <1342312261.31.0.534711044354.issue15355@psf.upfronthosting.co.za> Message-ID: <1345251133.72.0.790993563815.issue15355@psf.upfronthosting.co.za> R. David Murray added the comment: Confirmed that 2.7 raises the same errors (as I expected) using your test. Thanks, Chris. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 02:56:15 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 Aug 2012 00:56:15 +0000 Subject: [issue15636] base64.decodebytes is only available in Python3.1+ In-Reply-To: <1344858430.17.0.615853795219.issue15636@psf.upfronthosting.co.za> Message-ID: <3WzNBk3wH7zPvn@mail.python.org> Roundup Robot added the comment: New changeset ca5b36754892 by R David Murray in branch '3.2': #15636: add versionadded for decodebytes http://hg.python.org/cpython/rev/ca5b36754892 New changeset a343fa692bb0 by R David Murray in branch 'default': Merge #15636: add versionadded for decodebytes http://hg.python.org/cpython/rev/a343fa692bb0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 02:56:38 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 18 Aug 2012 00:56:38 +0000 Subject: [issue15636] base64.decodebytes is only available in Python3.1+ In-Reply-To: <1344858430.17.0.615853795219.issue15636@psf.upfronthosting.co.za> Message-ID: <1345251398.77.0.751641084572.issue15636@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 03:12:18 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 18 Aug 2012 01:12:18 +0000 Subject: [issue9271] Python throws `IOError: [Errno 27] File too large' on long file names In-Reply-To: <1279259347.56.0.547870211974.issue9271@psf.upfronthosting.co.za> Message-ID: <1345252338.07.0.524820933235.issue9271@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: -> committed/rejected status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 04:41:41 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 Aug 2012 02:41:41 +0000 Subject: [issue15586] Provide some examples for usage of ElementTree methods/attributes In-Reply-To: <1344407679.24.0.102359835139.issue15586@psf.upfronthosting.co.za> Message-ID: <3WzQXN19B9zPtn@mail.python.org> Roundup Robot added the comment: New changeset 094423a65a4e by Eli Bendersky in branch '2.7': Issue #15586: porting ET's new documentation bits to 2.7. Patch by Daniel Ellis http://hg.python.org/cpython/rev/094423a65a4e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 04:43:24 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 Aug 2012 02:43:24 +0000 Subject: [issue15586] Provide some examples for usage of ElementTree methods/attributes In-Reply-To: <1344407679.24.0.102359835139.issue15586@psf.upfronthosting.co.za> Message-ID: <3WzQZL6NcTzQ1g@mail.python.org> Roundup Robot added the comment: New changeset 7012f6a74f66 by Eli Bendersky in branch 'default': Issue #15586: fix prompts in some documentation examples http://hg.python.org/cpython/rev/7012f6a74f66 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 05:22:40 2012 From: report at bugs.python.org (Eric Snow) Date: Sat, 18 Aug 2012 03:22:40 +0000 Subject: [issue14905] zipimport.c needs to support namespace packages when no 'directory' entry exists In-Reply-To: <1337905627.12.0.841961188355.issue14905@psf.upfronthosting.co.za> Message-ID: <1345260160.56.0.519743136156.issue14905@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 05:38:09 2012 From: report at bugs.python.org (Eric Snow) Date: Sat, 18 Aug 2012 03:38:09 +0000 Subject: [issue15720] move __import__() out of the default lookup chain Message-ID: <1345261089.07.0.0712105087978.issue15720@psf.upfronthosting.co.za> New submission from Eric Snow: When people want to import modules with "runtime" names, they regrettably turn to __import__(), have done so for many years, and likely will for a while. If it were less convenient to use __import__(), fewer people would use it. I'm putting together a patch that removes it from .__builtins__, so that it will not be found during normal name lookup. However, it will still available for the adventurous spirit via the imp module, following the precedent of reload(). This proposal came up in issue15715. ---------- components: Interpreter Core messages: 168493 nosy: brett.cannon, eric.snow priority: normal severity: normal stage: needs patch status: open title: move __import__() out of the default lookup chain type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 05:38:50 2012 From: report at bugs.python.org (Eric Snow) Date: Sat, 18 Aug 2012 03:38:50 +0000 Subject: [issue15715] __import__ now raises with non-existing items in fromlist in 3.3 In-Reply-To: <1345156928.79.0.203974969225.issue15715@psf.upfronthosting.co.za> Message-ID: <1345261130.19.0.076535213726.issue15715@psf.upfronthosting.co.za> Eric Snow added the comment: I've taken the tanget over to issue15720. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 07:59:46 2012 From: report at bugs.python.org (Eric Snow) Date: Sat, 18 Aug 2012 05:59:46 +0000 Subject: [issue15578] Crash when modifying sys.modules during import In-Reply-To: <1344372630.36.0.657008264392.issue15578@psf.upfronthosting.co.za> Message-ID: <1345269586.97.0.658354884733.issue15578@psf.upfronthosting.co.za> Eric Snow added the comment: Here's the deal. import_module_level() gets called for v1 from sa (where "globals" comes from). In that function it first calls get_parent(), which returns a borrowed reference to the sa module object. Then that parent object is passed to load_next() where the actual load of v1 will take place (and the segfault happens). The problem is that get_parent() returns a borrowed reference. When the sa module is replaced in sys.modules, the old sa module is decref'ed. That's fine except load_next is using that same module as the parent. Enter segfault, stage left. Here's a quick patch that fixes the failure (along with a test). ---------- keywords: +patch nosy: +brett.cannon, eric.snow stage: -> patch review Added file: http://bugs.python.org/file26883/eric.snow_issue15578.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 08:04:42 2012 From: report at bugs.python.org (Eric Snow) Date: Sat, 18 Aug 2012 06:04:42 +0000 Subject: [issue15716] Ability to specify the PYTHONPATH via a command line flag In-Reply-To: <1345164027.44.0.397805734201.issue15716@psf.upfronthosting.co.za> Message-ID: <1345269882.4.0.480411746625.issue15716@psf.upfronthosting.co.za> Eric Snow added the comment: Would issue14803 be sufficient? Certainly not quite as concise, but deferring to that solution would limit the proliferation of command-line arguments to the interpreter. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 08:17:56 2012 From: report at bugs.python.org (Eric Snow) Date: Sat, 18 Aug 2012 06:17:56 +0000 Subject: [issue15720] move __import__() out of the default lookup chain In-Reply-To: <1345261089.07.0.0712105087978.issue15720@psf.upfronthosting.co.za> Message-ID: <1345270676.45.0.923256145696.issue15720@psf.upfronthosting.co.za> Eric Snow added the comment: Ah, __import__() is used all over the place in the stdlib. I won't have time right away to put together the patch then. However, here's what I'm planning: * expose builtin___import__() (from Python/bltinmodule.c) as imp.__import__(). * expose one used by the interpreter as builtins.__import__(), thus keeping it replaceable. * hide it in .__builtins__. That last part is the tricky part, and has a bit of a smell to it... Simply removing it from builtins would be easiest, but that still seems like the right place to go when you want to replace it with your own flashy __import__(). Insight appreciated, but this is definitely low priority at least for the next few months. ---------- priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 10:43:12 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 18 Aug 2012 08:43:12 +0000 Subject: [issue15477] test_cmath failures on OS X 10.8 In-Reply-To: <1343469837.83.0.840988569572.issue15477@psf.upfronthosting.co.za> Message-ID: <1345279392.63.0.495051440208.issue15477@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- assignee: -> mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 11:17:14 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 18 Aug 2012 09:17:14 +0000 Subject: [issue15477] test_cmath failures on OS X 10.8 In-Reply-To: <1343469837.83.0.840988569572.issue15477@psf.upfronthosting.co.za> Message-ID: <1345281434.64.0.213696665511.issue15477@psf.upfronthosting.co.za> Mark Dickinson added the comment: Trent, many thanks for the report and analysis. The LOG1P_DROPS_ZERO_SIGN hackery was a result of a previous attempt to 'fix' the tests on another platform whose log1p didn't preserve zero signs. But now that this behaviour has emerged on OS X too, I think it might be time to fix this in the Python core code (i.e., add a workaround for the buggy OS behaviour) instead of trying to make the tests pass again. Attached is a patch that adds a workaround for this on all platforms that have a system log1p. I was originally thinking of adding this workaround only on OS X (so as not to unnecessarily punish those platforms that get it right), but after running some timings (see below) it seems that the workaround is insignificant performance-wise, so we might as well keep things simple and add it on all platforms. Trent, if you have time, please could you try this patch on OS X 10.8 and see if it fixes all the test_cmath and test_math failures? Some timings on OS X 10.6. Current default branch (pass value directly onto system log1p): iwasawa:cpython mdickinson$ ./python.exe -m timeit -s 'from math import log1p; x = 2.3' 'log1p(x)' 10000000 loops, best of 3: 0.0685 usec per loop With the attached patch (do zero check, then pass value directly onto system log1p): iwasawa:cpython mdickinson$ ./python.exe -m timeit -s 'from math import log1p; x = 2.3' 'log1p(x)' 10000000 loops, best of 3: 0.0686 usec per loop ---------- Added file: http://bugs.python.org/file26884/log1p_sign_workaround.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 11:21:40 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 18 Aug 2012 09:21:40 +0000 Subject: [issue15477] test_cmath failures on OS X 10.8 In-Reply-To: <1343469837.83.0.840988569572.issue15477@psf.upfronthosting.co.za> Message-ID: <1345281700.87.0.0247322928092.issue15477@psf.upfronthosting.co.za> Mark Dickinson added the comment: Updated patch that also removes the sysconfig checks from the cmath tests. ---------- Added file: http://bugs.python.org/file26885/log1p_sign_workaround.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 11:22:01 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 18 Aug 2012 09:22:01 +0000 Subject: [issue15477] test_cmath failures on OS X 10.8 In-Reply-To: <1343469837.83.0.840988569572.issue15477@psf.upfronthosting.co.za> Message-ID: <1345281721.33.0.0688532468861.issue15477@psf.upfronthosting.co.za> Changes by Mark Dickinson : Removed file: http://bugs.python.org/file26884/log1p_sign_workaround.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 11:25:50 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 18 Aug 2012 09:25:50 +0000 Subject: [issue15477] test_cmath failures on OS X 10.8 In-Reply-To: <1343469837.83.0.840988569572.issue15477@psf.upfronthosting.co.za> Message-ID: <1345281950.04.0.146081088578.issue15477@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- components: +Extension Modules stage: -> patch review type: -> behavior versions: +Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 11:32:25 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 18 Aug 2012 09:32:25 +0000 Subject: [issue15477] test_cmath failures on OS X 10.8 In-Reply-To: <1343469837.83.0.840988569572.issue15477@psf.upfronthosting.co.za> Message-ID: <1345282345.2.0.852785309124.issue15477@psf.upfronthosting.co.za> Mark Dickinson added the comment: See also http://bugs.python.org/issue9920; the patch here *should* fix that issue, too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 11:33:09 2012 From: report at bugs.python.org (Trent Nelson) Date: Sat, 18 Aug 2012 09:33:09 +0000 Subject: [issue15477] test_cmath failures on OS X 10.8 In-Reply-To: <1343469837.83.0.840988569572.issue15477@psf.upfronthosting.co.za> Message-ID: <1345282389.61.0.510074051034.issue15477@psf.upfronthosting.co.za> Trent Nelson added the comment: Happy to report your patch does the trick Mark. test_cmath passes on 10.7 and 10.8 with it applied. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 12:25:46 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Sat, 18 Aug 2012 10:25:46 +0000 Subject: [issue15588] quopri: encodestring and decodestring handle bytes, not strings In-Reply-To: <1344411059.45.0.404148694214.issue15588@psf.upfronthosting.co.za> Message-ID: <1345285546.47.0.995775534725.issue15588@psf.upfronthosting.co.za> Petri Lehtinen added the comment: The encode() and decode() functions also expect binary file objects. Attached a patch that changes documentation and docstrings. Removed the mentions of readline(), because read() is called on input instead, if the binascii module is available. Also removed the repeated descriptions of quotetabs and header in encodestring()'s docs. ---------- keywords: +needs review, patch nosy: +petri.lehtinen stage: -> patch review Added file: http://bugs.python.org/file26886/issue15588.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 12:27:02 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 18 Aug 2012 10:27:02 +0000 Subject: [issue15477] test_cmath failures on OS X 10.8 In-Reply-To: <1343469837.83.0.840988569572.issue15477@psf.upfronthosting.co.za> Message-ID: <1345285622.2.0.413298498587.issue15477@psf.upfronthosting.co.za> Martin v. L?wis added the comment: BTW, did anybody file a bug report with Apple? Even to my untrained eye, that looks like a clear violation of the POSIX standard: If x is ?0, or +Inf, x shall be returned. http://pubs.opengroup.org/onlinepubs/009604599/functions/log1p.html C seems to make it implementation-defined, unless the implementation defines __STDC_IEC_559__, in which case log1p also needs to return ?0 (C99 F.9.3.9, C11 F.10.3.9). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 12:53:45 2012 From: report at bugs.python.org (Robin Schreiber) Date: Sat, 18 Aug 2012 10:53:45 +0000 Subject: [issue15721] PEP 3121, 384 Refactoring applied to tkinter module Message-ID: <1345287224.98.0.204885883161.issue15721@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the tkinter module! When running the test form inside Python.exe (tkinter._test()), the litte "test-window" is rendered correctly. However there are still some error messages popping up inside the python shell (I am running this on OS X 10.8): >>> tkinter._test() 2012-08-18 12:46:24.775 python.exe[17410:707] speedup (null) 2012-08-18 12:46:24.776 python.exe[17410:707] ERROR: Unable to find method [_NSFullScreenTransition _startFullScreenTransitionForCGWindow:targetFrame:duration:]. 2012-08-18 12:46:24.776 python.exe[17410:707] ERROR: Unable to find method [_NSFullScreenTransition _startEnterFullScreenTransitionForCGWindow:targetFrame:duration:]. 2012-08-18 12:46:24.778 python.exe[17410:707] ERROR: Unable to find method [_NSFullScreenTransition startExitFullScreenTransitionForCGWindow:targetFrame:duration:]. [87221 refs] >>> I have no Idea how and where these are triggered. ---------- components: Extension Modules files: _tkinter_pep3121-384_v0.patch keywords: patch messages: 168504 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121, 384 Refactoring applied to tkinter module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26887/_tkinter_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 12:58:32 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 18 Aug 2012 10:58:32 +0000 Subject: [issue15721] PEP 3121, 384 Refactoring applied to tkinter module In-Reply-To: <1345287224.98.0.204885883161.issue15721@psf.upfronthosting.co.za> Message-ID: <1345287512.31.0.694984878188.issue15721@psf.upfronthosting.co.za> Martin v. L?wis added the comment: See http://www.python.org/download/mac/tcltk/ It may be that using a different build of Tcl/Tk solves that problem. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 12:59:09 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 18 Aug 2012 10:59:09 +0000 Subject: [issue15477] test_cmath failures on OS X 10.8 In-Reply-To: <1343469837.83.0.840988569572.issue15477@psf.upfronthosting.co.za> Message-ID: <1345287548.99.0.933614526923.issue15477@psf.upfronthosting.co.za> Mark Dickinson added the comment: > BTW, did anybody file a bug report with Apple? I'll file one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 13:24:51 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 Aug 2012 11:24:51 +0000 Subject: [issue15477] test_cmath failures on OS X 10.8 In-Reply-To: <1343469837.83.0.840988569572.issue15477@psf.upfronthosting.co.za> Message-ID: <3Wzf823hs8zQ7n@mail.python.org> Roundup Robot added the comment: New changeset 08418369da7b by Mark Dickinson in branch '3.2': Issue #15477: Add workaround for log1p(-0.0) on platforms where it's broken. http://hg.python.org/cpython/rev/08418369da7b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 13:26:28 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 Aug 2012 11:26:28 +0000 Subject: [issue15477] test_cmath failures on OS X 10.8 In-Reply-To: <1343469837.83.0.840988569572.issue15477@psf.upfronthosting.co.za> Message-ID: <3Wzf9q4fWpzPrb@mail.python.org> Roundup Robot added the comment: New changeset 336653319112 by Mark Dickinson in branch 'default': Issue #15477: Merge fix from 3.2 http://hg.python.org/cpython/rev/336653319112 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 13:32:36 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 18 Aug 2012 11:32:36 +0000 Subject: [issue15477] test_cmath failures on OS X 10.8 In-Reply-To: <1343469837.83.0.840988569572.issue15477@psf.upfronthosting.co.za> Message-ID: <1345289556.54.0.0574119778234.issue15477@psf.upfronthosting.co.za> Mark Dickinson added the comment: Apple bug report filed: Bug ID# 12128251. Closing the issue. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 13:35:00 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 18 Aug 2012 11:35:00 +0000 Subject: [issue9920] test_cmath on atan fails on AIX In-Reply-To: <1285164788.53.0.85582412597.issue9920@psf.upfronthosting.co.za> Message-ID: <1345289700.98.0.38039326571.issue9920@psf.upfronthosting.co.za> Mark Dickinson added the comment: The fix applied for issue #15477 should also fix this issue. ---------- status: open -> closed versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 14:31:12 2012 From: report at bugs.python.org (Robin Schreiber) Date: Sat, 18 Aug 2012 12:31:12 +0000 Subject: [issue15722] PEP 3121, 384 Refactoring applied to decimal module Message-ID: <1345293070.72.0.383930872934.issue15722@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the decimal module! ---------- components: Regular Expressions files: _decimal_pep3121-384_v0.patch keywords: patch messages: 168511 nosy: Robin.Schreiber, ezio.melotti, mrabarnett, skrah priority: normal severity: normal status: open title: PEP 3121, 384 Refactoring applied to decimal module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26888/_decimal_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 15:11:01 2012 From: report at bugs.python.org (Robin Schreiber) Date: Sat, 18 Aug 2012 13:11:01 +0000 Subject: [issue15722] PEP 3121, 384 Refactoring applied to decimal module In-Reply-To: <1345293070.72.0.383930872934.issue15722@psf.upfronthosting.co.za> Message-ID: <1345295461.94.0.189424774509.issue15722@psf.upfronthosting.co.za> Changes by Robin Schreiber : ---------- components: +Extension Modules -Regular Expressions _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 15:29:58 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 18 Aug 2012 13:29:58 +0000 Subject: [issue15720] move __import__() out of the default lookup chain In-Reply-To: <1345261089.07.0.0712105087978.issue15720@psf.upfronthosting.co.za> Message-ID: <1345296598.46.0.978348229622.issue15720@psf.upfronthosting.co.za> R. David Murray added the comment: I could be wrong, but it is hard for me to see how we could justify doing this before python4, at this point in python3. Adding a warning would be uncontroversial, though. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 15:30:37 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 18 Aug 2012 13:30:37 +0000 Subject: [issue15720] move __import__() out of the default lookup chain In-Reply-To: <1345261089.07.0.0712105087978.issue15720@psf.upfronthosting.co.za> Message-ID: <1345296637.46.0.542768890125.issue15720@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 15:31:14 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 18 Aug 2012 13:31:14 +0000 Subject: [issue14803] Add feature to allow code execution prior to __main__ invocation In-Reply-To: <1336981419.55.0.280530546632.issue14803@psf.upfronthosting.co.za> Message-ID: <1345296674.09.0.253773001286.issue14803@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 15:31:47 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 18 Aug 2012 13:31:47 +0000 Subject: [issue15716] Ability to specify the PYTHONPATH via a command line flag In-Reply-To: <1345164027.44.0.397805734201.issue15716@psf.upfronthosting.co.za> Message-ID: <1345296707.52.0.839919801047.issue15716@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 15:36:05 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 18 Aug 2012 13:36:05 +0000 Subject: [issue14905] zipimport.c needs to support namespace packages when no 'directory' entry exists In-Reply-To: <1337905627.12.0.841961188355.issue14905@psf.upfronthosting.co.za> Message-ID: <1345296965.76.0.428732313985.issue14905@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 15:36:51 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 18 Aug 2012 13:36:51 +0000 Subject: [issue15645] 2to3 Grammar pickles not created when upgrading to 3.3.0b2 In-Reply-To: <1344932180.41.0.826216341416.issue15645@psf.upfronthosting.co.za> Message-ID: <1345297011.44.0.444082647167.issue15645@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 15:38:03 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 18 Aug 2012 13:38:03 +0000 Subject: [issue15718] Possible OverflowError in __len__ method undocumented (when called via len() function) In-Reply-To: <1345202279.02.0.767068523185.issue15718@psf.upfronthosting.co.za> Message-ID: <1345297083.15.0.17004989442.issue15718@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 15:38:40 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 18 Aug 2012 13:38:40 +0000 Subject: [issue15641] Clean up importlib for Python 3.4 In-Reply-To: <1344888035.57.0.935580041455.issue15641@psf.upfronthosting.co.za> Message-ID: <1345297120.34.0.104666295466.issue15641@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 15:41:16 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 18 Aug 2012 13:41:16 +0000 Subject: [issue15649] subprocess.Popen.communicate: accept str for input parameter if universal_newlines is False In-Reply-To: <1344959221.38.0.0409924242397.issue15649@psf.upfronthosting.co.za> Message-ID: <1345297276.22.0.568233904453.issue15649@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 16:05:30 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 18 Aug 2012 14:05:30 +0000 Subject: [issue15722] PEP 3121, 384 Refactoring applied to decimal module In-Reply-To: <1345293070.72.0.383930872934.issue15722@psf.upfronthosting.co.za> Message-ID: <1345298730.16.0.829059962811.issue15722@psf.upfronthosting.co.za> Stefan Krah added the comment: Thank you for the patch and the big amount of work that you are doing on so many modules! I'm afraid though that the patch is not acceptable in its current state: 1) The unit tests do not pass. This could be fixed. 2) The patch slows down _decimal by 25% (!). If 2) cannot be fixed due to the increased amount of state lookups, I'm firmly -1 on applying pep-3121 changes to _decimal (and any other speed sensitive module). ---------- nosy: +mark.dickinson, rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 16:08:41 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 18 Aug 2012 14:08:41 +0000 Subject: [issue15722] PEP 3121, 384 Refactoring applied to decimal module In-Reply-To: <1345293070.72.0.383930872934.issue15722@psf.upfronthosting.co.za> Message-ID: <1345298921.56.0.423942175671.issue15722@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- assignee: -> skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 16:09:14 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 18 Aug 2012 14:09:14 +0000 Subject: [issue15668] PEP 3121, 384 Refactoring applied to random module In-Reply-To: <1345039836.78.0.438193538839.issue15668@psf.upfronthosting.co.za> Message-ID: <1345298954.6.0.207507145929.issue15668@psf.upfronthosting.co.za> Stefan Krah added the comment: I tried to benchmark this patch but I'm getting a segfault: Python 3.3.0b2+ (default:dc18d73e67a5, Aug 18 2012, 15:37:04) [GCC 4.4.3] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import random Segmentation fault ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 16:10:00 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 18 Aug 2012 14:10:00 +0000 Subject: [issue15672] PEP 3121, 384 Refactoring applied to testbuffer module In-Reply-To: <1345042259.48.0.277311619921.issue15672@psf.upfronthosting.co.za> Message-ID: <1345299000.12.0.997905469156.issue15672@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- assignee: -> skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 16:50:01 2012 From: report at bugs.python.org (Florent Xicluna) Date: Sat, 18 Aug 2012 14:50:01 +0000 Subject: [issue8323] buffer objects are picklable but result is not unpicklable In-Reply-To: <1270507518.5.0.340159262485.issue8323@psf.upfronthosting.co.za> Message-ID: <1345301401.33.0.242671292884.issue8323@psf.upfronthosting.co.za> Changes by Florent Xicluna : ---------- nosy: +flox _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 17:14:02 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sat, 18 Aug 2012 15:14:02 +0000 Subject: [issue13498] os.makedirs exist_ok documentation is incorrect, as is some of the behavior In-Reply-To: <1322574123.12.0.756700598965.issue13498@psf.upfronthosting.co.za> Message-ID: <1345302842.23.0.0657059060696.issue13498@psf.upfronthosting.co.za> Hynek Schlawack added the comment: Ok, let?s do it here, that?s easier: .. function:: makedirs(path, mode=0o777, exist_ok=False) .. index:: single: directory; creating single: UNC paths; and os.makedirs() Recursive directory creation function. Like :func:`mkdir`, but makes all intermediate-level directories needed to contain the leaf directory. The default *mode* is ``0o777`` (octal). On some systems, *mode* is ignored. Where it is used, the current umask value is first masked out. If the target directory exists, :exc:`OSError` is raised unless *exist_ok* is set to ``True`` and the mode doesn't contradict the designated mode as discussed in the previous paragraph. If the mode doesn't match, :exc:`OSError` is raised regardless of the value of *exist_ok*. If the directory cannot be created in other cases, an :exc:`OSError` exception is raised too. .. note:: :func:`makedirs` will become confused if the path elements to create include :data:`pardir`. This function handles UNC paths correctly. .. versionadded:: 3.2 The *exist_ok* parameter. Python is so much easier than English. :'( ---------- versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 17:35:41 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 18 Aug 2012 15:35:41 +0000 Subject: [issue15668] PEP 3121, 384 Refactoring applied to random module In-Reply-To: <1345039836.78.0.438193538839.issue15668@psf.upfronthosting.co.za> Message-ID: <1345304141.52.0.618365317588.issue15668@psf.upfronthosting.co.za> Mark Dickinson added the comment: The Py_tp_bases line below doesn't look right. I suspect that's what's causing the segfault. +static PyType_Slot Random_Type_slots[] = { + {Py_tp_getattro, PyObject_GenericGetAttr}, + {Py_tp_doc, random_doc}, + {Py_tp_methods, random_methods}, + {Py_tp_new, random_new}, + {Py_tp_free, PyObject_Free}, + {Py_tp_bases, }, + {0, 0} ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 18:14:02 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 18 Aug 2012 16:14:02 +0000 Subject: [issue13498] os.makedirs exist_ok documentation is incorrect, as is some of the behavior In-Reply-To: <1322574123.12.0.756700598965.issue13498@psf.upfronthosting.co.za> Message-ID: <1345306442.74.0.115393838785.issue13498@psf.upfronthosting.co.za> R. David Murray added the comment: This is much better. But let me try tuning the problem paragraph a bit, since I'm a native English speaker: If *exists_ok* is ``False`` (the default), an :exc:`OSError` is raised if the target directory already exists. If *exists_ok* is ``True`` an :exc:`OSError` is still raised if the umask-masked *mode* is different from the existing mode, on systems where the mode is used. :exc:`OSError` will also be raised if the directory creation fails. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 18:16:54 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 18 Aug 2012 16:16:54 +0000 Subject: [issue15668] PEP 3121, 384 Refactoring applied to random module In-Reply-To: <1345039836.78.0.438193538839.issue15668@psf.upfronthosting.co.za> Message-ID: <1345306614.51.0.935183968489.issue15668@psf.upfronthosting.co.za> Mark Dickinson added the comment: With the Py_tp_bases line removed, all tests pass for me on a non-debug 64-bit build on OS X 10.6. A quick timing of random.random() showed no distinguishable performance impact. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 19:13:44 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 18 Aug 2012 17:13:44 +0000 Subject: [issue15668] PEP 3121, 384 Refactoring applied to random module In-Reply-To: <1345306614.51.0.935183968489.issue15668@psf.upfronthosting.co.za> Message-ID: <20120818171345.GA13080@sleipnir.bytereef.org> Stefan Krah added the comment: Thanks, Mark. With your change applied I can't measure any performance differences either. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 19:14:52 2012 From: report at bugs.python.org (Stefan Mihaila) Date: Sat, 18 Aug 2012 17:14:52 +0000 Subject: [issue15642] Integrate pickle protocol version 4 GSoC work by Stefan Mihaila In-Reply-To: <1344890920.23.0.695633734046.issue15642@psf.upfronthosting.co.za> Message-ID: <1345310092.84.0.339428342696.issue15642@psf.upfronthosting.co.za> Stefan Mihaila added the comment: Maybe you can set this issue as the superseder of issue9269, because the patches there have already been applied here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 19:35:20 2012 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 18 Aug 2012 17:35:20 +0000 Subject: [issue15719] Sort dict items in urlencode() In-Reply-To: <1345236293.12.0.120802358061.issue15719@psf.upfronthosting.co.za> Message-ID: <1345311320.53.0.930435041307.issue15719@psf.upfronthosting.co.za> Guido van Rossum added the comment: Note, the sort may fail if e.g. bytes and str are mixed in the keys. So this should be caught and ignored. An alternative would just be to fix the call site to pass in sorted(query.items()) instead of sorted(query). Still, I think that more predictable output would be better. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 20:52:02 2012 From: report at bugs.python.org (Ned Deily) Date: Sat, 18 Aug 2012 18:52:02 +0000 Subject: [issue15721] PEP 3121, 384 Refactoring applied to tkinter module In-Reply-To: <1345287224.98.0.204885883161.issue15721@psf.upfronthosting.co.za> Message-ID: <1345315922.03.0.634291835076.issue15721@psf.upfronthosting.co.za> Ned Deily added the comment: What version of 10.8 are you seeing those messages with? And do you see them without the patch applied? ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 20:54:20 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 Aug 2012 18:54:20 +0000 Subject: [issue15615] More tests for JSON decoder to test Exceptions In-Reply-To: <1344593566.55.0.653447713109.issue15615@psf.upfronthosting.co.za> Message-ID: <3Wzr6g1HPhzQHK@mail.python.org> Roundup Robot added the comment: New changeset cd9a4883dd02 by Antoine Pitrou in branch '3.2': Issue #15615: Add some tests for the json module's handling of invalid input data. http://hg.python.org/cpython/rev/cd9a4883dd02 New changeset 01717c3da4fb by Antoine Pitrou in branch 'default': Issue #15615: Add some tests for the json module's handling of invalid input data. http://hg.python.org/cpython/rev/01717c3da4fb New changeset b16a5f0d0c87 by Antoine Pitrou in branch '2.7': Issue #15615: Add some tests for the json module's handling of invalid input data. http://hg.python.org/cpython/rev/b16a5f0d0c87 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 20:56:02 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 18 Aug 2012 18:56:02 +0000 Subject: [issue15615] More tests for JSON decoder to test Exceptions In-Reply-To: <1344593566.55.0.653447713109.issue15615@psf.upfronthosting.co.za> Message-ID: <1345316162.02.0.824901663587.issue15615@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks and congratulations for your patch! It's now committed to all three branches. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 21:57:27 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 18 Aug 2012 19:57:27 +0000 Subject: [issue15719] Sort dict items in urlencode() In-Reply-To: <1345236293.12.0.120802358061.issue15719@psf.upfronthosting.co.za> Message-ID: <1345319847.87.0.16090768353.issue15719@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Honestly, this looks much more like an enhancement than a bugfix to me, so I think it should only target 3.4. As for the idea proper, I sounds ok to me, as long as only exact dict instances are affected (i.e. OrderedDict and friends keep using their native order). ---------- components: +Library (Lib) nosy: +pitrou type: -> enhancement versions: -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 22:00:04 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 18 Aug 2012 20:00:04 +0000 Subject: [issue15722] PEP 3121, 384 Refactoring applied to decimal module In-Reply-To: <1345293070.72.0.383930872934.issue15722@psf.upfronthosting.co.za> Message-ID: <1345320004.9.0.0849915449162.issue15722@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > 2) The patch slows down _decimal by 25% (!). Ouch. That's an interesting observation, because I guess other modules could be affected as well. Robin, can you please take care that other modules don't have significant performance regressions after your work? I'm not sure what kind of changes it involves, or if it's possible at all, but we don't want to slow down Python for what is mostly (IMO) a code cleanup. ---------- nosy: +loewis, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 22:02:49 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 18 Aug 2012 20:02:49 +0000 Subject: [issue15653] PEP 3121, 384 refactoring applied to hashopenssl module In-Reply-To: <1345224630.27.0.0367899548305.issue15653@psf.upfronthosting.co.za> Message-ID: <1345319985.4150.5.camel@localhost.localdomain> Antoine Pitrou added the comment: > So I'd propose that it is actually the leaf subtype which decrefs > ob_type. The check whether you are the leaf type is then done by > checking whether tp_dealloc is the one you are "in" right now. By leaf, you mean the derived subtype? That sounds a bit quirky (you need the aforementioned "if"), how about the base heap type instead? Speaking of which, what does this refactoring bring exactly? The type declarations are slightly less verbose, but other than that, is there a point? (using the stable ABI doesn't seem to provide any benefit for standard extension modules; besides, using PyType_FromSpec is only a small part of complying with the stable ABI) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 22:19:37 2012 From: report at bugs.python.org (Poul-Henning Kamp) Date: Sat, 18 Aug 2012 20:19:37 +0000 Subject: [issue15723] Python breaks OS' append guarantee on file writes Message-ID: <1345321177.26.0.0602208919047.issue15723@psf.upfronthosting.co.za> New submission from Poul-Henning Kamp: When a file is opened in append mode, the operating system guarantees that all write(2) system calls atomically appended their payload to the file. At least on FreeBSD, Python breaks this guarantee, by chopping up large writes into multiple write(2) syscalls to the OS. Try running this program using ktrace/truss/strace or a similar system-call tracing facility: fo = open("/tmp/_bogus", "ab", 0) fo.write(bytearray(1024*1024)) fo.close() Instead of one single megabyte write, I see 1024 kilobyte writes. (BTW: Why only one kilobyte ? That is an incredible pessimisation these days...) I leave it to the python community to decide if this should be fixed, or merely pointed out in documentation (os.write() is a workaround) ---------- components: None messages: 168528 nosy: bsdphk priority: normal severity: normal status: open title: Python breaks OS' append guarantee on file writes type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 22:22:38 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 18 Aug 2012 20:22:38 +0000 Subject: [issue15723] Python breaks OS' append guarantee on file writes In-Reply-To: <1345321177.26.0.0602208919047.issue15723@psf.upfronthosting.co.za> Message-ID: <1345321358.42.0.438325373197.issue15723@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > When a file is opened in append mode, the operating system guarantees > that all write(2) system calls atomically appended their payload to the > file. Does it? I don't see such strong guarantees in http://pubs.opengroup.org/onlinepubs/9699919799/functions/write.html In any case, Python 2 uses fwrite() not write(), so it may be the explanation. Do you observe the same behaviour when using io.open() instead of open()? (io.open() is the Python 3 IO stack backported to Python 2) ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 22:24:23 2012 From: report at bugs.python.org (Poul-Henning Kamp) Date: Sat, 18 Aug 2012 20:24:23 +0000 Subject: [issue15723] Python breaks OS' append guarantee on file writes In-Reply-To: <1345321177.26.0.0602208919047.issue15723@psf.upfronthosting.co.za> Message-ID: <1345321463.63.0.829635869369.issue15723@psf.upfronthosting.co.za> Poul-Henning Kamp added the comment: Yes, it does: If the O_APPEND flag of the file status flags is set, the file offset shall be set to the end of the file prior to each write and no intervening file modification operation shall occur between changing the file offset and the write operation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 22:25:14 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 18 Aug 2012 20:25:14 +0000 Subject: [issue15723] Python breaks OS' append guarantee on file writes In-Reply-To: <1345321177.26.0.0602208919047.issue15723@psf.upfronthosting.co.za> Message-ID: <1345321514.28.0.751365443853.issue15723@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ah, sorry. I was stupidly looking for "atomic" and only found the pipe-specific remarks. (the other points remain, though :-)) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 22:30:09 2012 From: report at bugs.python.org (Poul-Henning Kamp) Date: Sat, 18 Aug 2012 20:30:09 +0000 Subject: [issue15723] Python breaks OS' append guarantee on file writes In-Reply-To: <1345321177.26.0.0602208919047.issue15723@psf.upfronthosting.co.za> Message-ID: <1345321809.28.0.754330519069.issue15723@psf.upfronthosting.co.za> Poul-Henning Kamp added the comment: I have not tried io.open(), nor would I suspect most users would realize that they needed to do so, in order to get the canonical behaviour from an operation called "write" on a file opened in "append" mode. IMO: If pythons file.write() does not give the guarantee POLA would indicate, it's either a bug or a doc-issue, no matter how many workarounds might exist. But I have neither a clue to the aspirational goals of python, nor to what it might take to fix this, so it's entirely your call. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 22:36:40 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 18 Aug 2012 20:36:40 +0000 Subject: [issue15723] Python breaks OS' append guarantee on file writes In-Reply-To: <1345321809.28.0.754330519069.issue15723@psf.upfronthosting.co.za> Message-ID: <1345322014.4150.11.camel@localhost.localdomain> Antoine Pitrou added the comment: > I have not tried io.open(), nor would I suspect most users would > realize that they needed to do so, in order to get the canonical > behaviour from an operation called "write" on a file opened in > "append" mode. The reason I'm asking is that open() is the same as io.open() in Python 3.x, which is currently the main development line. That said, I can find the results myself. Python 2 is in bugfix mode, so it's impossible to rewrite the I/O routines to use unbuffered I/O instead of C buffered I/O. > IMO: If pythons file.write() does not give the guarantee POLA would > indicate, it's either a bug or a doc-issue, no matter how many > workarounds might exist. What do you call POLA? > But I have neither a clue to the aspirational goals of python, nor to > what it might take to fix this, so it's entirely your call. Well as I said, Python 2 will be pretty much impossible to fix (we call fwrite() with the argument, not write()). Python 3 is a different story since we use our own buffering layer and then C's unbuffered API. As a sidenote, do you know if writev() has the same guarantee as write()? POSIX doesn't seem to say so. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 22:50:31 2012 From: report at bugs.python.org (Poul-Henning Kamp) Date: Sat, 18 Aug 2012 20:50:31 +0000 Subject: [issue15723] Python breaks OS' append guarantee on file writes In-Reply-To: <1345321177.26.0.0602208919047.issue15723@psf.upfronthosting.co.za> Message-ID: <1345323031.9.0.496959679486.issue15723@psf.upfronthosting.co.za> Poul-Henning Kamp added the comment: POLA = Principle Of Least Astonishment We use that a lot in architectural decision in FreeBSD :-) As I said: You deal with this as you see fit. If all python2 gets is a doc- or errata-notice, that's perfectly fine with me. I interpret "The writev() function shall be equivalent to write(), except as described below." as writev() giving the same atomic append guarantee. In FreeBSD, write() is implemented using writev() and I expect that is the obvious and thus common way it is done. (You seem to be right with respect to the 1024: That is indeed still the BUFSIZ on FreeBSD, I'll work on getting that changed.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 18 23:33:48 2012 From: report at bugs.python.org (Roger Serwy) Date: Sat, 18 Aug 2012 21:33:48 +0000 Subject: [issue1574] Touchpad 2 Finger scroll does not work in IDLE on Mac (But scroll wheel of external mouse does) In-Reply-To: <1205799861.09.0.525919108741.issue1574@psf.upfronthosting.co.za> Message-ID: <1345325628.18.0.298315736784.issue1574@psf.upfronthosting.co.za> Roger Serwy added the comment: Tk support on Mac has improved greatly since 2008. Is this still a valid issue? ---------- nosy: +serwy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 00:36:40 2012 From: report at bugs.python.org (Robin Schreiber) Date: Sat, 18 Aug 2012 22:36:40 +0000 Subject: [issue15722] PEP 3121, 384 Refactoring applied to decimal module In-Reply-To: <1345293070.72.0.383930872934.issue15722@psf.upfronthosting.co.za> Message-ID: <1345329400.69.0.320813862108.issue15722@psf.upfronthosting.co.za> Robin Schreiber added the comment: I have removed some redundant modulestate lookups and the testsuite now executes the decimal tests as fast as before the patch is applied. (at least for me). May I ask how you tested the decimal performance? Regarding the failing test: It appears that the hackcheck() method in typeobject.c is responsible for this failure: static int hackcheck(PyObject *self, setattrofunc func, char *what) { PyTypeObject *type = Py_TYPE(self); while (type && type->tp_flags & Py_TPFLAGS_HEAPTYPE) type = type->tp_base; /* If type is NULL now, this is a really weird type. In the spirit of backwards compatibility (?), just shut up. */ if (type && type->tp_setattro != func) { PyErr_Format(PyExc_TypeError, "can't apply this %s to %s object", what, type->tp_name); return 0; } return 1; } As the context-type is now a heaptype the while-loop will continue to jump to the basetype of the conext-type, which is the object-type. There it ultimately fails when it compares func (context_setattr) to the tp_setattr of object. Anyway, I do not understand the purpose of the hackcheck method, so I can not propose any kind of solution for this problem. ---------- Added file: http://bugs.python.org/file26889/_decimal_pep3121-384_v1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 00:53:37 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 18 Aug 2012 22:53:37 +0000 Subject: [issue15526] test_startfile crash on Windows 7 AMD64 In-Reply-To: <1343827804.07.0.425515249327.issue15526@psf.upfronthosting.co.za> Message-ID: <1345330417.43.0.750717613116.issue15526@psf.upfronthosting.co.za> Antoine Pitrou added the comment: It crashed again, despite issue15496 being fixed: http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/496 ---------- title: regrtest crash on Windows 7 AMD64 -> test_startfile crash on Windows 7 AMD64 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 01:00:23 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 18 Aug 2012 23:00:23 +0000 Subject: [issue15653] PEP 3121, 384 refactoring applied to hashopenssl module In-Reply-To: <1345319985.4150.5.camel@localhost.localdomain> Message-ID: <20120819010021.Horde.xC7be0lCcOxQMB6F6aBic7A@webmail.df.eu> Martin v. L?wis added the comment: > By leaf, you mean the derived subtype? That sounds a bit quirky (you > need the aforementioned "if"), how about the base heap type instead? I think this fails (currently) because a subtype defined in Python using a "class" statement will automatically get subtype_dealloc as its dealloc function, which will in turn unconditionally decrefs the type (after calling the tp_dealloc function from its nearest ancestor which doesn't use subtype_dealloc). > Speaking of which, what does this refactoring bring exactly? The type > declarations are slightly less verbose, but other than that, is there a > point? It's really about the PEP 3121 changes: modules shouldn't have any global variables shared across interpreters, so that module cleanup can work properly. Ultimately, this can lead to gc-based shutdown, module unloading, and better separation of interpreters. In addition, it further reduces the differences between "extension types" and "classes" (which supposedly were removed by dropping old-style classes, yet some inconsistencies remain where the interpreter offers some features only to heaptypes). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 01:13:32 2012 From: report at bugs.python.org (Greg Stein) Date: Sat, 18 Aug 2012 23:13:32 +0000 Subject: [issue15653] PEP 3121, 384 refactoring applied to hashopenssl module In-Reply-To: <1344969733.85.0.308586175776.issue15653@psf.upfronthosting.co.za> Message-ID: <1345331612.09.0.231491332877.issue15653@psf.upfronthosting.co.za> Changes by Greg Stein : ---------- nosy: -gstein _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 01:14:02 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 18 Aug 2012 23:14:02 +0000 Subject: [issue15723] Python breaks OS' append guarantee on file writes In-Reply-To: <1345321177.26.0.0602208919047.issue15723@psf.upfronthosting.co.za> Message-ID: <1345331642.02.0.242995519821.issue15723@psf.upfronthosting.co.za> R. David Murray added the comment: Even if we write in chunks, if we are calling the OS write function and O_APPEND is set, wouldn't be satisfying the condition? Or, rather, the OS would be. That is, I don't really see a guarantee of an *atomic* write in the quoted description. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 01:20:05 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 18 Aug 2012 23:20:05 +0000 Subject: [issue15723] Python breaks OS' append guarantee on file writes In-Reply-To: <1345331642.02.0.242995519821.issue15723@psf.upfronthosting.co.za> Message-ID: <1345331819.4150.16.camel@localhost.localdomain> Antoine Pitrou added the comment: > Even if we write in chunks, if we are calling the OS write function > and O_APPEND is set, wouldn't be satisfying the condition? Or, > rather, the OS would be. That is, I don't really see a guarantee of > an *atomic* write in the quoted description. I'm not sure it's guaranteed to be atomic at the hardware level, but as AFAIU the updates should be atomic as seen from other processes on the same machine (i.e. filesystem cache coherency). As a side-note, I've just tested under Linux with the following script: with open("foo", "ab") as f: f.write(b"abcd") f.write(b"x" * (1024 ** 2)) Results: - on 2.7, the write buffers get sliced up (the glibc's fwrite() doesn't care about atomicity): write(3, "abcdxxxxxxxxxxxxxxxxxxxxxxxxxxxx"..., 4096) = 4096 write(3, "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"..., 1044480) = 1044480 - on 3.2 and 3.3, our home-grown buffering respects the original buffers: write(3, "abcd", 4) = 4 write(3, "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"..., 1048576) = 1048576 (but that's purely out of luck, since we didn't design it with that goal :-)) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 01:33:56 2012 From: report at bugs.python.org (Ned Deily) Date: Sat, 18 Aug 2012 23:33:56 +0000 Subject: [issue1574] Touchpad 2 Finger scroll does not work in IDLE on Mac (But scroll wheel of external mouse does) In-Reply-To: <1205799861.09.0.525919108741.issue1574@psf.upfronthosting.co.za> Message-ID: <1345332836.58.0.434231737776.issue1574@psf.upfronthosting.co.za> Ned Deily added the comment: On current OS X systems (tested on OS X 10.7.4), the 2-finger scrolling gesture scrolls IDLE text editor windows with long files, tested with current versions of ActiveTcl 8.5 and ActiveTcl 8.4. So I think the issue can be closed. ---------- nosy: +ned.deily resolution: -> works for me stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 01:54:09 2012 From: report at bugs.python.org (Trent Nelson) Date: Sat, 18 Aug 2012 23:54:09 +0000 Subject: [issue15285] test_timeout failure when system on IPv4 10.x.x.x subnet In-Reply-To: <1341678423.78.0.865179228191.issue15285@psf.upfronthosting.co.za> Message-ID: <1345334049.15.0.311466802787.issue15285@psf.upfronthosting.co.za> Trent Nelson added the comment: Proposed patch attached. ---------- keywords: +patch nosy: +trent Added file: http://bugs.python.org/file26890/test_timeout.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 02:29:52 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Sun, 19 Aug 2012 00:29:52 +0000 Subject: [issue15526] test_startfile crash on Windows 7 AMD64 In-Reply-To: <1345330417.43.0.750717613116.issue15526@psf.upfronthosting.co.za> Message-ID: Jeremy Kloth added the comment: Unfortunately, this is a legitimate failure of the test. The test (actually the support code) is attempting to remove a directory that is the current directory of an active process. The test has documented this issue and attempted to work around it by adding a sleep(). To fix this test there a few options: 1) increase the sleep timeout 2) change the current working directory before calling os.startfile() (possible that of the Python interpreter itself) 3) code a "wait for child process" function using ctypes and the Toolhelp API (Process32First/Next) 4) change os.startfile() to use ShellExecuteEx and use the hProcess handle as the return value and use that with os.waitpid() #4 is the most accurate, but does introduce an API change (the introduction of a return value to os.startfile) #3 is more work but may be helpful for other tests #2 will definitely work in this case but does violate the testing sandbox #1 is the least disruptive, but is really just avoiding the root cause I would like to see #4 but realize that it may be too late for 3.3. #3 is not bad either as it has impact only on the test suite. But any of the above should fix this particular case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 05:35:03 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Sun, 19 Aug 2012 03:35:03 +0000 Subject: [issue15719] Sort dict items in urlencode() In-Reply-To: <1345236293.12.0.120802358061.issue15719@psf.upfronthosting.co.za> Message-ID: <1345347303.25.0.0269274341346.issue15719@psf.upfronthosting.co.za> Gregory P. Smith added the comment: -1 on doing this from me. While I don't see it hurting anything when "type(query) is dict" I'd much rather encourage people to write better tests that do not take the lazy way out. Tests that get by comparing a generated string to a "golden" string are soo often wrong because the golden string is not what they actually wanted to test. Instead the author meant to test the meaning of the result rather than the specific incantation of it that they pasted in their code for an assertEqual check. (This does suggest that some additional unittest methods to make comparing common things like this in a safe manner would be useful to people. urls, html and xml with attributes, json, etc) Ex: We've run into many tests that were failing due to hash randomization because they compared json strings... rather than suggest that json.dumps sort dictionaries before generating output, having the tests use json.loads and compare the actual data structure rather than a golden value string is much better. If a change like this is made, it needs to be conditional in 2.7 and 3.2 to only sort when hash randomization is enabled to avoid altering the existing behavior of urlencode for the default PYTHONHASHSEED=0 case on 2.7 and 3.2. As far as this being an enhancement rather than a bugfix... I sort of agree that this is an enhancement. And if this is an enhancement, we don't need to do it at all: People will already have done the right thing making their code work with 3.3's hash randomization by default before long before 3.4 is out. ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 06:15:11 2012 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 19 Aug 2012 04:15:11 +0000 Subject: [issue15719] Sort dict items in urlencode() In-Reply-To: <1345236293.12.0.120802358061.issue15719@psf.upfronthosting.co.za> Message-ID: <1345349711.6.0.0634865001808.issue15719@psf.upfronthosting.co.za> Guido van Rossum added the comment: I've come to see more downsides than upsides to this idea. I'm withdrawing it. Good points, Greg! (And others.) ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 07:10:58 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 19 Aug 2012 05:10:58 +0000 Subject: [issue15285] test_timeout failure when system on IPv4 10.x.x.x subnet In-Reply-To: <1341678423.78.0.865179228191.issue15285@psf.upfronthosting.co.za> Message-ID: <1345353058.0.0.423735172154.issue15285@psf.upfronthosting.co.za> Ned Deily added the comment: The patch looks good to me. Thanks for setting up the infrastructure to allow reproducible testing! ---------- stage: needs patch -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 08:16:04 2012 From: report at bugs.python.org (Ben Darnell) Date: Sun, 19 Aug 2012 06:16:04 +0000 Subject: [issue8240] ssl.SSLSocket.write may fail on non-blocking sockets In-Reply-To: <1269617434.76.0.650979265578.issue8240@psf.upfronthosting.co.za> Message-ID: <1345356964.38.0.916175474896.issue8240@psf.upfronthosting.co.za> Ben Darnell added the comment: Related pypy issue: https://bugs.pypy.org/issue1238 ---------- nosy: +Ben.Darnell _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 09:23:12 2012 From: report at bugs.python.org (Mike Hoy) Date: Sun, 19 Aug 2012 07:23:12 +0000 Subject: [issue12436] Missing items in installation/setup instructions In-Reply-To: <1309305395.29.0.101516779086.issue12436@psf.upfronthosting.co.za> Message-ID: <1345360992.54.0.190185680653.issue12436@psf.upfronthosting.co.za> Mike Hoy added the comment: Here is a patch for just Notepad++. ---------- keywords: +patch Added file: http://bugs.python.org/file26891/issue12436-notepad_plus_plus.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 09:24:45 2012 From: report at bugs.python.org (Mike Hoy) Date: Sun, 19 Aug 2012 07:24:45 +0000 Subject: [issue15569] Doc doc: incorrect description of some roles as format-only In-Reply-To: <1344302647.18.0.307450045197.issue15569@psf.upfronthosting.co.za> Message-ID: <1345361085.45.0.524891520617.issue15569@psf.upfronthosting.co.za> Mike Hoy added the comment: I would like to submit a patch for this. Is anyone currently working on one? ---------- nosy: +mikehoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 09:26:12 2012 From: report at bugs.python.org (Mike Hoy) Date: Sun, 19 Aug 2012 07:26:12 +0000 Subject: [issue13341] Incorrect documentation for "u" PyArg_Parse format unit In-Reply-To: <1320412814.48.0.657162308895.issue13341@psf.upfronthosting.co.za> Message-ID: <1345361172.12.0.419572833624.issue13341@psf.upfronthosting.co.za> Changes by Mike Hoy : ---------- nosy: -mikehoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 09:45:08 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 19 Aug 2012 07:45:08 +0000 Subject: [issue15722] PEP 3121, 384 Refactoring applied to decimal module In-Reply-To: <1345329400.69.0.320813862108.issue15722@psf.upfronthosting.co.za> Message-ID: <20120819074505.GA20781@sleipnir.bytereef.org> Stefan Krah added the comment: The test suite is not a good benchmark: it also tests decimal.py. For numerical performance I'm running: cd Modules/_decimal/tests ../../../python bench.py You can hit Ctrl-C after the first cdecimal result, since that's usually already a pretty good indicator of overall performance. On 64-bit, for 9 digits of precision cdecimal is currently only around 1.5 times slower than float. I want to keep that. Running an unpatched _decimal.c three times gives (Linux, 64-bit, Core2 Duo): 0.162576s 0.165146s 0.163242s With your second patch: 0.204383s 0.204383s 0.206919s > Regarding the failing test: > It appears that the hackcheck() method in typeobject.c is responsible for this failure: Thanks for the analysis. Perhaps Martin can comment on that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 10:20:52 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 19 Aug 2012 08:20:52 +0000 Subject: [issue15722] PEP 3121, 384 Refactoring applied to decimal module In-Reply-To: <1345293070.72.0.383930872934.issue15722@psf.upfronthosting.co.za> Message-ID: <1345364452.42.0.0368206324844.issue15722@psf.upfronthosting.co.za> Martin v. L?wis added the comment: hackcheck fixes the "Carlo Verry hack", which goes like this: py> object.__setattr__(str, 'lower', str.upper) py> 'dammit Carlo!'.lower() 'DAMMIT CARLO!' (from http://bugs.jython.org/issue1058) It shouldn't be possible to monkey-patch a builtin type; I believe this is to prevent crashes when self has the incorrect layout. Other than that, I find that an arbitrary restriction, except that setattr/attribute assignment prevent an assignment from occurring, it shouldn't be possible to bypass this by calling __setattr__. So if the restriction could be lifted, it should be lifted in both cases. What specific decimal test is failing? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 11:40:17 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 19 Aug 2012 09:40:17 +0000 Subject: [issue15722] PEP 3121, 384 Refactoring applied to decimal module In-Reply-To: <1345364452.42.0.0368206324844.issue15722@psf.upfronthosting.co.za> Message-ID: <20120819094014.GA21864@sleipnir.bytereef.org> Stefan Krah added the comment: > What specific decimal test is failing? # Attributes cannot be deleted for attr in ['prec', 'Emax', 'Emin', 'rounding', 'capitals', 'clamp', 'flags', 'traps']: self.assertRaises(AttributeError, c.__delattr__, attr) test test_decimal failed -- Traceback (most recent call last): File "/home/stefan/pydev/pep-3121-cpython/Lib/test/test_decimal.py", line 3683, in test_invalid_context self.assertRaises(AttributeError, c.__delattr__, attr) File "/home/stefan/pydev/pep-3121-cpython/Lib/unittest/case.py", line 571, in assertRaises return context.handle('assertRaises', callableObj, args, kwargs) File "/home/stefan/pydev/pep-3121-cpython/Lib/unittest/case.py", line 135, in handle callable_obj(*args, **kwargs) TypeError: can't apply this __delattr__ to object object 1 test failed: test_decimal ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 12:31:58 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Sun, 19 Aug 2012 10:31:58 +0000 Subject: [issue15526] test_startfile crash on Windows 7 AMD64 In-Reply-To: <1343827804.07.0.425515249327.issue15526@psf.upfronthosting.co.za> Message-ID: <1345372318.98.0.514391418726.issue15526@psf.upfronthosting.co.za> Richard Oudkerk added the comment: I think the reason that it is only this buildbot which fails is that the other Windows buildbots don't use multiple processes. Therefore they don't use a different dir for each test. > 4) change os.startfile() to use ShellExecuteEx and use the hProcess > handle as the return value and use that with os.waitpid() Would this cause a handle leak if os.waitpid() is not used? ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 12:55:16 2012 From: report at bugs.python.org (Georg Brandl) Date: Sun, 19 Aug 2012 10:55:16 +0000 Subject: [issue15298] _sysconfigdata is generated in srcdir, not builddir In-Reply-To: <1341782776.55.0.708234468774.issue15298@psf.upfronthosting.co.za> Message-ID: <1345373716.14.0.480170514656.issue15298@psf.upfronthosting.co.za> Georg Brandl added the comment: It seems there is no urge to fix this before 3.3 -- fine with me. ---------- priority: deferred blocker -> critical _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 12:56:06 2012 From: report at bugs.python.org (Georg Brandl) Date: Sun, 19 Aug 2012 10:56:06 +0000 Subject: [issue15037] curses.unget_wch and test_curses fail when linked with ncurses 5.7 and earlier In-Reply-To: <1339171712.6.0.747270716657.issue15037@psf.upfronthosting.co.za> Message-ID: <1345373766.46.0.45291721809.issue15037@psf.upfronthosting.co.za> Georg Brandl added the comment: Anything left to do here? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 12:57:39 2012 From: report at bugs.python.org (Georg Brandl) Date: Sun, 19 Aug 2012 10:57:39 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <1345373859.37.0.255050289723.issue14814@psf.upfronthosting.co.za> Georg Brandl added the comment: Please keep in mind that this should be committed before next weekend if it is to make 3.3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 13:00:10 2012 From: report at bugs.python.org (Georg Brandl) Date: Sun, 19 Aug 2012 11:00:10 +0000 Subject: [issue12623] "universal newlines" subprocess support broken with select- and poll-based communicate() In-Reply-To: <1311451893.22.0.0169745025507.issue12623@psf.upfronthosting.co.za> Message-ID: <1345374010.49.0.707167118223.issue12623@psf.upfronthosting.co.za> Georg Brandl added the comment: > The main question: can be fix applied to 3.3 or it can wait for 3.4? > 3.2 has the same problem BTW. I don't see any fix attached :) If it is a bug, it can be fixed before 3.3rc1, no need for release blocker status. ---------- priority: release blocker -> critical _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 13:00:30 2012 From: report at bugs.python.org (Georg Brandl) Date: Sun, 19 Aug 2012 11:00:30 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1317341390.65.0.255779328054.issue13072@psf.upfronthosting.co.za> Message-ID: <1345374030.7.0.702871208594.issue13072@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- priority: deferred blocker -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 13:00:33 2012 From: report at bugs.python.org (Georg Brandl) Date: Sun, 19 Aug 2012 11:00:33 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1345374033.2.0.622916114375.issue15573@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- priority: deferred blocker -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 13:00:37 2012 From: report at bugs.python.org (Georg Brandl) Date: Sun, 19 Aug 2012 11:00:37 +0000 Subject: [issue15037] curses.unget_wch and test_curses fail when linked with ncurses 5.7 and earlier In-Reply-To: <1339171712.6.0.747270716657.issue15037@psf.upfronthosting.co.za> Message-ID: <1345374037.3.0.475667216951.issue15037@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- priority: deferred blocker -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 13:00:40 2012 From: report at bugs.python.org (Georg Brandl) Date: Sun, 19 Aug 2012 11:00:40 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <1345374040.59.0.986161772398.issue14814@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- priority: deferred blocker -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 13:26:34 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 19 Aug 2012 11:26:34 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1317341390.65.0.255779328054.issue13072@psf.upfronthosting.co.za> Message-ID: <1345375594.37.0.0220423388252.issue13072@psf.upfronthosting.co.za> Stefan Krah added the comment: If everyone agrees on deprecating 'u', here's a patch. I think that should be sufficient to close this issue (unless we absolutely need deprecation warnings). ---------- Added file: http://bugs.python.org/file26892/array_deprecate_u.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 13:30:22 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 19 Aug 2012 11:30:22 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1345375822.92.0.593902056919.issue15573@psf.upfronthosting.co.za> Stefan Krah added the comment: I think issue15573-struct-2.diff is ready to go and I'd rather commit sooner than later. Nick, can I interpret your last review comment as "go ahead"? :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 13:36:27 2012 From: report at bugs.python.org (Georg Brandl) Date: Sun, 19 Aug 2012 11:36:27 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1345376187.6.0.810447696055.issue15573@psf.upfronthosting.co.za> Georg Brandl added the comment: Small nit: when you put "versionchanged:: 3.3" there should be a hint of *what* changed exactly :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 13:49:08 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 19 Aug 2012 11:49:08 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1345375594.37.0.0220423388252.issue13072@psf.upfronthosting.co.za> Message-ID: <1345376741.3379.0.camel@localhost.localdomain> Antoine Pitrou added the comment: > If everyone agrees on deprecating 'u', here's a patch. I think > that should be sufficient to close this issue (unless we absolutely > need deprecation warnings). I think a proper deprecation warning is preferable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 13:53:20 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 19 Aug 2012 11:53:20 +0000 Subject: [issue15544] math.isnan fails with some Decimal NaNs In-Reply-To: <1343962443.78.0.878505736017.issue15544@psf.upfronthosting.co.za> Message-ID: <1345377200.51.0.382226533495.issue15544@psf.upfronthosting.co.za> Mark Dickinson added the comment: Here's an updated patch that extends Steven's fix to the C code. ---------- Added file: http://bugs.python.org/file26893/decimalnan_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 13:53:43 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 19 Aug 2012 11:53:43 +0000 Subject: [issue15724] Add "versionchanged" to memoryview docs Message-ID: <1345377223.09.0.176185074566.issue15724@psf.upfronthosting.co.za> New submission from Stefan Krah: There are a couple of places in the memoryview docs that still need a "versionchanged" tag. Other places might need explanations what exactly has changed. ---------- assignee: docs at python components: Documentation messages: 168563 nosy: docs at python, skrah priority: normal severity: normal stage: needs patch status: open title: Add "versionchanged" to memoryview docs type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 13:57:07 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 19 Aug 2012 11:57:07 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1345377427.51.0.437178139152.issue15573@psf.upfronthosting.co.za> Stefan Krah added the comment: Right. I'm tracking all "versionchanged" issues in #15724. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 14:07:16 2012 From: report at bugs.python.org (Eli Bendersky) Date: Sun, 19 Aug 2012 12:07:16 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <1345378036.76.0.992748418826.issue14814@psf.upfronthosting.co.za> Eli Bendersky added the comment: I'm just waiting for a review. If Nick has no time for that, perhaps I can commit anyway since this is just adding documentation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 14:50:38 2012 From: report at bugs.python.org (Kevin Chen) Date: Sun, 19 Aug 2012 12:50:38 +0000 Subject: [issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite In-Reply-To: <1242857063.47.0.919073638283.issue6074@psf.upfronthosting.co.za> Message-ID: <1345380638.34.0.173578427079.issue6074@psf.upfronthosting.co.za> Kevin Chen added the comment: I propose a fix: static FILE * open_exclusive(char *filename, mode_t mode) { #if defined(O_EXCL)&&defined(O_CREAT)&&defined(O_WRONLY)&&defined(O_TRUNC) /* Use O_EXCL to avoid a race condition when another process tries to write the same file. When that happens, our open() call fails, which is just fine (since it's only a cache). XXX If the file exists and is writable but the directory is not writable, the file will never be written. Oh well. */ int fd; (void) unlink(filename); fd = open(filename, O_EXCL|O_CREAT|O_WRONLY|O_TRUNC #ifdef O_BINARY |O_BINARY /* necessary for Windows */ #endif #ifdef __VMS , mode, "ctxt=bin", "shr=nil" #elif defined(MS_WINDOWS) , mode | _S_IWRITE #else , mode #endif ); if (fd < 0 ) return NULL; return fdopen(fd, "wb"); #else /* Best we can do -- on Windows this can't happen anyway */ return fopen(filename, "wb"); #endif } ---------------------- so doesn't matter what the .py file permission is under windows, the .pyc file will always have both read and write permissions. ---------- nosy: +lowlifer123 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 14:59:24 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 19 Aug 2012 12:59:24 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1345376741.3379.0.camel@localhost.localdomain> Message-ID: Nick Coghlan added the comment: I guess the analogy with bytes objects is that UCS-2 code points can be handled as 16-bit integer objects. If we're going to do a programmatic deprecation now, that's the only alternative typecode currently available. Do we want to recommend that? Or do we want to postpone programmatic deprecation until we add a 2-byte code point type code for 3.4? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 14:59:32 2012 From: report at bugs.python.org (Stephen Thorne) Date: Sun, 19 Aug 2012 12:59:32 +0000 Subject: [issue14905] zipimport.c needs to support namespace packages when no 'directory' entry exists In-Reply-To: <1337905627.12.0.841961188355.issue14905@psf.upfronthosting.co.za> Message-ID: <1345381172.0.0.806134155842.issue14905@psf.upfronthosting.co.za> Stephen Thorne added the comment: Please see attached new patch, based on review comments. ---------- Added file: http://bugs.python.org/file26894/zipimport-issue14905-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 15:01:34 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 19 Aug 2012 13:01:34 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1345378036.76.0.992748418826.issue14814@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: I'm at the pyconau sprints for the next couple of days - I'll make sure this is dealt with. On Aug 19, 2012 10:07 PM, "Eli Bendersky" wrote: > > Eli Bendersky added the comment: > > I'm just waiting for a review. If Nick has no time for that, perhaps I can > commit anyway since this is just adding documentation. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 15:12:47 2012 From: report at bugs.python.org (Robin Schreiber) Date: Sun, 19 Aug 2012 13:12:47 +0000 Subject: [issue15725] PyType_FromSpecWithBases bugfix Message-ID: <1345381967.41.0.932282182002.issue15725@psf.upfronthosting.co.za> New submission from Robin Schreiber: This small patch prevents PyType_FromSpecWithBases, from setting the base(s) attribute of the HeapType to NULL-values. ---------- components: Interpreter Core files: PyType_FromSpecWithBases_bases_fix.patch keywords: patch messages: 168570 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PyType_FromSpecWithBases bugfix type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file26895/PyType_FromSpecWithBases_bases_fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 15:14:18 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 19 Aug 2012 13:14:18 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: Message-ID: <1345381851.3379.3.camel@localhost.localdomain> Antoine Pitrou added the comment: > I guess the analogy with bytes objects is that UCS-2 code points can be > handled as 16-bit integer objects. > > If we're going to do a programmatic deprecation now, that's the only > alternative typecode currently available. Do we want to recommend that? Or > do we want to postpone programmatic deprecation until we add a 2-byte code > point type code for 3.4? I don't understand. If you want to handle 16-bit integers, you already have the "h" and "H" type codes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 15:17:12 2012 From: report at bugs.python.org (Robin Schreiber) Date: Sun, 19 Aug 2012 13:17:12 +0000 Subject: [issue15726] PyState_FindModule false length-comparison fix Message-ID: <1345382232.77.0.93004938409.issue15726@psf.upfronthosting.co.za> New submission from Robin Schreiber: Fixed wrong list-length comparison in PyState_FindModule. ---------- components: Interpreter Core files: PyState_FindModule_LE_fix.patch keywords: patch messages: 168572 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PyState_FindModule false length-comparison fix type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file26896/PyState_FindModule_LE_fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 15:17:38 2012 From: report at bugs.python.org (Robin Schreiber) Date: Sun, 19 Aug 2012 13:17:38 +0000 Subject: [issue15726] PyState_FindModule false length-comparison fix In-Reply-To: <1345382232.77.0.93004938409.issue15726@psf.upfronthosting.co.za> Message-ID: <1345382258.64.0.433189999405.issue15726@psf.upfronthosting.co.za> Changes by Robin Schreiber : ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 15:17:55 2012 From: report at bugs.python.org (Robin Schreiber) Date: Sun, 19 Aug 2012 13:17:55 +0000 Subject: [issue15725] PyType_FromSpecWithBases bugfix In-Reply-To: <1345381967.41.0.932282182002.issue15725@psf.upfronthosting.co.za> Message-ID: <1345382275.56.0.117021010247.issue15725@psf.upfronthosting.co.za> Changes by Robin Schreiber : ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 15:29:48 2012 From: report at bugs.python.org (Kevin Chen) Date: Sun, 19 Aug 2012 13:29:48 +0000 Subject: [issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite In-Reply-To: <1242857063.47.0.919073638283.issue6074@psf.upfronthosting.co.za> Message-ID: <1345382988.3.0.246677812276.issue6074@psf.upfronthosting.co.za> Kevin Chen added the comment: This is essentially the way things were done in version 2.5.4 of Python. The unlink() always succeeded, because the created .pyc file permission is always set to 0666 in the fd=open() function. This means the .pyc will never be created as read-only, and as long as they are never set to read-only manually by the user, everything will be okay. You might say this will be a problem if someone accidentally set the it to read-only. Well we have been using Python 2.5 for many years, and we have managed quite well, so it is not really going to be a big issue, and can be fixed in the future. Whereas at the moment we have a PROBLEM!! With the current state of the Python 2.6, 2.7 and 3.2 interpreters, many Windows users cannot even think about upgrade from Python 2.5 because source control tools like Perforce will set all .py files to read-only, and so ALL created .pyc files will become read-only every time you run Python. I cannot stress how much pain this causes. PLEASE MAKE IT 2.5 EQUIVALENT ASAP! THANK YOU!! even just this will do the trick: ------------------------------------- fd = open(filename, O_EXCL|O_CREAT|O_WRONLY|O_TRUNC #ifdef O_BINARY |O_BINARY /* necessary for Windows */ #endif #ifdef __VMS , mode, "ctxt=bin", "shr=nil" #elif defined(MS_WINDOWS) , 0666 #else , mode #endif ); ----------------------------------- And a side note, for the VC8 build for PC, the file random.c was left out from the visual studio project file for pythoncore project. It gives these errors when I try recompile: Error 2 error LNK2019: unresolved external symbol __PyRandom_Init referenced in function _Py_Main main.obj Error 3 error LNK2001: unresolved external symbol __PyRandom_Init pythonrun.obj Error 4 error LNK2019: unresolved external symbol __PyOS_URandom referenced in function _posix_urandom posixmodule.obj This is my first time using bug tracker, so please point me to the appropriate place to put this. Thank you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 15:37:42 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 19 Aug 2012 13:37:42 +0000 Subject: [issue15544] math.isnan fails with some Decimal NaNs In-Reply-To: <1345377200.51.0.382226533495.issue15544@psf.upfronthosting.co.za> Message-ID: <20120819133742.GA26613@sleipnir.bytereef.org> Stefan Krah added the comment: The patch looks good in every detail. +1 for committing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 16:07:39 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 19 Aug 2012 14:07:39 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1317341390.65.0.255779328054.issue13072@psf.upfronthosting.co.za> Message-ID: <1345385259.55.0.760172567528.issue13072@psf.upfronthosting.co.za> Stefan Krah added the comment: Since actual removal is only scheduled for 4.0, I think user warnings can wait until 3.4. By then, we should have sorted out the struct format codes. In this scenario we would be sort of forced to use 'C', 'U' and 'W' as the new codes, while 'u' and 'w' would continue to linger in the array module for a while. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 16:32:47 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Sun, 19 Aug 2012 14:32:47 +0000 Subject: [issue15526] test_startfile crash on Windows 7 AMD64 In-Reply-To: <1345372318.98.0.514391418726.issue15526@psf.upfronthosting.co.za> Message-ID: Jeremy Kloth added the comment: > I think the reason that it is only this buildbot which fails is that the other Windows buildbots don't use multiple processes. Therefore they don't use a different dir for each test. That might be it. Also the failure possibly only happens when multiple builds are being run thus slowing down process creation and termination. > Would this cause a handle leak if os.waitpid() is not used? It seems so, yes. So to expand on #4: 4a) create a new handle type that closes the handles on dealloc 4b) return the process ID instead using GetProcessId() and callers interested in waiting would then need to use _winapi.OpenProcess() to convert it to a handle for os.waitpid() or _winapi.WaitForSingleObject() 4c) add a third optional argument to os.startfile() "mode" that mimics the mode semantics of the os.spawn*() functions ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 16:43:45 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 19 Aug 2012 14:43:45 +0000 Subject: [issue15526] test_startfile crash on Windows 7 AMD64 In-Reply-To: <1343827804.07.0.425515249327.issue15526@psf.upfronthosting.co.za> Message-ID: <1345387425.52.0.107525352586.issue15526@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I think the two "simple and stupid" solutions (#1 and #2) have a certain charm myself :) Especially #1, which is the simplest of all. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 17:26:22 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Sun, 19 Aug 2012 15:26:22 +0000 Subject: [issue15526] test_startfile crash on Windows 7 AMD64 In-Reply-To: <1345387425.52.0.107525352586.issue15526@psf.upfronthosting.co.za> Message-ID: Jeremy Kloth added the comment: However #1 is the reason that is bug exists in the first place. The designer of the test guessed wrong on the "magic value" for the timeout. There will never be a correct timeout value as it varies from machine to machine and from workload to workload on a given machine. For any value that is picked, there exists a scenario where it will fail. #2 is certainly a viable work-around and it appears that other tests (notably the test for fork/exec) do similar so it wouldn't be unprecedented #3 is really only useful if other tests need a "wait for process" helper on Windows. #4 really just highlights a deficiency with os.startfile() so I'm fine with deferring that to a feature request for 3.4. I'll cook up a patch implementing #2 unless anyone else is feeling ambitious. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 17:57:46 2012 From: report at bugs.python.org (Robin Schreiber) Date: Sun, 19 Aug 2012 15:57:46 +0000 Subject: [issue15727] PyType_FromSpecWithBases tp_new bugfix Message-ID: <1345391866.4.0.54341725267.issue15727@psf.upfronthosting.co.za> New submission from Robin Schreiber: As with every type, that has been created and initialized, HeapTypes created form PyType_FromSpecWithBases() have to pass through PyType_Ready(). Here the function inherit_special might be called, which, among other things, does the following: .... 3892 if (base != &PyBaseObject_Type || 3893 (type->tp_flags & Py_TPFLAGS_HEAPTYPE)) { 3894 if (type->tp_new == NULL) 3895 type->tp_new = base->tp_new; 3896 } .... The code does not know of Heaptypes that have been created from extension-types by the PEP 384 refactorings. This includes extension-types that do not specify a tp_new method but instead have seperate factory methods, that are only used within the extension module. inherit_special() might consequently assign inappropriate new-methods to these type objects. To circumvent this issue, I propose to enhance PyType_FromSpecWithBases in the following way: If no tp_new has been specified, we assign the newly defined PySpec_New() method to tp_new which simply denies the user to create an instance of this type. This also prohibits inherit_special to falsely inherit inappropriate new-methods. ---------- components: Interpreter Core files: PyType_FromSpecWithBases_tp_new_fix.patch keywords: patch messages: 168579 nosy: Robin.Schreiber, loewis priority: normal severity: normal status: open title: PyType_FromSpecWithBases tp_new bugfix type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file26897/PyType_FromSpecWithBases_tp_new_fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 18:14:08 2012 From: report at bugs.python.org (Brian Curtin) Date: Sun, 19 Aug 2012 16:14:08 +0000 Subject: [issue15131] Document py/pyw launchers In-Reply-To: <1340316982.35.0.0939341708.issue15131@psf.upfronthosting.co.za> Message-ID: <1345392848.43.0.548437514396.issue15131@psf.upfronthosting.co.za> Brian Curtin added the comment: This was added by Vinay in 4a3439ef552c. ---------- resolution: -> invalid stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 18:18:56 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 19 Aug 2012 16:18:56 +0000 Subject: [issue15642] Integrate pickle protocol version 4 GSoC work by Stefan Mihaila In-Reply-To: <1344890920.23.0.695633734046.issue15642@psf.upfronthosting.co.za> Message-ID: <1345393136.6.0.946167435119.issue15642@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Is this patch stable? Or are there further changes coming? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 18:21:07 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 19 Aug 2012 16:21:07 +0000 Subject: [issue15726] PyState_FindModule false length-comparison fix In-Reply-To: <1345382232.77.0.93004938409.issue15726@psf.upfronthosting.co.za> Message-ID: <1345393267.61.0.239971831627.issue15726@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Looks good to me, thank you. ---------- nosy: +pitrou stage: -> patch review versions: +Python 3.2, Python 3.3 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 18:22:33 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 19 Aug 2012 16:22:33 +0000 Subject: [issue14668] Document the path option in the Windows installer In-Reply-To: <1335360311.11.0.51507359107.issue14668@psf.upfronthosting.co.za> Message-ID: <3X0Nj05KW9zQX1@mail.python.org> Roundup Robot added the comment: New changeset b07a408b0291 by Brian Curtin in branch 'default': Fixes #14668. Mention Windows Path manipulation option in the installer. http://hg.python.org/cpython/rev/b07a408b0291 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 19:50:05 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 19 Aug 2012 17:50:05 +0000 Subject: [issue15728] Leak in PyUnicode_AsWideCharString() Message-ID: <1345398605.54.0.540570089061.issue15728@psf.upfronthosting.co.za> New submission from Stefan Krah: Coverity found a leak in PyUnicode_AsWideCharString(). Patch attached. ---------- components: Interpreter Core files: aswidechar-leak.diff keywords: patch messages: 168584 nosy: haypo, skrah priority: normal severity: normal stage: patch review status: open title: Leak in PyUnicode_AsWideCharString() type: resource usage versions: Python 3.3 Added file: http://bugs.python.org/file26898/aswidechar-leak.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 20:27:57 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 19 Aug 2012 18:27:57 +0000 Subject: [issue15595] subprocess.Popen(universal_newlines=True) does not work for certain locales In-Reply-To: <1344461775.23.0.274836365722.issue15595@psf.upfronthosting.co.za> Message-ID: <1345400877.09.0.635226552795.issue15595@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Looks good for me, but please use assertEqual instead assertEquals. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 20:42:51 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 19 Aug 2012 18:42:51 +0000 Subject: [issue15037] curses.unget_wch and test_curses fail when linked with ncurses 5.7 and earlier In-Reply-To: <1339171712.6.0.747270716657.issue15037@psf.upfronthosting.co.za> Message-ID: <1345401771.83.0.0593958064404.issue15037@psf.upfronthosting.co.za> Ned Deily added the comment: To be clear, I've eliminated the problem for the OS X installer builds by supplying newer versions of libncursesw so I wasn't planning on doing anything more on this issue myself. It should be easy enough to reproduce on most platforms by installing ncursesw 5.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 20:49:01 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 19 Aug 2012 18:49:01 +0000 Subject: [issue15595] subprocess.Popen(universal_newlines=True) does not work for certain locales In-Reply-To: <1344461775.23.0.274836365722.issue15595@psf.upfronthosting.co.za> Message-ID: <1345402141.32.0.800416918252.issue15595@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Thank you, Andrew. Here is a patch updated with that change (and also merging with tip). ---------- Added file: http://bugs.python.org/file26899/issue-15595-4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 21:20:38 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 19 Aug 2012 19:20:38 +0000 Subject: [issue15595] subprocess.Popen(universal_newlines=True) does not work for certain locales In-Reply-To: <1344461775.23.0.274836365722.issue15595@psf.upfronthosting.co.za> Message-ID: <3X0Sf73Z5xzQ2q@mail.python.org> Roundup Robot added the comment: New changeset a0f7c2f79bce by Andrew Svetlov in branch '3.2': Issue #15595: Fix subprocess.Popen(universal_newlines=True) http://hg.python.org/cpython/rev/a0f7c2f79bce New changeset aceb820154c3 by Andrew Svetlov in branch 'default': Issue #15595: Fix subprocess.Popen(universal_newlines=True) http://hg.python.org/cpython/rev/aceb820154c3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 21:23:06 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 19 Aug 2012 19:23:06 +0000 Subject: [issue15595] subprocess.Popen(universal_newlines=True) does not work for certain locales In-Reply-To: <1344461775.23.0.274836365722.issue15595@psf.upfronthosting.co.za> Message-ID: <1345404186.68.0.0671610174147.issue15595@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Fixed. Thank you. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 21:25:42 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 19 Aug 2012 19:25:42 +0000 Subject: [issue10951] gcc 4.6 warnings In-Reply-To: <1295474318.57.0.129834114348.issue10951@psf.upfronthosting.co.za> Message-ID: <1345404342.61.0.60553703235.issue10951@psf.upfronthosting.co.za> Martin v. L?wis added the comment: (As usual), I'm quite skeptical about this "bulk bug report"; it violates the "one bug at a time" principle, where "one bug" can roughly be defined as "cannot be split into smaller independent issues". For the cases at hand, I think it would be best if somebody with gcc 4.6 available just fixed the "easy" ones, i.e. where the code clearly improves when silenciing the warning. In these cases, I wouldn't mind if they get checked in without code review; I know some favor review for all changes, in which case a separate issue should be opened for a patch fixing a bunch of these. The more difficult ones may deserve their own issues (e.g. when it is debatable whether gcc is right to warn about the code) ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 21:28:23 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 19 Aug 2012 19:28:23 +0000 Subject: [issue15728] Leak in PyUnicode_AsWideCharString() In-Reply-To: <1345398605.54.0.540570089061.issue15728@psf.upfronthosting.co.za> Message-ID: <1345404502.99.0.721239901676.issue15728@psf.upfronthosting.co.za> Martin v. L?wis added the comment: LGTM. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 21:38:44 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Sun, 19 Aug 2012 19:38:44 +0000 Subject: [issue15528] Better support for finalization with weakrefs In-Reply-To: <1343837927.06.0.561023898829.issue15528@psf.upfronthosting.co.za> Message-ID: <1345405124.56.0.386059082768.issue15528@psf.upfronthosting.co.za> Richard Oudkerk added the comment: New patch. ---------- Added file: http://bugs.python.org/file26900/finalize.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 21:57:58 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 19 Aug 2012 19:57:58 +0000 Subject: [issue15728] Leak in PyUnicode_AsWideCharString() In-Reply-To: <1345404502.99.0.721239901676.issue15728@psf.upfronthosting.co.za> Message-ID: <20120819195738.GA30665@sleipnir.bytereef.org> Stefan Krah added the comment: Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 21:58:54 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 19 Aug 2012 19:58:54 +0000 Subject: [issue15728] Leak in PyUnicode_AsWideCharString() In-Reply-To: <1345398605.54.0.540570089061.issue15728@psf.upfronthosting.co.za> Message-ID: <3X0TVK1t7JzQLB@mail.python.org> Roundup Robot added the comment: New changeset 2703171ddf53 by Stefan Krah in branch 'default': Issue #15728: Fix leak in PyUnicode_AsWideCharString(). Found by Coverity. http://hg.python.org/cpython/rev/2703171ddf53 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 21:59:45 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 19 Aug 2012 19:59:45 +0000 Subject: [issue15728] Leak in PyUnicode_AsWideCharString() In-Reply-To: <1345398605.54.0.540570089061.issue15728@psf.upfronthosting.co.za> Message-ID: <1345406385.35.0.898873596245.issue15728@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 22:16:18 2012 From: report at bugs.python.org (Robin Schreiber) Date: Sun, 19 Aug 2012 20:16:18 +0000 Subject: [issue15729] PyStructSequence_NewType enhancement Message-ID: <1345407378.13.0.964225258094.issue15729@psf.upfronthosting.co.za> New submission from Robin Schreiber: To create a HeapType from Structseq description, there is the helpful, yet undocumented PyStructSequence_NewType Method, which can do just that. Until now, this method solely allocates some generic TypeObject on which it then performs PyStructSequence_InitType(). I have found that this is far from enough, as for one the flags of the type are not set appropriately and neither ht_name nor ht_qualname are set (which is as far as I know required of a proper Heaptype). I have now added this missing initialization of the fields to PyStructSequence_NewType(). I have also changed the previous definition of PyStructSequence_InitType, by extracting a new Method _PyStructSequence_InitTypeWithFlags. This initializes the given type with the flags variable passed to the function. This method extraction is needed, as we can not alter the semantics of InitType itself, yet need some way to initialize a SequenceType with Heaptype-flags, without having too much duplicate code. ---------- components: Interpreter Core files: structseq_newtype_fix.patch keywords: patch messages: 168595 nosy: Robin.Schreiber, loewis priority: normal severity: normal status: open title: PyStructSequence_NewType enhancement type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file26901/structseq_newtype_fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 23:05:02 2012 From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=) Date: Sun, 19 Aug 2012 21:05:02 +0000 Subject: [issue5765] stack overflow evaluating eval("()" * 30000) In-Reply-To: <1239838657.22.0.326859227165.issue5765@psf.upfronthosting.co.za> Message-ID: <1345410302.89.0.0846193581647.issue5765@psf.upfronthosting.co.za> Francisco Mart?n Brugu? added the comment: Just curiosity: how relate the magic numbers 100000 and 2000 in test_compiler_recursion_limit to recursion_depth and recursion_limit Thanks! ---------- nosy: +francismb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 19 23:59:15 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 19 Aug 2012 21:59:15 +0000 Subject: [issue13579] string.Formatter doesn't understand the a conversion specifier In-Reply-To: <1323587450.48.0.625379374057.issue13579@psf.upfronthosting.co.za> Message-ID: <3X0X9R6Cm4zQMb@mail.python.org> Roundup Robot added the comment: New changeset 24b449a77e88 by R David Murray in branch '3.2': #13579: teach string.Formatter about 'a'. http://hg.python.org/cpython/rev/24b449a77e88 New changeset 4feb10457c13 by R David Murray in branch 'default': Merge #13579: teach string.Formatter about 'a'. http://hg.python.org/cpython/rev/4feb10457c13 New changeset c793d62cdecc by R David Murray in branch '2.7': #13579: minimize code base drift for 'a' string.Formatter change. http://hg.python.org/cpython/rev/c793d62cdecc ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 00:01:23 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 19 Aug 2012 22:01:23 +0000 Subject: [issue13579] string.Formatter doesn't understand the a conversion specifier In-Reply-To: <1323587450.48.0.625379374057.issue13579@psf.upfronthosting.co.za> Message-ID: <1345413683.69.0.257580444575.issue13579@psf.upfronthosting.co.za> R. David Murray added the comment: I've reviewed the patch and applied it. 2.7 doesn't support !a or 'ascii()', but I did backport the doc changes and the reordering of the clauses in order to minimize code base drift. Thanks, Francisco. ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 00:23:09 2012 From: report at bugs.python.org (Stefan Mihaila) Date: Sun, 19 Aug 2012 22:23:09 +0000 Subject: [issue15642] Integrate pickle protocol version 4 GSoC work by Stefan Mihaila In-Reply-To: <1344890920.23.0.695633734046.issue15642@psf.upfronthosting.co.za> Message-ID: <1345414989.6.0.829618015025.issue15642@psf.upfronthosting.co.za> Stefan Mihaila added the comment: There are still some upcoming changes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 00:27:29 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 19 Aug 2012 22:27:29 +0000 Subject: [issue5765] stack overflow evaluating eval("()" * 30000) In-Reply-To: <1239838657.22.0.326859227165.issue5765@psf.upfronthosting.co.za> Message-ID: <1345415249.27.0.860593206687.issue5765@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Indeed I don't like the introduction of COMPILER_STACK_FRAME_SCALE. Re-using the existing infrastructure would be much easier to maintain. The default recursion limit is 1000, which should cover any non-pathological code, IMHO. ---------- nosy: +pitrou stage: -> patch review versions: -Python 2.6, Python 3.1, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 00:33:25 2012 From: report at bugs.python.org (Mike Hoy) Date: Sun, 19 Aug 2012 22:33:25 +0000 Subject: [issue12436] Missing items in installation/setup instructions In-Reply-To: <1309305395.29.0.101516779086.issue12436@psf.upfronthosting.co.za> Message-ID: <1345415605.94.0.899960744807.issue12436@psf.upfronthosting.co.za> Changes by Mike Hoy : Added file: http://bugs.python.org/file26902/issue12436-notepad_plus_plus_2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 00:35:31 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sun, 19 Aug 2012 22:35:31 +0000 Subject: [issue5765] stack overflow evaluating eval("()" * 30000) In-Reply-To: <1239838657.22.0.326859227165.issue5765@psf.upfronthosting.co.za> Message-ID: <1345415731.1.0.965989337497.issue5765@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: The patch is incomplete: the VISIT macro contains a "return 0;" and in this case st->recursion_depth is not decremented. OTOH errors are never caught, so it's not necessary to do any cleanup in case of errors. Here is a simplified patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 00:35:55 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sun, 19 Aug 2012 22:35:55 +0000 Subject: [issue5765] stack overflow evaluating eval("()" * 30000) In-Reply-To: <1239838657.22.0.326859227165.issue5765@psf.upfronthosting.co.za> Message-ID: <1345415755.02.0.793265704798.issue5765@psf.upfronthosting.co.za> Changes by Amaury Forgeot d'Arc : Added file: http://bugs.python.org/file26903/compiler_recursion_limit_check-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 00:41:49 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 19 Aug 2012 22:41:49 +0000 Subject: [issue15574] IDLE crashes using clipboard copy command on OS X with ActiveTcl 8.5.12 In-Reply-To: <1344358098.04.0.570334143116.issue15574@psf.upfronthosting.co.za> Message-ID: <1345416109.51.0.72898768484.issue15574@psf.upfronthosting.co.za> Ned Deily added the comment: An update: ActiveState has released a Tcl/Tk 8.5.12.1 for OS X and, while it fixes a similar crash-on-copy from within the Wish shell, it doesn't fix the crash-on-copy from within tkinter and IDLE. Plus, I notice now there's also another regression in 8.5.12.x, a crash when opening IDLE preferences. Since ActiveTcl only makes available the most recent build in their Community Edition, I would recommend not updating and holding on to 8.5.11.1 until this is resolved. I'm now able to build Tcl/Tk to reproduce. I'll see if I can bisect it. ---------- resolution: out of date -> status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 00:53:28 2012 From: report at bugs.python.org (Mike Hoy) Date: Sun, 19 Aug 2012 22:53:28 +0000 Subject: [issue12436] Missing items in installation/setup instructions In-Reply-To: <1309305395.29.0.101516779086.issue12436@psf.upfronthosting.co.za> Message-ID: <1345416808.42.0.052644215416.issue12436@psf.upfronthosting.co.za> Mike Hoy added the comment: Wrapped my text columns to 80. Ignore v2. ---------- Added file: http://bugs.python.org/file26904/issue12436-notepad_plus_plus_3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 00:53:45 2012 From: report at bugs.python.org (Mahmood Hikmet) Date: Sun, 19 Aug 2012 22:53:45 +0000 Subject: [issue11631] Python 2.7.1 64bit, Win7 64bit problem to read and write with UDP. In-Reply-To: <1300786239.46.0.274643383137.issue11631@psf.upfronthosting.co.za> Message-ID: <1345416825.74.0.621314580126.issue11631@psf.upfronthosting.co.za> Mahmood Hikmet added the comment: I am facing this same issue. I set recvfrom to have a timeout of 5 seconds and stuck it in an infinite loop with some response code based on what is received. The sending functionality of the socket is not compromised at all. It can always send. However, after about 10-20 minutes of normal operation (i.e. packets are being sent and received properly) - python stops being able to receive packets (but is still able to send them). Cross-checking this with wireshark showed me that incoming packets are being received by the system (so the problem is somewhere between receiving them on the network adapter and accessing it in python). I'm running 64bit Windows 7 with 2 network adapters (wired and wireless). I also tried running the same python script in 4-200 processes simultaneously (but on different ports), and the error happens at the same time for ALL windows. All firewalls are disabled. ---------- nosy: +sadmoody _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 01:23:48 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 19 Aug 2012 23:23:48 +0000 Subject: [issue11631] Python 2.7.1 64bit, Win7 64bit problem to read and write with UDP. In-Reply-To: <1300786239.46.0.274643383137.issue11631@psf.upfronthosting.co.za> Message-ID: <1345418628.21.0.881727680223.issue11631@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > I set recvfrom to have a timeout of 5 seconds and stuck it in an > infinite loop with some response code based on what is received. Does it make a difference if you set specify a timeout? Could you upload a script that reproduces the issue? Also, which Python version have you been running? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 01:26:00 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 19 Aug 2012 23:26:00 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <1345418760.39.0.603791324533.issue14814@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- assignee: -> ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 01:46:03 2012 From: report at bugs.python.org (Mahmood Hikmet) Date: Sun, 19 Aug 2012 23:46:03 +0000 Subject: [issue11631] Python 2.7.1 64bit, Win7 64bit problem to read and write with UDP. In-Reply-To: <1300786239.46.0.274643383137.issue11631@psf.upfronthosting.co.za> Message-ID: <1345419963.13.0.651658685073.issue11631@psf.upfronthosting.co.za> Mahmood Hikmet added the comment: I'm unsure what you mean by "set specify" a timeout, but I do use the "settimeout()" function. I've stripped my program of everything that is not dealing with the socket and replaced the string being sent back with a dummy one. But this is essentially how it's laid out. I'm using Python 2.7.2 ---------- Added file: http://bugs.python.org/file26905/recvfrom_fail.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 01:49:23 2012 From: report at bugs.python.org (Kevin Chen) Date: Sun, 19 Aug 2012 23:49:23 +0000 Subject: [issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite In-Reply-To: <1242857063.47.0.919073638283.issue6074@psf.upfronthosting.co.za> Message-ID: <1345420163.76.0.318328315941.issue6074@psf.upfronthosting.co.za> Changes by Kevin Chen : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 02:05:05 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 Aug 2012 00:05:05 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <3X0ZyM3xX6zPx2@mail.python.org> Roundup Robot added the comment: New changeset 258558e36d8a by Nick Coghlan in branch 'default': Issue #14814: document the Interface APIs and fix various problems with the string representations (initial patch by Eli Bendersky). http://hg.python.org/cpython/rev/258558e36d8a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 02:19:58 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 Aug 2012 00:19:58 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <3X0bHT1gFczQSc@mail.python.org> Roundup Robot added the comment: New changeset 811d91591f73 by Nick Coghlan in branch 'default': Close #14814: Avoid depending on struct by using newer features. Also use enumerate where appropriate (patch by Serhiy Storchaka). Declaring PEP 3144 final at this point - any further changes to code or docs can go in new issues. http://hg.python.org/cpython/rev/811d91591f73 ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 02:46:33 2012 From: report at bugs.python.org (Benno Rice) Date: Mon, 20 Aug 2012 00:46:33 +0000 Subject: [issue15730] Silence unused value warnings under Mac OS X 10.8/clang Message-ID: <1345423593.46.0.41871412241.issue15730@psf.upfronthosting.co.za> New submission from Benno Rice: This patch silences a bunch of unused value warnings emitted by clang when building on Mac OS X 10.8. ---------- assignee: ronaldoussoren components: Interpreter Core, Macintosh files: warning-silencing.patch keywords: patch messages: 168609 nosy: Benno.Rice, ronaldoussoren priority: normal severity: normal status: open title: Silence unused value warnings under Mac OS X 10.8/clang type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file26906/warning-silencing.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 03:26:19 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 20 Aug 2012 01:26:19 +0000 Subject: [issue2051] PYO file permission problem In-Reply-To: <1202498912.62.0.957005802385.issue2051@psf.upfronthosting.co.za> Message-ID: <1345425979.46.0.315583960247.issue2051@psf.upfronthosting.co.za> Nick Coghlan added the comment: Since there was no regression test added for this, it appears to me that it is broken again now that we're using importlib. It may be rather hard to fix given the limitations of the set_data API :( ---------- assignee: facundobatista -> nosy: +brett.cannon, georg.brandl, ncoghlan priority: high -> release blocker resolution: accepted -> status: closed -> open versions: +Python 3.3 -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 03:27:54 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 20 Aug 2012 01:27:54 +0000 Subject: [issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite In-Reply-To: <1242857063.47.0.919073638283.issue6074@psf.upfronthosting.co.za> Message-ID: <1345426074.69.0.0641241458573.issue6074@psf.upfronthosting.co.za> Nick Coghlan added the comment: OK, I tracked down the original reason for the behavioural change: #2051 The important aspect in that patch is preserving the *read* permissions from the .py file so we don't accidentally expose data to other users. Kevin's patch seems like a good approach for restoring compatibility in 2.7 and 3.2 In 3.3, it appears that #2051 has regressed, since no test was added to confirm the correct behaviour and importlib appears to behave more like 2.5. ---------- versions: -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 03:27:58 2012 From: report at bugs.python.org (Benno Rice) Date: Mon, 20 Aug 2012 01:27:58 +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: <1345426078.99.0.646941263367.issue7665@psf.upfronthosting.co.za> Benno Rice added the comment: This patch fixes the urllib2 test. I wasn't able to replicate the ntpath test failure. This patch needs testing on Windows to make sure I haven't broken anything. ---------- keywords: +patch nosy: +Benno.Rice Added file: http://bugs.python.org/file26907/urllib2-conditionalise-path-hacking.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 03:37:17 2012 From: report at bugs.python.org (Ned Deily) Date: Mon, 20 Aug 2012 01:37:17 +0000 Subject: [issue15730] Silence unused value warnings under Mac OS X 10.8/clang In-Reply-To: <1345423593.46.0.41871412241.issue15730@psf.upfronthosting.co.za> Message-ID: <1345426637.92.0.283717999152.issue15730@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +ned.deily stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 03:40:05 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 20 Aug 2012 01:40:05 +0000 Subject: [issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite In-Reply-To: <1242857063.47.0.919073638283.issue6074@psf.upfronthosting.co.za> Message-ID: <1345426805.57.0.309540757037.issue6074@psf.upfronthosting.co.za> Nick Coghlan added the comment: (Note: Kevin is looking into this at the PyConAU sprints) New test case needed (probably in Lib/test/test_import.py): - create .py file as 0400 - import it - check .pyc (or .pyo) file is 0600 That ensures the #2501 security bug remains fixed, while also addressing this problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 04:47:33 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 20 Aug 2012 02:47:33 +0000 Subject: [issue2051] PYO file permission problem In-Reply-To: <1345425979.46.0.315583960247.issue2051@psf.upfronthosting.co.za> Message-ID: Brett Cannon added the comment: On Aug 19, 2012 9:26 PM, "Nick Coghlan" wrote: > > > Nick Coghlan added the comment: > > Since there was no regression test added for this, it appears to me that it is broken again now that we're using importlib. > > It may be rather hard to fix given the limitations of the set_data API :( >From an API perspective it's tough, but realistically it should be possible since the loaders have the path to the file that triggered the find as the 'path' attribute. > > ---------- > assignee: facundobatista -> > nosy: +brett.cannon, georg.brandl, ncoghlan > priority: high -> release blocker > resolution: accepted -> > status: closed -> open > versions: +Python 3.3 -Python 2.6 > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 05:15:29 2012 From: report at bugs.python.org (Ben Finney) Date: Mon, 20 Aug 2012 03:15:29 +0000 Subject: [issue8810] TZ offset description is unclear in docs In-Reply-To: <1274718021.16.0.883294684947.issue8810@psf.upfronthosting.co.za> Message-ID: <1345432529.08.0.333471200277.issue8810@psf.upfronthosting.co.za> Ben Finney added the comment: Here is an updated patch. I examined the implementation in the code for UTC offset and DST handling, and updated the code comments, the docstrings, and the library documentation. ---------- keywords: +patch nosy: +bignose, ncoghlan Added file: http://bugs.python.org/file26908/issue8810_reconcile_docs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 05:19:00 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 Aug 2012 03:19:00 +0000 Subject: [issue14846] Change in error when sys.path contains a nonexistent folder (importlib) In-Reply-To: <1337297708.76.0.21488172689.issue14846@psf.upfronthosting.co.za> Message-ID: <3X0gG460hkzQNT@mail.python.org> Roundup Robot added the comment: New changeset bfd04bfb55c5 by Nick Coghlan in branch 'default': Close #14846: Handle a sys.path entry going away http://hg.python.org/cpython/rev/bfd04bfb55c5 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 05:20:41 2012 From: report at bugs.python.org (Russell Sim) Date: Mon, 20 Aug 2012 03:20:41 +0000 Subject: [issue13299] namedtuple row factory for sqlite3 In-Reply-To: <1320021145.59.0.53370875256.issue13299@psf.upfronthosting.co.za> Message-ID: <1345432841.58.0.646224756114.issue13299@psf.upfronthosting.co.za> Russell Sim added the comment: Hi, Here is an implementation using lru_cache to prevent regeneration of the named tuple each time. Cheers, Russell ---------- keywords: +patch nosy: +Russell.Sim Added file: http://bugs.python.org/file26909/issue_13299.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 05:57:25 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 20 Aug 2012 03:57:25 +0000 Subject: [issue5808] Subprocess.getstatusoutput Fails Executing 'dir' Command on Windows In-Reply-To: <1240328974.09.0.446818382044.issue5808@psf.upfronthosting.co.za> Message-ID: <1345435045.88.0.300347974314.issue5808@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- superseder: -> subprocess.getoutput fails on win32 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 06:37:32 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 20 Aug 2012 04:37:32 +0000 Subject: [issue15731] Mechanism for inheriting docstrings and signatures Message-ID: <1345437452.28.0.514901819881.issue15731@psf.upfronthosting.co.za> New submission from Nick Coghlan: While working on #8810, I was reminded of the problem of wanting to inherit docstrings while replacing a method implementation. The abstract base class method docstrings for tzinfo.utcoffset and tzinfo.dst are also correct for the concrete subclasses in the pure Python and the C versions. However, the docstrings currently need to be duplicated in all 3 places manually. functools.wraps already plays in this space, but arguably asserts *too much* about the relationship between components A couple of descriptors on bound and unbound methods (for __doc__ and __signature__) could have dealt with this fairly easily, but we don't have unbound methods any more :( ---------- components: Library (Lib) messages: 168618 nosy: eric.snow, ncoghlan priority: normal severity: normal status: open title: Mechanism for inheriting docstrings and signatures type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 06:41:01 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 20 Aug 2012 04:41:01 +0000 Subject: [issue15731] Mechanism for inheriting docstrings and signatures In-Reply-To: <1345437452.28.0.514901819881.issue15731@psf.upfronthosting.co.za> Message-ID: <1345437661.89.0.159839219869.issue15731@psf.upfronthosting.co.za> Nick Coghlan added the comment: Slight correction: turns out this docstring appears in a lot of other places, too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 06:44:39 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 20 Aug 2012 04:44:39 +0000 Subject: [issue8810] TZ offset description is unclear in docs In-Reply-To: <1274718021.16.0.883294684947.issue8810@psf.upfronthosting.co.za> Message-ID: <1345437879.32.0.316184173234.issue8810@psf.upfronthosting.co.za> Nick Coghlan added the comment: It turns out these particular docstrings are duplicated all over the place, as time and datetime both wrap the tzinfo method, and there is both the tzinfo ABC as well as the concrete fixed offset subclasses, and this happens in both C and Python. Ben's patch currently only covers the docstrings for the Python tzinfo ABC implementation ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 07:46:03 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 20 Aug 2012 05:46:03 +0000 Subject: [issue1152248] Add support for reading records with arbitrary separators to the standard IO stack Message-ID: <1345441563.78.0.79335540412.issue1152248@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- title: Enhance file.readlines by making line separator selectable -> Add support for reading records with arbitrary separators to the standard IO stack versions: +Python 3.4 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 08:25:55 2012 From: report at bugs.python.org (Ben Finney) Date: Mon, 20 Aug 2012 06:25:55 +0000 Subject: [issue15731] Mechanism for inheriting docstrings and signatures In-Reply-To: <1345437452.28.0.514901819881.issue15731@psf.upfronthosting.co.za> Message-ID: <1345443955.86.0.615122687185.issue15731@psf.upfronthosting.co.za> Ben Finney added the comment: Attached is a patch which is more comprehensive (covering the additional locations pointed out to me by ncoghlan), and also consolidating the details into the library documentation so they're not verbosely repeated in so many places. I agree with Nick's position that the docstrings are not the place to go into great detail about the significance and background of the issues. So the docstrings in this patch are accurate, but terse; the details are in the library documentation. ---------- keywords: +patch nosy: +bignose Added file: http://bugs.python.org/file26910/issue8810_reconcile_docs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 08:42:43 2012 From: report at bugs.python.org (Ben Finney) Date: Mon, 20 Aug 2012 06:42:43 +0000 Subject: [issue15731] Mechanism for inheriting docstrings and signatures In-Reply-To: <1345437452.28.0.514901819881.issue15731@psf.upfronthosting.co.za> Message-ID: <1345444963.64.0.828639818401.issue15731@psf.upfronthosting.co.za> Ben Finney added the comment: Apologies, my previous comment and patch was sent to the wrong issue (should have gone to #8810). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 08:44:35 2012 From: report at bugs.python.org (Ben Finney) Date: Mon, 20 Aug 2012 06:44:35 +0000 Subject: [issue8810] TZ offset description is unclear in docs In-Reply-To: <1274718021.16.0.883294684947.issue8810@psf.upfronthosting.co.za> Message-ID: <1345445075.32.0.150160381518.issue8810@psf.upfronthosting.co.za> Ben Finney added the comment: Attached is a patch which is more comprehensive (covering the additional locations pointed out to me by ncoghlan), and also consolidating the details into the library documentation so they're not verbosely repeated in so many places. I agree with Nick's position that the docstrings are not the place to go into great detail about the significance and background of the issues. So the docstrings in this patch are accurate, but terse; the details are in the library documentation. ---------- Added file: http://bugs.python.org/file26911/issue8810_reconcile_docs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 08:50:28 2012 From: report at bugs.python.org (Kevin Chen) Date: Mon, 20 Aug 2012 06:50:28 +0000 Subject: [issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite In-Reply-To: <1242857063.47.0.919073638283.issue6074@psf.upfronthosting.co.za> Message-ID: <1345445428.32.0.797848982508.issue6074@psf.upfronthosting.co.za> Kevin Chen added the comment: Hi I made the following patch for this issue. It addresses the #2051 security bug. So the .pyc and .pyo files are created using the same permission as .py The MS_WINDOWS version will chmod the permission of .pyc and .pyo files to write accessible before deleting them. I have also created a test for it. This test needs cleaning up, because it is the first time I have written a test for cpython. I would love to have a look at the final committed test so I can learn how to make it better next time. I will also be happy to keep extending that test to make sure it covers more cases. A great big thanks to Nick for your help! ---------- keywords: +patch versions: +Python 3.1 Added file: http://bugs.python.org/file26912/issue6074.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 08:54:22 2012 From: report at bugs.python.org (Andrea Griffini) Date: Mon, 20 Aug 2012 06:54:22 +0000 Subject: [issue5765] stack overflow evaluating eval("()" * 30000) In-Reply-To: <1239838657.22.0.326859227165.issue5765@psf.upfronthosting.co.za> Message-ID: <1345445662.93.0.239125199081.issue5765@psf.upfronthosting.co.za> Andrea Griffini added the comment: I missed all the macrology present :-( ... the following is a patch that takes it into account (also defines a VISIT_QUIT macro to make more visible the exit points). The handling has been also extended to visit_stmt because the macros are shared. Of course all this makes sense assuming that a cleanup in case of error is indeed desired... BTW: shouldn't be all those statement macros of the "do{...}while(0)" form instead of just being wrapped in "{}" ? I see potential problems with if/else... ---------- Added file: http://bugs.python.org/file26913/compiler_recursion_limit_check_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 08:59:47 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 20 Aug 2012 06:59:47 +0000 Subject: [issue15724] Add "versionchanged" to memoryview docs In-Reply-To: <1345377223.09.0.176185074566.issue15724@psf.upfronthosting.co.za> Message-ID: <1345445987.21.0.683216891694.issue15724@psf.upfronthosting.co.za> Nick Coghlan added the comment: Just a heads up that I'm about to check in a fairly major change to the sequence docs layout. I'm leaving the memoryview block alone, so hopefully this won't cause you any problems, but there's going to be a merge in your future :) ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 09:00:06 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 20 Aug 2012 07:00:06 +0000 Subject: [issue11631] Python 2.7.1 64bit, Win7 64bit problem to read and write with UDP. In-Reply-To: <1300786239.46.0.274643383137.issue11631@psf.upfronthosting.co.za> Message-ID: <1345446006.61.0.471123550202.issue11631@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I still can't reproduce it. I'm attaching client and server scripts that communicate over 127.0.0.1. This works just fine. ---------- Added file: http://bugs.python.org/file26914/server.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 09:00:14 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 20 Aug 2012 07:00:14 +0000 Subject: [issue4966] Improving Lib Doc Sequence Types Section In-Reply-To: <1232149418.64.0.0450574767427.issue4966@psf.upfronthosting.co.za> Message-ID: <1345446014.87.0.88521642915.issue4966@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- assignee: -> ncoghlan versions: -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 09:00:18 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 20 Aug 2012 07:00:18 +0000 Subject: [issue11631] Python 2.7.1 64bit, Win7 64bit problem to read and write with UDP. In-Reply-To: <1300786239.46.0.274643383137.issue11631@psf.upfronthosting.co.za> Message-ID: <1345446018.98.0.467682953911.issue11631@psf.upfronthosting.co.za> Changes by Martin v. L?wis : Added file: http://bugs.python.org/file26915/client.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 09:00:37 2012 From: report at bugs.python.org (Andrea Griffini) Date: Mon, 20 Aug 2012 07:00:37 +0000 Subject: [issue5765] stack overflow evaluating eval("()" * 30000) In-Reply-To: <1345415249.27.0.860593206687.issue5765@psf.upfronthosting.co.za> Message-ID: Andrea Griffini added the comment: On Mon, Aug 20, 2012 at 12:27 AM, Antoine Pitrou wrote: > Indeed I don't like the introduction of COMPILER_STACK_FRAME_SCALE. > Re-using the existing infrastructure would be much easier to maintain. > The default recursion limit is 1000, which should cover any non-pathological code, IMHO. I submitted a new version with the scale lowered to 3. Using a lower value (e.g. 1) however makes "test_extended_args" fail (the test tries to compile an expression with 2500+ terms). If it's ok to make that test to throw instead then the whole scaling could be removed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 09:07:18 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 20 Aug 2012 07:07:18 +0000 Subject: [issue15645] 2to3 Grammar pickles not created when upgrading to 3.3.0b2 In-Reply-To: <1344932180.41.0.826216341416.issue15645@psf.upfronthosting.co.za> Message-ID: <1345446438.06.0.909442987423.issue15645@psf.upfronthosting.co.za> Ronald Oussoren added the comment: I'm pretty sure this is a generic Makefile bug. I could reproduce this problem with a clean install into a new prefix, after cleaning up the source tree: 'make clean' won't remove the generated file when srcdir != builddir. This line in the Makefile seems to generate the pickle file: -PYTHONPATH=$(DESTDIR)$(LIBDEST) $(RUNSHARED) \ $(PYTHON_FOR_BUILD) -Wi -c "import lib2to3.pygram,lib2to3.patcomp;lib2to3.patcomp.PatternCompiler()" This uses $(PYTHON_FOR_BUILD) to generate the cache file, and that which means the cache file is generated in the *source* tree, not in the installation tree. This command is at the end of the libinstall target, which means the generatd file is not copied into the installation prefix. Running 'make install' twice will therefore install the file. The attached patch seems to fix the issue by moving the command to the start of the libinstall target. The patch also fixes "make clean", by explicitly targetting the pickle files in $(srcdir)/Lib/lib2to3. BTW. What "known OSX problems"? BTW2. This should affect all platforms that use Makefiles (basicly anything but Windows) ---------- components: +Build keywords: +needs review, patch stage: -> patch review type: -> compile error Added file: http://bugs.python.org/file26916/issue15645.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 09:14:44 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 Aug 2012 07:14:44 +0000 Subject: [issue4966] Improving Lib Doc Sequence Types Section In-Reply-To: <1232149418.64.0.0450574767427.issue4966@psf.upfronthosting.co.za> Message-ID: <3X0mV64QTMzQNr@mail.python.org> Roundup Robot added the comment: New changeset 463f52d20314 by Nick Coghlan in branch 'default': Close #4966: revamp the sequence docs in order to better explain the state of modern Python http://hg.python.org/cpython/rev/463f52d20314 ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 09:18:35 2012 From: report at bugs.python.org (Michael Dorman) Date: Mon, 20 Aug 2012 07:18:35 +0000 Subject: [issue8943] Bug in InteractiveConsole In-Reply-To: <1276014263.34.0.524334073977.issue8943@psf.upfronthosting.co.za> Message-ID: <1345447115.56.0.082975002177.issue8943@psf.upfronthosting.co.za> Michael Dorman added the comment: I'd suggest this is an issue in the doc for the InteractiveInterpreter class. Try locals=global() and your problem goes away. (namespace == __main__)... ---------- keywords: +patch nosy: +mjdorma Added file: http://bugs.python.org/file26917/issue8943.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 09:28:25 2012 From: report at bugs.python.org (danblack) Date: Mon, 20 Aug 2012 07:28:25 +0000 Subject: [issue10852] SSL/TLS sni use in smtp, pop, imap, nntp, ftp client libs by default In-Reply-To: <1294375380.08.0.187691378511.issue10852@psf.upfronthosting.co.za> Message-ID: <1345447705.04.0.971888565632.issue10852@psf.upfronthosting.co.za> danblack added the comment: Antoine, I copied off your http example for all the other protocols. tested with: import smtplib a = smtplib.SMTP_SSL('gmail-smtp-in.l.google.com.') a.starttls() a = smtplib.SMTP_SSL('mail.internode.on.net') a = smtplib.SMTP_SSL('smtp.gmail.com') import ftplib # http://secureftp-test.com/ f = ftplib.FTP_TLS('ftp.secureftp-test.com') f.auth() import imaplib i = imaplib.IMAP4('calmail.berkley.edu') i.starttls() i = imaplib.IMAP4_SSL('mail.internode.on.net') import poplib p = poplib.POP3_SSL('calmail.berkley.edu') import nntplib n = nntplib.NNTP_SSL('news.internode.on.net') I did a network capture and saw the hostname in the SNI header ---------- nosy: +daniel-black Added file: http://bugs.python.org/file26918/issue_10852_pop-smtp-imap-nntp.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 09:43:41 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 20 Aug 2012 07:43:41 +0000 Subject: [issue15732] Crash (constructed) in _PySequence_BytesToCharpArray() Message-ID: <1345448621.33.0.149221824706.issue15732@psf.upfronthosting.co.za> New submission from Stefan Krah: Coverity found an unchecked return value in _PySequence_BytesToCharpArray(). Patch attached. A demonstration: import _posixsubprocess class Z(object): def __len__(self): return 1 _posixsubprocess.fork_exec(1,Z(),3,[1, 2],5,6,7,8,9,10,11,12,13,14,15,16,17) ---------- components: Interpreter Core files: bytes_to_charp_array.diff keywords: patch messages: 168633 nosy: skrah priority: normal severity: normal stage: patch review status: open title: Crash (constructed) in _PySequence_BytesToCharpArray() type: crash versions: Python 3.3 Added file: http://bugs.python.org/file26919/bytes_to_charp_array.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 09:58:34 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 20 Aug 2012 07:58:34 +0000 Subject: [issue15732] Crash (constructed) in _PySequence_BytesToCharpArray() In-Reply-To: <1345448621.33.0.149221824706.issue15732@psf.upfronthosting.co.za> Message-ID: <1345449514.37.0.138663612126.issue15732@psf.upfronthosting.co.za> Martin v. L?wis added the comment: LGTM. Please apply to all affected branches. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 10:11:59 2012 From: report at bugs.python.org (aliles) Date: Mon, 20 Aug 2012 08:11:59 +0000 Subject: [issue12643] code.InteractiveConsole ignores sys.excepthook In-Reply-To: <1311768607.53.0.760039078139.issue12643@psf.upfronthosting.co.za> Message-ID: <1345450319.37.0.524458619189.issue12643@psf.upfronthosting.co.za> aliles added the comment: Submitted patch. Patch creates a new unit test suite with basic unit tests for InteractiveConsole. Enhances InteractiveConsole to call sys.excepthook instead of it's own handler if the user has overridden the excepthook. The unit tests use the new unittest.mock module and ExitStack class for contextlib. ---------- keywords: +patch nosy: +ncoghlan Added file: http://bugs.python.org/file26920/issue12643.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 10:13:41 2012 From: report at bugs.python.org (Michael Dorman) Date: Mon, 20 Aug 2012 08:13:41 +0000 Subject: [issue8943] Bug in InteractiveConsole In-Reply-To: <1276014263.34.0.524334073977.issue8943@psf.upfronthosting.co.za> Message-ID: <1345450421.99.0.723175644249.issue8943@psf.upfronthosting.co.za> Changes by Michael Dorman : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 10:36:49 2012 From: report at bugs.python.org (Sandro Tosi) Date: Mon, 20 Aug 2012 08:36:49 +0000 Subject: [issue13799] Base 16 should be hexadecimal in Unicode HOWTO In-Reply-To: <1326718246.49.0.980962494093.issue13799@psf.upfronthosting.co.za> Message-ID: <1345451809.78.0.125569939831.issue13799@psf.upfronthosting.co.za> Sandro Tosi added the comment: I tend to agree with Terry that this report can be closed: base 16 is quite known and it's high likely that if you know what hexadecimal is, you also aware of the concept of "base X" and viceversa. If no-one objects, I'd just close it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 11:00:39 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 20 Aug 2012 09:00:39 +0000 Subject: [issue13370] test_ctypes fails when building python with clang In-Reply-To: <1320761474.93.0.268896325495.issue13370@psf.upfronthosting.co.za> Message-ID: <1345453239.98.0.805996193764.issue13370@psf.upfronthosting.co.za> Changes by Ronald Oussoren : ---------- keywords: +needs review, patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 11:20:05 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 Aug 2012 09:20:05 +0000 Subject: [issue15732] Crash (constructed) in _PySequence_BytesToCharpArray() In-Reply-To: <1345448621.33.0.149221824706.issue15732@psf.upfronthosting.co.za> Message-ID: <3X0qGj6b9XzQ8W@mail.python.org> Roundup Robot added the comment: New changeset cfddcf964ff0 by Stefan Krah in branch '3.2': Issue #15732: Fix (constructed) crash in _PySequence_BytesToCharpArray(). http://hg.python.org/cpython/rev/cfddcf964ff0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 11:21:40 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 20 Aug 2012 09:21:40 +0000 Subject: [issue15732] Crash (constructed) in _PySequence_BytesToCharpArray() In-Reply-To: <1345448621.33.0.149221824706.issue15732@psf.upfronthosting.co.za> Message-ID: <1345454500.5.0.170706395571.issue15732@psf.upfronthosting.co.za> Stefan Krah added the comment: Thanks for reviewing! ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed versions: +Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 11:39:51 2012 From: report at bugs.python.org (Robin Schreiber) Date: Mon, 20 Aug 2012 09:39:51 +0000 Subject: [issue15733] PEP 3121, 384 Refactoring applied to winapi module Message-ID: <1345455591.0.0.532625871045.issue15733@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the winapi module! ---------- components: Extension Modules files: _winapi_pep3121-384_v0.patch keywords: patch messages: 168639 nosy: Robin.Schreiber, astrand, effbot, loewis priority: normal severity: normal status: open title: PEP 3121, 384 Refactoring applied to winapi module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26921/_winapi_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 11:50:23 2012 From: report at bugs.python.org (Robin Schreiber) Date: Mon, 20 Aug 2012 09:50:23 +0000 Subject: [issue15733] PEP 3121, 384 Refactoring applied to winapi module In-Reply-To: <1345455591.0.0.532625871045.issue15733@psf.upfronthosting.co.za> Message-ID: <1345456223.64.0.874978300115.issue15733@psf.upfronthosting.co.za> Robin Schreiber added the comment: Forgot to change the macro definition... ---------- Added file: http://bugs.python.org/file26922/_winapi_pep3121-384_v1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 11:52:32 2012 From: report at bugs.python.org (Robin Schreiber) Date: Mon, 20 Aug 2012 09:52:32 +0000 Subject: [issue15734] PEP 3121, 384 Refactoring applied to spwd module Message-ID: <1345456351.91.0.162191182976.issue15734@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the spwd module! ---------- components: Extension Modules files: spwd_pep3121-384_v0.patch keywords: patch messages: 168641 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121, 384 Refactoring applied to spwd module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26923/spwd_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 11:55:22 2012 From: report at bugs.python.org (Robin Schreiber) Date: Mon, 20 Aug 2012 09:55:22 +0000 Subject: [issue15735] PEP 3121, 384 Refactoring applied to ossaudio module Message-ID: <1345456522.27.0.354179103538.issue15735@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the ossaudio module! ---------- components: Extension Modules files: ossaudiodev_pep3121-384_v0.patch keywords: patch messages: 168642 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121, 384 Refactoring applied to ossaudio module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26924/ossaudiodev_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 11:55:30 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 20 Aug 2012 09:55:30 +0000 Subject: [issue15736] Crash #2 (constructed overflow) in _PySequence_BytesToCharpArray() Message-ID: <1345456530.94.0.929465650961.issue15736@psf.upfronthosting.co.za> New submission from Stefan Krah: A Py_ssize_t overflow can be constructed in _PySequence_BytesToCharpArray(). Patch attached. Demonstration (requires revision >= 2af78f8a98e1): Python 3.3.0b2+ (default:2af78f8a98e1, Aug 20 2012, 11:38:54) [GCC 4.4.3] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import sys, _posixsubprocess [65851 refs] >>> class Z(object): ... def __len__(self): ... return sys.maxsize ... def __getitem__(self, i): ... return b'x' ... [65923 refs] >>> _posixsubprocess.fork_exec(1,Z(),3,[1, 2],5,6,7,8,9,10,11,12,13,14,15,16,17) Segmentation fault ---------- components: Interpreter Core files: bytes_to_charp_array_overflow.diff keywords: patch messages: 168643 nosy: skrah priority: normal severity: normal stage: patch review status: open title: Crash #2 (constructed overflow) in _PySequence_BytesToCharpArray() type: crash versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file26925/bytes_to_charp_array_overflow.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 12:36:53 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 20 Aug 2012 10:36:53 +0000 Subject: [issue12643] code.InteractiveConsole ignores sys.excepthook In-Reply-To: <1311768607.53.0.760039078139.issue12643@psf.upfronthosting.co.za> Message-ID: <1345459013.82.0.746231905782.issue12643@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 12:41:25 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 20 Aug 2012 10:41:25 +0000 Subject: [issue15731] Mechanism for inheriting docstrings and signatures In-Reply-To: <1345437452.28.0.514901819881.issue15731@psf.upfronthosting.co.za> Message-ID: <1345459285.41.0.607527977896.issue15731@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 12:41:38 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 20 Aug 2012 10:41:38 +0000 Subject: [issue15737] NULL dereference in zipimport.c Message-ID: <1345459298.63.0.0891873759151.issue15737@psf.upfronthosting.co.za> New submission from Stefan Krah: There's a use of an unchecked return value in zipimport.c. Patch attached. ---------- components: Extension Modules files: zipimport_null_dereference.diff keywords: patch messages: 168644 nosy: skrah priority: normal severity: normal stage: patch review status: open title: NULL dereference in zipimport.c type: crash versions: Python 3.3 Added file: http://bugs.python.org/file26926/zipimport_null_dereference.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 12:42:46 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 20 Aug 2012 10:42:46 +0000 Subject: [issue15721] PEP 3121, 384 Refactoring applied to tkinter module In-Reply-To: <1345287224.98.0.204885883161.issue15721@psf.upfronthosting.co.za> Message-ID: <1345459366.96.0.999544238411.issue15721@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 13:17:04 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 20 Aug 2012 11:17:04 +0000 Subject: [issue15731] Mechanism for inheriting docstrings and signatures In-Reply-To: <1345437452.28.0.514901819881.issue15731@psf.upfronthosting.co.za> Message-ID: <1345461424.48.0.463375077194.issue15731@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- Removed message: http://bugs.python.org/msg168621 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 13:17:09 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 20 Aug 2012 11:17:09 +0000 Subject: [issue15731] Mechanism for inheriting docstrings and signatures In-Reply-To: <1345437452.28.0.514901819881.issue15731@psf.upfronthosting.co.za> Message-ID: <1345461429.79.0.93777481663.issue15731@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- Removed message: http://bugs.python.org/msg168622 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 13:17:49 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 20 Aug 2012 11:17:49 +0000 Subject: [issue15731] Mechanism for inheriting docstrings and signatures In-Reply-To: <1345437452.28.0.514901819881.issue15731@psf.upfronthosting.co.za> Message-ID: <1345461469.47.0.75666814036.issue15731@psf.upfronthosting.co.za> Changes by Nick Coghlan : Removed file: http://bugs.python.org/file26910/issue8810_reconcile_docs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 13:32:20 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 20 Aug 2012 11:32:20 +0000 Subject: [issue15738] Crash (constructed) in subprocess_fork_exec() Message-ID: <1345462340.12.0.207013540635.issue15738@psf.upfronthosting.co.za> New submission from Stefan Krah: Coverity found a missing NULL check in subprocess_fork_exec(). Patch attached. Demonstration: import _posixsubprocess class Z(object): def __len__(self): return 1 _posixsubprocess.fork_exec(Z(),[b'1'],3,[1, 2],5,6,7,8,9,10,11,12,13,14,15,16,17) [Segmentation fault] ---------- components: Extension Modules files: subprocess_fork_exec.diff keywords: patch messages: 168645 nosy: skrah priority: normal severity: normal stage: patch review status: open title: Crash (constructed) in subprocess_fork_exec() type: crash versions: Python 3.3 Added file: http://bugs.python.org/file26927/subprocess_fork_exec.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 13:43:14 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 20 Aug 2012 11:43:14 +0000 Subject: [issue6749] Support for encrypted zipfiles when interpreting zipfile as script In-Reply-To: <1250830303.29.0.377270089004.issue6749@psf.upfronthosting.co.za> Message-ID: <1345462994.31.0.585779330043.issue6749@psf.upfronthosting.co.za> Nick Coghlan added the comment: Rejecting - if anyone really wants this. they can do it as their own custom import hook. ---------- resolution: -> wont fix stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 13:49:50 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 20 Aug 2012 11:49:50 +0000 Subject: [issue15730] Silence unused value warnings under Mac OS X 10.8/clang In-Reply-To: <1345423593.46.0.41871412241.issue15730@psf.upfronthosting.co.za> Message-ID: <1345463390.86.0.919852263245.issue15730@psf.upfronthosting.co.za> Ronald Oussoren added the comment: Patch looks good to me. I've added 3.3 to the list of python versions because it might be worthwhile to apply this to 3.3 as well (after 3.3.0 is released). ---------- keywords: +needs review versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 13:53:43 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 20 Aug 2012 11:53:43 +0000 Subject: [issue15737] NULL dereference in zipimport.c In-Reply-To: <1345459298.63.0.0891873759151.issue15737@psf.upfronthosting.co.za> Message-ID: <1345463623.86.0.586623812618.issue15737@psf.upfronthosting.co.za> Martin v. L?wis added the comment: LGTM. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 13:54:00 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 20 Aug 2012 11:54:00 +0000 Subject: [issue14329] proxy_bypass_macosx_sysconf does not handle singel ip addresses correctly In-Reply-To: <1331851754.34.0.615850283155.issue14329@psf.upfronthosting.co.za> Message-ID: <1345463640.95.0.115971122056.issue14329@psf.upfronthosting.co.za> Ronald Oussoren added the comment: Patch seems to be present in the current maintenance and development releases (2.7, 3.2 and 3.3). Can you confirm that this issue is no longer present in python 2.7 and later? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 14:19:06 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 Aug 2012 12:19:06 +0000 Subject: [issue15737] NULL dereference in zipimport.c In-Reply-To: <1345459298.63.0.0891873759151.issue15737@psf.upfronthosting.co.za> Message-ID: <3X0vFK1D9zzQ27@mail.python.org> Roundup Robot added the comment: New changeset c89fe7dc22ee by Stefan Krah in branch 'default': Closes #15737: Fix potential NULL dereference in zipimport.c. http://hg.python.org/cpython/rev/c89fe7dc22ee ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 14:24:49 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 20 Aug 2012 12:24:49 +0000 Subject: [issue15738] Crash (constructed) in subprocess_fork_exec() In-Reply-To: <1345462340.12.0.207013540635.issue15738@psf.upfronthosting.co.za> Message-ID: <1345465489.25.0.207331229042.issue15738@psf.upfronthosting.co.za> Martin v. L?wis added the comment: That's fine, please apply ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 14:32:52 2012 From: report at bugs.python.org (aliles) Date: Mon, 20 Aug 2012 12:32:52 +0000 Subject: [issue12643] code.InteractiveConsole ignores sys.excepthook In-Reply-To: <1311768607.53.0.760039078139.issue12643@psf.upfronthosting.co.za> Message-ID: <1345465972.52.0.276733055186.issue12643@psf.upfronthosting.co.za> aliles added the comment: New patch to address comments provide by Nick Coghlan in person at PyCon-AU 2012. ---------- Added file: http://bugs.python.org/file26928/issue12643_2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 14:38:06 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 20 Aug 2012 12:38:06 +0000 Subject: [issue15736] Crash #2 (constructed overflow) in _PySequence_BytesToCharpArray() In-Reply-To: <1345456530.94.0.929465650961.issue15736@psf.upfronthosting.co.za> Message-ID: <1345466286.57.0.168683309478.issue15736@psf.upfronthosting.co.za> Martin v. L?wis added the comment: It's fine if the Rietveld comments are addressed. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 14:40:31 2012 From: report at bugs.python.org (Ralf Schmitt) Date: Mon, 20 Aug 2012 12:40:31 +0000 Subject: [issue14406] Race condition in concurrent.futures In-Reply-To: <1332700603.2.0.848156169458.issue14406@psf.upfronthosting.co.za> Message-ID: <1345466431.98.0.637507860099.issue14406@psf.upfronthosting.co.za> Changes by Ralf Schmitt : ---------- nosy: +schmir _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 14:48:43 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 Aug 2012 12:48:43 +0000 Subject: [issue15738] Crash (constructed) in subprocess_fork_exec() In-Reply-To: <1345462340.12.0.207013540635.issue15738@psf.upfronthosting.co.za> Message-ID: <3X0vvT59FBzPxm@mail.python.org> Roundup Robot added the comment: New changeset 03c98d05b140 by Stefan Krah in branch '3.2': Issue #15738: Fix a missing NULL check in subprocess_fork_exec(). http://hg.python.org/cpython/rev/03c98d05b140 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 14:51:53 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 20 Aug 2012 12:51:53 +0000 Subject: [issue15738] Crash (constructed) in subprocess_fork_exec() In-Reply-To: <1345462340.12.0.207013540635.issue15738@psf.upfronthosting.co.za> Message-ID: <1345467113.11.0.492929214315.issue15738@psf.upfronthosting.co.za> Stefan Krah added the comment: Thanks again! ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed versions: +Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 15:02:50 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 Aug 2012 13:02:50 +0000 Subject: [issue12643] code.InteractiveConsole ignores sys.excepthook In-Reply-To: <1311768607.53.0.760039078139.issue12643@psf.upfronthosting.co.za> Message-ID: <3X0wD23Xw8zQB7@mail.python.org> Roundup Robot added the comment: New changeset a812de69b493 by Nick Coghlan in branch 'default': Issue #12643: Respect sys.excepthook in code.InteractiveConsole http://hg.python.org/cpython/rev/a812de69b493 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 15:04:27 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 20 Aug 2012 13:04:27 +0000 Subject: [issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite In-Reply-To: <1242857063.47.0.919073638283.issue6074@psf.upfronthosting.co.za> Message-ID: <1345467867.88.0.574400523231.issue6074@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- assignee: -> ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 15:10:06 2012 From: report at bugs.python.org (Ralf Schmitt) Date: Mon, 20 Aug 2012 13:10:06 +0000 Subject: [issue14406] Race condition in concurrent.futures In-Reply-To: <1332700603.2.0.848156169458.issue14406@psf.upfronthosting.co.za> Message-ID: <1345468206.48.0.257074756083.issue14406@psf.upfronthosting.co.za> Ralf Schmitt added the comment: I think having a lock here is unnecessary. The following code should work: def _decrement_pending_calls(self): if self.num_pending_calls == len(self.finished_futures): self.event.set() (well, maybe the method should also be renamed then) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 15:17:18 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 20 Aug 2012 13:17:18 +0000 Subject: [issue15733] PEP 3121, 384 Refactoring applied to winapi module In-Reply-To: <1345455591.0.0.532625871045.issue15733@psf.upfronthosting.co.za> Message-ID: <1345468638.27.0.362108497589.issue15733@psf.upfronthosting.co.za> Richard Oudkerk added the comment: I don't see why you made has_CancelIoEx part of the module state. Availability of CancelIoEx only depends on the version of Windows you have, so it will not change if you reload the module. BTW, I think you forgot to delete the has_CancelIoEx global, and to initialize winapi__state(m)->has_CancelIoEx to -1. ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 15:41:10 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 20 Aug 2012 13:41:10 +0000 Subject: [issue14649] doctest.DocTestSuite error misleading when module has no docstrings In-Reply-To: <1335192861.9.0.305748973415.issue14649@psf.upfronthosting.co.za> Message-ID: <1345470070.21.0.763695748387.issue14649@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Ok, I'm +0 for that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 15:47:14 2012 From: report at bugs.python.org (Apple Grew) Date: Mon, 20 Aug 2012 13:47:14 +0000 Subject: [issue15739] Python crashes with "Bus error: 10" Message-ID: <1345470434.58.0.741490128779.issue15739@psf.upfronthosting.co.za> New submission from Apple Grew: Python crashes when I try to access (by sending http request from borwser) my Django application. OS: Mac OSX Lion Python version: 2.7.1 (This was pre-bundled with OS and not a MacPort). There isn't a simple test case but I do have an open source app which where I am able to replicate this always on my system. 0. Make sure you have Django 1.4 installed. 1. Download the code at https://github.com/applegrew/django-select2/tree/v1.1-PythonCrasher 2. cd to django-select2/testapp folder. 3. Use python manage.py runserver & to run the server. 4. Now try accessing http://127.0.0.1:8000/ . It should crash immediately. Lines which seem to cause the crash. Follow the following instructions and the application won't crash again. 1. Open django_select2/fields.py. 2. Comment line 128, uncomment line 129. 3. Uncomment line 156 and comment lines 158 and 159. 4. Now run the app again. This time it should work. ---------- components: Interpreter Core files: Process Python.txt messages: 168660 nosy: Apple Grew priority: normal severity: normal status: open title: Python crashes with "Bus error: 10" type: crash versions: Python 2.7 Added file: http://bugs.python.org/file26929/Process Python.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 16:25:00 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 20 Aug 2012 14:25:00 +0000 Subject: [issue15740] test_ssl failure when cacert.org CA cert in system keychain on OSX Message-ID: <1345472699.98.0.29406283833.issue15740@psf.upfronthosting.co.za> New submission from Ronald Oussoren: On my laptop (running OSX 10.8, but I have noticed the same on earlier OSX releases) test_ssl fails: ====================================================================== FAIL: test_connect (test.test_ssl.NetworkedTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/ronald/Projects/python/rw/default/Lib/test/test_ssl.py", line 650, in test_connect s.connect, ("svn.python.org", 443)) AssertionError: SSLError not raised by connect ====================================================================== FAIL: test_connect_with_context (test.test_ssl.NetworkedTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/ronald/Projects/python/rw/default/Lib/test/test_ssl.py", line 743, in test_connect_with_context s.connect, ("svn.python.org", 443)) AssertionError: SSLError not raised by connect ====================================================================== FAIL: test_get_server_certificate (test.test_ssl.NetworkedTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/ronald/Projects/python/rw/default/Lib/test/test_ssl.py", line 848, in test_get_server_certificate _test_get_server_certificate('svn.python.org', 443, SVN_PYTHON_ORG_ROOT_CERT) File "/Users/ronald/Projects/python/rw/default/Lib/test/test_ssl.py", line 840, in _test_get_server_certificate self.fail("Got server certificate %s for %s:%s!" % (pem, host, port)) AssertionError: Got server certificate -----BEGIN CERTIFICATE----- MIIEmTCCAoGgAwIBAgIDCyOkMA0GCSqGSIb3DQEBBQUAMHkxEDAOBgNVBAoTB1Jv b3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9y dEBjYWNlcnQub3JnMB4XDTExMTIyNTIxMzIxNVoXDTEzMTIyNDIxMzIxNVowGTEX MBUGA1UEAxMOc3ZuLnB5dGhvbi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDM6un3wTW9+HVJ7KC+/GwL0KAxehug0tw2YoSSX+TGxLyr9AUtBHQk hCNWhRLewa0WMOY6hxIIQY1Hp6vreDiCbBehjVkEAydlKBzaAsgYCEbCC/ZaMzhv aaFAiLVeaxAKJsBGUJNz5hGgzd67A6SGz+XK7qDWig4NR5eFrsr3DvjyEM7txMiG gftGWLkadOuqUQsI20AykBGi+RxmrQIwqO2svGmje89DsWVILdP37PssM2zqRonh 4fUKooei3L43tXbTdHayXc9NtFS7q8T4eUlyWaD+BtP80QQOQFFvi+qZpme9bmYI 7YPX+e86lZtxAKM9nWrP93qc+2nS0MsHAgMBAAGjgYkwgYYwDAYDVR0TAQH/BAIw ADA0BgNVHSUELTArBggrBgEFBQcDAgYIKwYBBQUHAwEGCWCGSAGG+EIEAQYKKwYB BAGCNwoDAzALBgNVHQ8EBAMCBaAwMwYIKwYBBQUHAQEEJzAlMCMGCCsGAQUFBzAB hhdodHRwOi8vb2NzcC5jYWNlcnQub3JnLzANBgkqhkiG9w0BAQUFAAOCAgEAEsw6 TMEXRn8ex1feaSNB5r2/aCLKE33ssGTp5HAyFo04YF2WaGK8HgjEg/fqrGUaSORw P1ikBNTAUiaKbRQtcIvQPg8Zk4lSiQZ7m6ePs4hKdFVKeOpykwQyTsm+NaGk4xtM Zk0XsWkzFntG676MT2FGvDCn0XhtdpAGJy59FXQ1mto9j99AvXpcl9Ja7tRYI/mI goq3Gu6lwIoYSnslOtIWgsj9Wog1Kug7zoGscxY6z2lk15wbQlQbXbdAbVW7RZry 07eGwROLpE8tydRvvCbJp3P7FE+aAk1D3fQi09G0dUJWRmvBoFOVZCfHmGx23Mpz YTVgGP1bydjjzzhNAqaKctLf6g3UuUwsOJ1pso4Cr/00EDWG1JsRb4wtlpAEPSnb vjr/TqHMfefeQf4DmgWo1DutKhUBur5t+VukVCN1z44VtKeu8zaNaA3vR2Q+jArl YxIFGUTuBcDHBx5Zl0Wcauoe3IbIBckBk2+WOBXVAdj00a46XJ4OHesft63HVOLn vsKqAhwHPgsH0iTrgbO6ky0Xk573aJWz5wrlYin2FzHXsfJkA7U0wesrG4AFdeAm zICOAFz9bOhyi6t5c0whF6L0W6Gt4cW+tERG+CD++2svdh8JP9QgozoSKd9N33bg q5qGifkRs3lTJQGn2wDkgepX1vtshWgRXR9QTRw= -----END CERTIFICATE----- for svn.python.org:443! This machine has the cacert root certificate as a trusted key in the system keychain. This is using Apple's copy of OpenSSL, I haven't tested yet if the test failure is also present with the upstream edition of OpenSSL. The failure seems to occur because the test assumes that the OpenSSL library either won't load a CA list at all when ca_cert is not specified, or that the default CA list doesn't contain the cacert.org one. I can avoid the test failures by always specifying ca_certs in these tests, but point the argument to an empty file. That's probably not the right solution though, hence I haven't included this as a patch. ---------- assignee: ronaldoussoren components: Library (Lib), Macintosh, Tests messages: 168661 nosy: ronaldoussoren priority: normal severity: normal status: open title: test_ssl failure when cacert.org CA cert in system keychain on OSX versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 16:25:23 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 20 Aug 2012 14:25:23 +0000 Subject: [issue15740] test_ssl failure when cacert.org CA cert in system keychain on OSX In-Reply-To: <1345472699.98.0.29406283833.issue15740@psf.upfronthosting.co.za> Message-ID: <1345472723.2.0.0131957685044.issue15740@psf.upfronthosting.co.za> Changes by Ronald Oussoren : ---------- assignee: ronaldoussoren -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 16:39:26 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 20 Aug 2012 14:39:26 +0000 Subject: [issue12643] code.InteractiveConsole ignores sys.excepthook In-Reply-To: <1311768607.53.0.760039078139.issue12643@psf.upfronthosting.co.za> Message-ID: <1345473566.36.0.00299096635489.issue12643@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Is it finished or not? Also looks like patch applied to 3.3 while issue marked for 2.7 and 3.2 also. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 16:42:24 2012 From: report at bugs.python.org (Ross Lagerwall) Date: Mon, 20 Aug 2012 14:42:24 +0000 Subject: [issue15739] Python crashes with "Bus error: 10" In-Reply-To: <1345470434.58.0.741490128779.issue15739@psf.upfronthosting.co.za> Message-ID: <1345473744.8.0.674755863822.issue15739@psf.upfronthosting.co.za> Ross Lagerwall added the comment: Well the app has an infinite recursion. This shows on Fedora Linux 17: """ Request Method: GET Request URL: http://127.0.0.1:8000/ Django Version: 1.4 Exception Type: RuntimeError Exception Value: maximum recursion depth exceeded while calling a Python object Exception Location: /tmp/dg/django_select2/fields.py in __init__, line 146 Python Executable: /home/ross/src/python/2.7/python Python Version: 2.7.1 ... """ Of course, this shouldn't cause a bus error in Python. Perhaps try a different build of Python or try building it yourself? ---------- nosy: +rosslagerwall _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 16:46:13 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 20 Aug 2012 14:46:13 +0000 Subject: [issue15741] NULL dereference in builtin_compile() Message-ID: <1345473973.6.0.856256957918.issue15741@psf.upfronthosting.co.za> New submission from Stefan Krah: Coverity found a missing NULL check in builtin_compile(). Patch attached. ---------- components: Interpreter Core files: builtin-compile-check-null.diff keywords: patch messages: 168664 nosy: skrah priority: normal severity: normal stage: patch review status: open title: NULL dereference in builtin_compile() type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file26930/builtin-compile-check-null.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 16:50:23 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 20 Aug 2012 14:50:23 +0000 Subject: [issue12643] code.InteractiveConsole ignores sys.excepthook In-Reply-To: <1311768607.53.0.760039078139.issue12643@psf.upfronthosting.co.za> Message-ID: <1345474223.96.0.482928962085.issue12643@psf.upfronthosting.co.za> Nick Coghlan added the comment: The patch also adds a test suite for the code module, in order to demonstrate that the issue is actually fixed. However, due to the interactive nature of the component, the new tests rely on unittest.mock. Backporting the test suite would mean eliminating that dependency (which is doable, but somewhat tedious). So we can either leave the issue open, indicating that a backport of the tests and change to 2.7 (and perhaps 3.2) is still acceptable, or else declare that we aren't going to worry about that and just leave this as something that is only supported properly in 3.3+ ---------- versions: -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 16:53:05 2012 From: report at bugs.python.org (Patrick Welche) Date: Mon, 20 Aug 2012 14:53:05 +0000 Subject: [issue13789] _tkinter does not build on Windows 7 In-Reply-To: <1326603556.49.0.117233546142.issue13789@psf.upfronthosting.co.za> Message-ID: <1345474385.53.0.918441665125.issue13789@psf.upfronthosting.co.za> Changes by Patrick Welche : ---------- nosy: +prlw1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 16:55:38 2012 From: report at bugs.python.org (Patrick Welche) Date: Mon, 20 Aug 2012 14:55:38 +0000 Subject: [issue14873] Windows devguide: clarification for build errors due to missing optional dependencies In-Reply-To: <1337635934.97.0.00774228484409.issue14873@psf.upfronthosting.co.za> Message-ID: <1345474538.86.0.850483384546.issue14873@psf.upfronthosting.co.za> Changes by Patrick Welche : ---------- nosy: +prlw1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 16:56:37 2012 From: report at bugs.python.org (Patrick Welche) Date: Mon, 20 Aug 2012 14:56:37 +0000 Subject: [issue13210] Support Visual Studio 2010 In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za> Message-ID: <1345474597.06.0.570633713154.issue13210@psf.upfronthosting.co.za> Changes by Patrick Welche : ---------- nosy: +prlw1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 16:57:08 2012 From: report at bugs.python.org (Patrick Welche) Date: Mon, 20 Aug 2012 14:57:08 +0000 Subject: [issue13461] Error on test_issue_1395_5 with Python 2.7 and VS2010 In-Reply-To: <1322056958.99.0.498945300571.issue13461@psf.upfronthosting.co.za> Message-ID: <1345474628.7.0.315580323464.issue13461@psf.upfronthosting.co.za> Changes by Patrick Welche : ---------- nosy: +prlw1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 16:58:50 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 20 Aug 2012 14:58:50 +0000 Subject: [issue12643] code.InteractiveConsole ignores sys.excepthook In-Reply-To: <1311768607.53.0.760039078139.issue12643@psf.upfronthosting.co.za> Message-ID: <1345474730.04.0.403687387653.issue12643@psf.upfronthosting.co.za> Andrew Svetlov added the comment: I'm ok with current status. Thanks for clarification. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 17:01:23 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 20 Aug 2012 15:01:23 +0000 Subject: [issue15733] PEP 3121, 384 Refactoring applied to winapi module In-Reply-To: <1345455591.0.0.532625871045.issue15733@psf.upfronthosting.co.za> Message-ID: <1345474883.29.0.613551234583.issue15733@psf.upfronthosting.co.za> Martin v. L?wis added the comment: In addition, I plan to actively drop Windows 2000 support post 3.3, so CancelIO can be presumed to be present. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 17:06:09 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 20 Aug 2012 15:06:09 +0000 Subject: [issue15741] NULL dereference in builtin_compile() In-Reply-To: <1345473973.6.0.856256957918.issue15741@psf.upfronthosting.co.za> Message-ID: <1345475169.22.0.63619983555.issue15741@psf.upfronthosting.co.za> Martin v. L?wis added the comment: That's fine, please apply. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 17:09:33 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 20 Aug 2012 15:09:33 +0000 Subject: [issue15736] Crash #2 (constructed overflow) in _PySequence_BytesToCharpArray() In-Reply-To: <1345456530.94.0.929465650961.issue15736@psf.upfronthosting.co.za> Message-ID: <1345475373.76.0.211064373657.issue15736@psf.upfronthosting.co.za> Stefan Krah added the comment: issue15736.diff shows what I meant in the comments. I find this slightly more readable than casting the big RHS expression. ---------- Added file: http://bugs.python.org/file26931/issue15632.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 17:11:18 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 20 Aug 2012 15:11:18 +0000 Subject: [issue15736] Crash #2 (constructed overflow) in _PySequence_BytesToCharpArray() In-Reply-To: <1345456530.94.0.929465650961.issue15736@psf.upfronthosting.co.za> Message-ID: <1345475478.75.0.101515566574.issue15736@psf.upfronthosting.co.za> Changes by Stefan Krah : Removed file: http://bugs.python.org/file26931/issue15632.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 17:14:53 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 20 Aug 2012 15:14:53 +0000 Subject: [issue15736] Crash #2 (constructed overflow) in _PySequence_BytesToCharpArray() In-Reply-To: <1345456530.94.0.929465650961.issue15736@psf.upfronthosting.co.za> Message-ID: <1345475693.31.0.871342157501.issue15736@psf.upfronthosting.co.za> Stefan Krah added the comment: Sorry, the right diff this time. ---------- Added file: http://bugs.python.org/file26932/issue15736.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 17:25:32 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 20 Aug 2012 15:25:32 +0000 Subject: [issue13370] test_ctypes fails when building python with clang In-Reply-To: <1320761474.93.0.268896325495.issue13370@psf.upfronthosting.co.za> Message-ID: <1345476332.79.0.196533368013.issue13370@psf.upfronthosting.co.za> Ronald Oussoren added the comment: I've tested the patch on OSX 10.5 with GCC and all tests pass. I'd like to get this into 3.3rc1 as the test failure indicate a problem that could cause very vague problems for users of the ctypes library that use clang on OSX to build python (which includes anyone building python from source on OSX 10.7 or later) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 17:36:37 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 Aug 2012 15:36:37 +0000 Subject: [issue15741] NULL dereference in builtin_compile() In-Reply-To: <1345473973.6.0.856256957918.issue15741@psf.upfronthosting.co.za> Message-ID: <3X0zdC3p4TzQDf@mail.python.org> Roundup Robot added the comment: New changeset d5ee1a06101f by Stefan Krah in branch '3.2': Issue #15741: Fix potential NULL dereference. Found by Coverity. http://hg.python.org/cpython/rev/d5ee1a06101f New changeset 2b4f6770877e by Stefan Krah in branch '2.7': Issue #15741: Fix potential NULL dereference. Found by Coverity. http://hg.python.org/cpython/rev/2b4f6770877e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 17:41:01 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 20 Aug 2012 15:41:01 +0000 Subject: [issue15741] NULL dereference in builtin_compile() In-Reply-To: <1345473973.6.0.856256957918.issue15741@psf.upfronthosting.co.za> Message-ID: <1345477261.5.0.115887346445.issue15741@psf.upfronthosting.co.za> Stefan Krah added the comment: Thanks, done. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed versions: +Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 18:07:28 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 20 Aug 2012 16:07:28 +0000 Subject: [issue15724] Add "versionchanged" to memoryview docs In-Reply-To: <1345445987.21.0.683216891694.issue15724@psf.upfronthosting.co.za> Message-ID: <20120820160727.GA19757@sleipnir.bytereef.org> Stefan Krah added the comment: Thanks for the warning. I see you've already committed, so my natural inertia has protected me from additional merge work. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 18:22:50 2012 From: report at bugs.python.org (Stan Seibert) Date: Mon, 20 Aug 2012 16:22:50 +0000 Subject: [issue13370] test_ctypes fails when building python with clang In-Reply-To: <1320761474.93.0.268896325495.issue13370@psf.upfronthosting.co.za> Message-ID: <1345479770.49.0.0444333785287.issue13370@psf.upfronthosting.co.za> Stan Seibert added the comment: I can also confirm that the patch applied to the current tip (663de4dbb88a) passes test_ctypes now with Clang 4.0 on OS X 10.8. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 18:24:04 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 20 Aug 2012 16:24:04 +0000 Subject: [issue15645] 2to3 Grammar pickles not created when upgrading to 3.3.0b2 In-Reply-To: <1344932180.41.0.826216341416.issue15645@psf.upfronthosting.co.za> Message-ID: <1345479844.63.0.88291898656.issue15645@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I had the impression that there *were* problems with compiling 3.3 on the new OSX and Xcode or something. If that is wrong or all fixed, great. Sorry for the noise. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 18:31:32 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 20 Aug 2012 16:31:32 +0000 Subject: [issue15645] 2to3 Grammar pickles not created when upgrading to 3.3.0b2 In-Reply-To: <1344932180.41.0.826216341416.issue15645@psf.upfronthosting.co.za> Message-ID: <1345480292.66.0.0502747985221.issue15645@psf.upfronthosting.co.za> Ronald Oussoren added the comment: There were some problems building using llvm-gcc, those have been resolved by detecting falling back to clang when llvm-gcc is detected. That's the only real problem I know of. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 18:33:33 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 20 Aug 2012 16:33:33 +0000 Subject: [issue15645] 2to3 Grammar pickles not created when upgrading to 3.3.0b2 In-Reply-To: <1344932180.41.0.826216341416.issue15645@psf.upfronthosting.co.za> Message-ID: <1345480413.03.0.427480976557.issue15645@psf.upfronthosting.co.za> Ronald Oussoren added the comment: BTW. I wouldn't mind a patch review, particularly by someone that can easily test on Linux. I'm not too keen on checking in this patch without a test on Linux, not this close to 3.3rc1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 18:48:30 2012 From: report at bugs.python.org (Eugene Voytitsky) Date: Mon, 20 Aug 2012 16:48:30 +0000 Subject: [issue1065427] sre_parse group limit check missing with 'python -O' Message-ID: <1345481310.73.0.108043043865.issue1065427@psf.upfronthosting.co.za> Eugene Voytitsky added the comment: Hi all, does someone can answer the questions asked by Keith Briggs in 2004: > What is the reason for this limit? Can it easily be removed? > It is causing me many problems. I also stuck into the problem with this limitation. Details you can read here - https://groups.google.com/forum/#!topic/ply-hack/iQLnZpTL1GA[1-25] Thanks. ---------- nosy: +Eugene.Voytitsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 19:11:56 2012 From: report at bugs.python.org (Mike Hoy) Date: Mon, 20 Aug 2012 17:11:56 +0000 Subject: [issue15742] SQLite3 documentation changes Message-ID: <1345482716.74.0.73441059198.issue15742@psf.upfronthosting.co.za> New submission from Mike Hoy: In Core-Mentorship we discussed this and decided on the following patch. ---------- assignee: docs at python components: Documentation files: sqlite3-docs-changes.diff keywords: patch messages: 168681 nosy: docs at python, mikehoy, r.david.murray priority: normal severity: normal status: open title: SQLite3 documentation changes versions: Python 3.3 Added file: http://bugs.python.org/file26933/sqlite3-docs-changes.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 19:38:47 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 Aug 2012 17:38:47 +0000 Subject: [issue15726] PyState_FindModule false length-comparison fix In-Reply-To: <1345382232.77.0.93004938409.issue15726@psf.upfronthosting.co.za> Message-ID: <3X12L93Z2wzQ3D@mail.python.org> Roundup Robot added the comment: New changeset b96a4b1e7ecb by Antoine Pitrou in branch '3.2': Issue #15726: Fix incorrect bounds checking in PyState_FindModule. http://hg.python.org/cpython/rev/b96a4b1e7ecb New changeset 7789111afe05 by Antoine Pitrou in branch 'default': Issue #15726: Fix incorrect bounds checking in PyState_FindModule. http://hg.python.org/cpython/rev/7789111afe05 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 19:39:40 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 20 Aug 2012 17:39:40 +0000 Subject: [issue15726] PyState_FindModule false length-comparison fix In-Reply-To: <1345382232.77.0.93004938409.issue15726@psf.upfronthosting.co.za> Message-ID: <1345484380.57.0.0929906130672.issue15726@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- resolution: -> invalid stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 19:47:03 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Mon, 20 Aug 2012 17:47:03 +0000 Subject: [issue15742] SQLite3 documentation changes In-Reply-To: <1345482716.74.0.73441059198.issue15742@psf.upfronthosting.co.za> Message-ID: <1345484823.83.0.216528926354.issue15742@psf.upfronthosting.co.za> Petri Lehtinen added the comment: + print(c.fetchone()) I don't think this line should be added because it's not there after the first select. ---------- nosy: +petri.lehtinen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 19:56:48 2012 From: report at bugs.python.org (Mike Hoy) Date: Mon, 20 Aug 2012 17:56:48 +0000 Subject: [issue15742] SQLite3 documentation changes In-Reply-To: <1345482716.74.0.73441059198.issue15742@psf.upfronthosting.co.za> Message-ID: <1345485408.62.0.832377395407.issue15742@psf.upfronthosting.co.za> Mike Hoy added the comment: Removed print function in this patch. ---------- Added file: http://bugs.python.org/file26934/sqlite3-docs-remove-print.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 20:10:07 2012 From: report at bugs.python.org (Apple Grew) Date: Mon, 20 Aug 2012 18:10:07 +0000 Subject: [issue15739] Python crashes with "Bus error: 10" In-Reply-To: <1345470434.58.0.741490128779.issue15739@psf.upfronthosting.co.za> Message-ID: <1345486207.65.0.28337856535.issue15739@psf.upfronthosting.co.za> Apple Grew added the comment: Well I tried with Python2.6 (MacPort) now. It too crashes with Bus error. I guess this has something to do with OSX ports. Please investigate. Whatever it maybe, but the process must not crash like that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 20:18:19 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 Aug 2012 18:18:19 +0000 Subject: [issue15742] SQLite3 documentation changes In-Reply-To: <1345482716.74.0.73441059198.issue15742@psf.upfronthosting.co.za> Message-ID: <3X13Cn6cbLzQGb@mail.python.org> Roundup Robot added the comment: New changeset 80b15cf2611e by R David Murray in branch '3.2': #15742: clarify sqlite parameter substitution example. http://hg.python.org/cpython/rev/80b15cf2611e New changeset 2eafe04cb6ed by R David Murray in branch 'default': Merge #15742: clarify sqlite parameter substitution example. http://hg.python.org/cpython/rev/2eafe04cb6ed New changeset 857c9e1fdd1e by R David Murray in branch '2.7': #15742: clarify sqlite parameter substitution example. http://hg.python.org/cpython/rev/857c9e1fdd1e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 20:21:40 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 20 Aug 2012 18:21:40 +0000 Subject: [issue15742] SQLite3 documentation changes In-Reply-To: <1345482716.74.0.73441059198.issue15742@psf.upfronthosting.co.za> Message-ID: <1345486900.16.0.526562813702.issue15742@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Mike. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed versions: +Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 20:22:53 2012 From: report at bugs.python.org (Apple Grew) Date: Mon, 20 Aug 2012 18:22:53 +0000 Subject: [issue15739] Python crashes with "Bus error: 10" In-Reply-To: <1345470434.58.0.741490128779.issue15739@psf.upfronthosting.co.za> Message-ID: <1345486973.55.0.992195821671.issue15739@psf.upfronthosting.co.za> Apple Grew added the comment: If you believe this is impossible then possibly there could be a memory overflow issue which triggers this error in OSX builds. In other builds it may not cause that problem or don't share the same faulty code. ---------- assignee: -> ronaldoussoren components: +Macintosh -Interpreter Core nosy: +ronaldoussoren versions: +Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 20:35:27 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 Aug 2012 18:35:27 +0000 Subject: [issue15199] Default mimetype for javascript should be application/javascript In-Reply-To: <1340781019.87.0.733806504492.issue15199@psf.upfronthosting.co.za> Message-ID: <3X13bt470rzQGc@mail.python.org> Roundup Robot added the comment: New changeset 20985f52b65e by Petri Lehtinen in branch '2.7': #15199: Fix JavaScript's default MIME type to application/javascript http://hg.python.org/cpython/rev/20985f52b65e New changeset b64947b6f947 by Petri Lehtinen in branch '3.2': #15199: Fix JavaScript's default MIME type to application/javascript http://hg.python.org/cpython/rev/b64947b6f947 New changeset d4d5cfef5323 by Petri Lehtinen in branch 'default': #15199: Fix JavaScript's default MIME type to application/javascript http://hg.python.org/cpython/rev/d4d5cfef5323 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 20:37:59 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Mon, 20 Aug 2012 18:37:59 +0000 Subject: [issue15199] Default mimetype for javascript should be application/javascript In-Reply-To: <1340781019.87.0.733806504492.issue15199@psf.upfronthosting.co.za> Message-ID: <1345487879.17.0.473637782195.issue15199@psf.upfronthosting.co.za> Petri Lehtinen added the comment: Fixed, thanks for the patch. ---------- nosy: +petri.lehtinen resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 20:53:27 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 20 Aug 2012 18:53:27 +0000 Subject: [issue15736] Crash #2 (constructed overflow) in _PySequence_BytesToCharpArray() In-Reply-To: <1345456530.94.0.929465650961.issue15736@psf.upfronthosting.co.za> Message-ID: <1345488807.4.0.433438463128.issue15736@psf.upfronthosting.co.za> Stefan Krah added the comment: Bad news: gcc-4.6.3 needs the size_t cast, otherwise it warns with both the assert() and the (argc < 0) version. So I suggest using the size_t cast and a comment. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 21:58:39 2012 From: report at bugs.python.org (Jeff Knupp) Date: Mon, 20 Aug 2012 19:58:39 +0000 Subject: [issue15743] test_urllib2/test_urllib use deprecated urllib.Request methods Message-ID: <1345492719.87.0.291856407657.issue15743@psf.upfronthosting.co.za> New submission from Jeff Knupp: urllib was updated to deprecate a number of Request methods for 3.3. The test_urllib2 and test_urllib tests still use some of the deprecated methods. ---------- components: Tests messages: 168692 nosy: Jeff.Knupp priority: normal severity: normal status: open title: test_urllib2/test_urllib use deprecated urllib.Request methods type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 21:59:21 2012 From: report at bugs.python.org (Jeff Knupp) Date: Mon, 20 Aug 2012 19:59:21 +0000 Subject: [issue15743] test_urllib2/test_urllib use deprecated urllib.Request methods In-Reply-To: <1345492719.87.0.291856407657.issue15743@psf.upfronthosting.co.za> Message-ID: <1345492761.18.0.790858526284.issue15743@psf.upfronthosting.co.za> Jeff Knupp added the comment: Attaching patch. ---------- keywords: +patch Added file: http://bugs.python.org/file26935/test_urllib.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 22:01:32 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Mon, 20 Aug 2012 20:01:32 +0000 Subject: [issue15743] test_urllib2/test_urllib use deprecated urllib.Request methods In-Reply-To: <1345492719.87.0.291856407657.issue15743@psf.upfronthosting.co.za> Message-ID: <1345492892.54.0.908430441096.issue15743@psf.upfronthosting.co.za> Changes by Senthil Kumaran : ---------- assignee: -> orsenthil nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 22:02:27 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Mon, 20 Aug 2012 20:02:27 +0000 Subject: [issue15743] test_urllib2/test_urllib use deprecated urllib.Request methods In-Reply-To: <1345492719.87.0.291856407657.issue15743@psf.upfronthosting.co.za> Message-ID: <1345492947.9.0.594780579109.issue15743@psf.upfronthosting.co.za> Senthil Kumaran added the comment: The patch looks good to me. Thanks Jeff. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 22:14:04 2012 From: report at bugs.python.org (Jeff Knupp) Date: Mon, 20 Aug 2012 20:14:04 +0000 Subject: [issue15743] test_urllib2/test_urllib use deprecated urllib.Request methods In-Reply-To: <1345492719.87.0.291856407657.issue15743@psf.upfronthosting.co.za> Message-ID: <1345493644.95.0.727152441018.issue15743@psf.upfronthosting.co.za> Changes by Jeff Knupp : Removed file: http://bugs.python.org/file26935/test_urllib.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 22:15:50 2012 From: report at bugs.python.org (Jeff Knupp) Date: Mon, 20 Aug 2012 20:15:50 +0000 Subject: [issue15743] test_urllib2/test_urllib use deprecated urllib.Request methods In-Reply-To: <1345492719.87.0.291856407657.issue15743@psf.upfronthosting.co.za> Message-ID: <1345493750.03.0.57533767522.issue15743@psf.upfronthosting.co.za> Jeff Knupp added the comment: Updated with correct patch file. ---------- Added file: http://bugs.python.org/file26936/test_urllib.patch.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 22:17:34 2012 From: report at bugs.python.org (Jeff Knupp) Date: Mon, 20 Aug 2012 20:17:34 +0000 Subject: [issue15743] test_urllib2/test_urllib use deprecated urllib.Request methods In-Reply-To: <1345492719.87.0.291856407657.issue15743@psf.upfronthosting.co.za> Message-ID: <1345493854.72.0.210930686065.issue15743@psf.upfronthosting.co.za> Jeff Knupp added the comment: Senthil, sorry, missed your comment and hadn't realized anyone had seen the patch yet. I replaced it with an updated version (had missed a few places deprecated functions were used). Could you review the new patch instead? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 22:20:21 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Mon, 20 Aug 2012 20:20:21 +0000 Subject: [issue15743] test_urllib2/test_urllib use deprecated urllib.Request methods In-Reply-To: <1345492719.87.0.291856407657.issue15743@psf.upfronthosting.co.za> Message-ID: <1345494021.0.0.363893398247.issue15743@psf.upfronthosting.co.za> Senthil Kumaran added the comment: One change. get_method has only been changed not deprecated. Those test cases should not change and moreover the current change to assert against .method results in a failure too. get_method would return "GET" when .method is None or empty. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 22:23:28 2012 From: report at bugs.python.org (Jeff Knupp) Date: Mon, 20 Aug 2012 20:23:28 +0000 Subject: [issue15743] test_urllib2/test_urllib use deprecated urllib.Request methods In-Reply-To: <1345492719.87.0.291856407657.issue15743@psf.upfronthosting.co.za> Message-ID: <1345494208.55.0.409540141704.issue15743@psf.upfronthosting.co.za> Jeff Knupp added the comment: Yes, that was part of the original patch which was incorrectly uploaded. The current patch (2) should be correct wrt get_method. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 22:44:35 2012 From: report at bugs.python.org (Ross Lagerwall) Date: Mon, 20 Aug 2012 20:44:35 +0000 Subject: [issue15739] Python crashes with "Bus error: 10" In-Reply-To: <1345470434.58.0.741490128779.issue15739@psf.upfronthosting.co.za> Message-ID: <1345495475.5.0.246667969685.issue15739@psf.upfronthosting.co.za> Ross Lagerwall added the comment: Sorry, I didn't mean that it's impossible; I meant that it shouldn't happen and it should be fixed :-) Unfortunately I don't have access to an OS X box to test. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 22:46:47 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 Aug 2012 20:46:47 +0000 Subject: [issue15743] test_urllib2/test_urllib use deprecated urllib.Request methods In-Reply-To: <1345492719.87.0.291856407657.issue15743@psf.upfronthosting.co.za> Message-ID: <3X16W51dgNzQPn@mail.python.org> Roundup Robot added the comment: New changeset 9b28dff66ac3 by Senthil Kumaran in branch 'default': Fix Issue 15743 - improve urllib tests by removing deprecated method usages. Patch by Jeff Knupp. http://hg.python.org/cpython/rev/9b28dff66ac3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 22:54:30 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 20 Aug 2012 20:54:30 +0000 Subject: [issue15739] Python crashes with "Bus error: 10" In-Reply-To: <1345486973.55.0.992195821671.issue15739@psf.upfronthosting.co.za> Message-ID: <540975F0-B590-45CC-A143-5829C5640CA4@mac.com> Ronald Oussoren added the comment: The bug report mentions python 2.7.1. Could you try to reproduce using the most recent release, or a fresh checkout? The reason I ask this is that the crash report has a deeply nested call stack and there used to be a bug where new threads were created with a too small stack. BTW. Python 2.6 is in security fix only mode. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 23:20:41 2012 From: report at bugs.python.org (Sandro Tosi) Date: Mon, 20 Aug 2012 21:20:41 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1345497641.51.0.612936326923.issue14468@psf.upfronthosting.co.za> Sandro Tosi added the comment: Hi Ezio, thanks for the review: how about this new version of the patch? I've left the more "verbose" version in the 3.2 example, while used the more compact way for the 2.7 . Re first committing to 2.7 then 3.2 and then merge, that would work for doc patches, but probably what happens most of the time is the commit in 3.2 and merge on default, which should be covered. Any other comments? ---------- Added file: http://bugs.python.org/file26937/issue14468-v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 23:37:57 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 20 Aug 2012 21:37:57 +0000 Subject: [issue15645] 2to3 Grammar pickles not created when upgrading to 3.3.0b2 In-Reply-To: <1344932180.41.0.826216341416.issue15645@psf.upfronthosting.co.za> Message-ID: <1345498677.61.0.143908721065.issue15645@psf.upfronthosting.co.za> Terry J. Reedy added the comment: If necessary, ask on pydev. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 20 23:40:58 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 20 Aug 2012 21:40:58 +0000 Subject: [issue13799] Base 16 should be hexadecimal in Unicode HOWTO In-Reply-To: <1326718246.49.0.980962494093.issue13799@psf.upfronthosting.co.za> Message-ID: <1345498858.15.0.804288920886.issue13799@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- resolution: -> rejected stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 00:00:53 2012 From: report at bugs.python.org (Ethan Furman) Date: Mon, 20 Aug 2012 22:00:53 +0000 Subject: [issue15209] Re-raising exceptions from an expression In-Reply-To: <1340821665.84.0.121596566188.issue15209@psf.upfronthosting.co.za> Message-ID: <1345500053.51.0.047755329065.issue15209@psf.upfronthosting.co.za> Ethan Furman added the comment: Any problems with the current doc patch? If not, can it be applied before RC1? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 00:01:51 2012 From: report at bugs.python.org (Ethan Furman) Date: Mon, 20 Aug 2012 22:01:51 +0000 Subject: [issue14954] weakref doc clarification In-Reply-To: <1338307482.44.0.878689614277.issue14954@psf.upfronthosting.co.za> Message-ID: <1345500111.62.0.773033533257.issue14954@psf.upfronthosting.co.za> Ethan Furman added the comment: Any problems with the current doc patch? If not, can it be applied before RC1? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 00:02:31 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 Aug 2012 22:02:31 +0000 Subject: [issue12415] Missing: How to checkout the Doc sources In-Reply-To: <1309069778.19.0.06342861361.issue12415@psf.upfronthosting.co.za> Message-ID: <3X18Bd60bHzQ8j@mail.python.org> Roundup Robot added the comment: New changeset e0d68c73e351 by Sandro Tosi in branch 'default': Issue #12415: describe where the documentation files are (patch by ?ric Araujo) http://hg.python.org/devguide/rev/e0d68c73e351 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 00:02:54 2012 From: report at bugs.python.org (Ethan Furman) Date: Mon, 20 Aug 2012 22:02:54 +0000 Subject: [issue14617] confusing docs with regard to __hash__ In-Reply-To: <1334771728.14.0.513778784524.issue14617@psf.upfronthosting.co.za> Message-ID: <1345500174.82.0.0160235989058.issue14617@psf.upfronthosting.co.za> Ethan Furman added the comment: Any problems with the current doc patch? If not, can it be applied before RC1? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 00:04:36 2012 From: report at bugs.python.org (Sandro Tosi) Date: Mon, 20 Aug 2012 22:04:36 +0000 Subject: [issue12415] Missing: How to checkout the Doc sources In-Reply-To: <1309069778.19.0.06342861361.issue12415@psf.upfronthosting.co.za> Message-ID: <1345500276.25.0.883902798082.issue12415@psf.upfronthosting.co.za> Sandro Tosi added the comment: ?ric: I've just committed your patch, with also the latest changes. Philip: In order to be consistent with the way the documentation is compiled on the Python platform, the svn checkout must be used: else if you refer to the upstream website, a contributor can checkout an updated version that will generate a different result. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 00:05:57 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 20 Aug 2012 22:05:57 +0000 Subject: [issue15744] missing tests for {RawIO,BufferedIO,TextIO}.writelines Message-ID: <1345500357.29.0.226025015503.issue15744@psf.upfronthosting.co.za> New submission from Antoine Pitrou: The writelines() method of I/O objects has almost no tests in test_fileio / test_io (and a couple of them in test_file). ---------- components: IO, Tests messages: 168709 nosy: pitrou priority: normal severity: normal stage: needs patch status: open title: missing tests for {RawIO,BufferedIO,TextIO}.writelines type: behavior versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 00:06:25 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 20 Aug 2012 22:06:25 +0000 Subject: [issue14617] confusing docs with regard to __hash__ In-Reply-To: <1334771728.14.0.513778784524.issue14617@psf.upfronthosting.co.za> Message-ID: <1345500385.93.0.444538589367.issue14617@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 00:11:08 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 Aug 2012 22:11:08 +0000 Subject: [issue14954] weakref doc clarification In-Reply-To: <1338307482.44.0.878689614277.issue14954@psf.upfronthosting.co.za> Message-ID: <3X18Nh5rpQzQ8j@mail.python.org> Roundup Robot added the comment: New changeset 8600ae913b63 by Antoine Pitrou in branch '3.2': Issue #14954: Clarify the interaction of weak references and garbage collection. http://hg.python.org/cpython/rev/8600ae913b63 New changeset 57c9ed276332 by Antoine Pitrou in branch 'default': Issue #14954: Clarify the interaction of weak references and garbage collection. http://hg.python.org/cpython/rev/57c9ed276332 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 00:13:26 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 20 Aug 2012 22:13:26 +0000 Subject: [issue14954] weakref doc clarification In-Reply-To: <1338307482.44.0.878689614277.issue14954@psf.upfronthosting.co.za> Message-ID: <1345500806.09.0.23104057738.issue14954@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This is good, thank you. ---------- nosy: +pitrou resolution: -> fixed stage: -> committed/rejected status: open -> closed versions: +Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 00:22:02 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 20 Aug 2012 22:22:02 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1345501322.77.0.246876852184.issue14468@psf.upfronthosting.co.za> Chris Jerdonek added the comment: It might be worth mentioning and/or linking to some of the branching tips discussed in the FAQ. For example, using `hg share` instead of `hg clone` eliminates the need to pull between repositories/working directories: http://docs.python.org/devguide/faq.html#how-do-i-avoid-repeated-pulls-and-pushes-between-my-local-repositories I didn't know the FAQ had hg workflow tips until a recent discussion on core-mentorship. ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 00:25:02 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 20 Aug 2012 22:25:02 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1345501502.16.0.923180055157.issue14468@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Sandro, I find your patch is really a regression: -* Then clone it to create another local repository which is then used to - checkout branch 3.2:: +* Then clone it to create another local repository for the 3.2 branch:: This makes the terminology ambiguous. The old sentence is worded exaclty like that, because it is important to make the distinction between repository and working copy contents. You do *not* create a repository for a single branch; instead you clone the *whole* repository and then checkout the desired branch. If you don't distinguish the concepts clearly, hg beginners will get a wrong idea of what happens. + (this command is equivalent to those used to create a local 3.2 branch, but + it's more concise.) This is wrong too. You *don't* create a local 3.2 branch, you checkout the existing 3.2 branch. This is totally different. +you have a patch that should also be applied to Python 3.2. To properly port +the patch to both versions of Python, you should first apply the patch to +Python 3.2:: Please replace "apply the patch to Python 3.2" with "apply the patch to the 3.2 branch". +With the patch now committed, you want to merge the patch up into Python 3.3. a.k.a in the default branch. +This will push changes in both the Python 3.2 and Python 3.3 branches to +hg.python.org. I would prefer "the 3.2 and default branches". +The import is +possible because changesets are unique per repository, and so in ``py2.7`` you +also have all of those of the other branches. I find the wording of this sentence confusing and I don't think it brings any useful information. (yes, changeset ids are unique, this is a property of Mercurial and doesn't deserve mentioning specifically here) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 00:27:01 2012 From: report at bugs.python.org (Sandro Tosi) Date: Mon, 20 Aug 2012 22:27:01 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1345501621.91.0.683574974439.issue14468@psf.upfronthosting.co.za> Sandro Tosi added the comment: I think the aim of that part of the devguide is to give one clear, simple, working way to operate on different branches at the same time. Additional workflows can be presented, but probably in another place (like the FAQ indeed). What others thing about this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 00:51:24 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 20 Aug 2012 22:51:24 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1345503084.72.0.621777710458.issue14468@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > I think the aim of that part of the devguide is to give one clear, simple, working way to operate on different branches at the same time. The change can be as simple as adding a sentence along the lines of, "Also see the version control section of the FAQ for some suggestions for alternative workflows." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 01:04:14 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 20 Aug 2012 23:04:14 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1345503854.35.0.318433343062.issue14468@psf.upfronthosting.co.za> Ezio Melotti added the comment: You could mention "hg out" where you talk about pushing all the changes. About hg graft, I would assume that most of the patches grafted from 3.x don't work right away on 2.7, or if the graft work the code might still need to be changed. How do you deal with this situation? Is there a --no-commit option for graft? (I haven't used graft yet) > Re first committing to 2.7 then 3.2 and then merge FWIW now that 2.7 is "getting old" I agree that committing on 3.x first and possibly backporting to 2.7 later is more common. > Any other comments? [Disclaimer: This is not directly related to your patch but about other things mentioned in the same page. Here I'm describing my workflow, it might or might not be better than the one suggested by the devguide, but if it is feel free to include the relevant bits in the patch] That page suggest to push from e.g. 3.2 to py3k. I usually do the opposite, i.e. I always pull the 3.2 changes in py3k. I guess it's just a matter of preferences, but iiuc if you push and there's a conflict the push will fail, whereas the pull will usually work better. Not using push myself I can't tell how often that happens and if that's a problem at all. I also have all the clones configured to pull and push from h.p.o. As soon as I "enter" a clone I "hg pull -u" the changes from h.p.o, and if I have to pull some local changesets too I also "hg pull -u ../py3.2". When I'm done I "hg push" from py3k (or sometimes from 2.7, if the changes don't apply to 3.x). I also "hg pull -u" just before committing, in case someone pushed something in the meanwhile. This means that: * I don't have to chain-pulling following 2.7<-3.2<-default, and thus I don't need the "simple script" suggested by the devguide; * If I have uncommitted changes in one of the clone, I can deal with them one by one, and not when I run some scripts that tries to update everything at once; * I download the same changes from h.p.o 2-3 times; * I have to do a bit more typing; This can be summarized with: $ cd py32 $ hg pull -u $ hg import --no-c patch.diff $ # review, run tests, etc. $ hg ci -m '...' $ cd ../py3k $ hg pull -u $ hg pull -u ../3.2 $ hg merge 3.2 $ # solve conflicts, run tests, etc. $ hg ci -m '...' $ hg push ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 01:14:51 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 20 Aug 2012 23:14:51 +0000 Subject: [issue15733] PEP 3121, 384 Refactoring applied to winapi module In-Reply-To: <1345455591.0.0.532625871045.issue15733@psf.upfronthosting.co.za> Message-ID: <1345504491.93.0.117932954584.issue15733@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > In addition, I plan to actively drop Windows 2000 support post 3.3, so > CancelIO can be presumed to be present. The function at issue is CancelIoEx() (introduced in Vista) not CancelIo(). I assume WinXP will still be supported? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 01:39:18 2012 From: report at bugs.python.org (Stephen M McQuay) Date: Mon, 20 Aug 2012 23:39:18 +0000 Subject: [issue9762] PEP 3149 related build failures In-Reply-To: <1283542817.2.0.95523590272.issue9762@psf.upfronthosting.co.za> Message-ID: <1345505958.34.0.197339793308.issue9762@psf.upfronthosting.co.za> Stephen M McQuay added the comment: I cobbled together a mix of what I found here: http://ubuntuforums.org/showthread.php?t=1976837 http://blog.schmichael.com/2012/05/29/building-python-2-6-8-on-ubuntu-12-04/ and got python 2.6 to build fine on modern Ubuntu : % python -mplatform Linux-3.2.0-29-generic-x86_64-with-Ubuntu-12.04-precise ---------- hgrepos: +146 keywords: +patch nosy: +stephen.mcquay Added file: http://bugs.python.org/file26938/py26-fix.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 02:15:57 2012 From: report at bugs.python.org (aliles) Date: Tue, 21 Aug 2012 00:15:57 +0000 Subject: [issue7741] Allow multiple statements in code.InteractiveConsole.push In-Reply-To: <1263912723.35.0.93131684665.issue7741@psf.upfronthosting.co.za> Message-ID: <1345508157.84.0.163276124669.issue7741@psf.upfronthosting.co.za> aliles added the comment: Patch option 1 of 2. Incorporates Kristjan's patch and adds unit tests. This has the side effect of changing InteractiveConsole's behaviour with respect to displayhook(). I'm unsure if this is desirable. ---------- nosy: +aliles Added file: http://bugs.python.org/file26939/issue7741_x.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 02:18:27 2012 From: report at bugs.python.org (aliles) Date: Tue, 21 Aug 2012 00:18:27 +0000 Subject: [issue7741] Allow multiple statements in code.InteractiveConsole.push In-Reply-To: <1263912723.35.0.93131684665.issue7741@psf.upfronthosting.co.za> Message-ID: <1345508307.27.0.245704667035.issue7741@psf.upfronthosting.co.za> aliles added the comment: Patch option 2 of 2. Alternative patch that adds a new method to InteractiveConsole to split the string into multiple lines, feeding each line to interpreter using push(). This doesn't change the behaviour regarding the displayhook. But this may not meet Kristjan's original goals. ---------- Added file: http://bugs.python.org/file26940/issue7741_y.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 02:21:43 2012 From: report at bugs.python.org (aliles) Date: Tue, 21 Aug 2012 00:21:43 +0000 Subject: [issue7741] Allow multiple statements in code.InteractiveConsole.push In-Reply-To: <1263912723.35.0.93131684665.issue7741@psf.upfronthosting.co.za> Message-ID: <1345508503.96.0.587738401406.issue7741@psf.upfronthosting.co.za> aliles added the comment: A quick note regarding the last two patches submitted. These patches add unit tests using the test suite added for Issue #12643. This limits the patches suitable to Python 3.3 and up. ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 02:26:03 2012 From: report at bugs.python.org (aliles) Date: Tue, 21 Aug 2012 00:26:03 +0000 Subject: [issue1228112] code.py use sys.excepthook to display exceptions Message-ID: <1345508763.18.0.0974471350735.issue1228112@psf.upfronthosting.co.za> aliles added the comment: Has this issue been resolved by issue been resolved by #12643, which has been merged for Python 3.3? ---------- nosy: +aliles, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 02:50:36 2012 From: report at bugs.python.org (aliles) Date: Tue, 21 Aug 2012 00:50:36 +0000 Subject: [issue14563] Segmentation fault on ctypes.Structure subclass with byte string field names In-Reply-To: <1334236262.62.0.0349212060005.issue14563@psf.upfronthosting.co.za> Message-ID: <1345510236.27.0.339571228581.issue14563@psf.upfronthosting.co.za> aliles added the comment: Tested with Python 3.3b2 built from trunk. This issue is resolved. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 02:57:30 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 21 Aug 2012 00:57:30 +0000 Subject: [issue15740] test_ssl failure when cacert.org CA cert in system keychain on OSX In-Reply-To: <1345472699.98.0.29406283833.issue15740@psf.upfronthosting.co.za> Message-ID: <1345510650.33.0.71528382994.issue15740@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > The failure seems to occur because the test assumes that the OpenSSL > library either won't load a CA list at all when ca_cert is not > specified, or that the default CA list doesn't contain the cacert.org one. Well, OpenSSL should not implicitly load a CA list when not asked to. If it does, it means Apple hacked their OpenSSL copy. (I am further surprised that Apple includes cacert by default in the trusted certificates, while mainstream browsers like Firefox don't) ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 03:13:42 2012 From: report at bugs.python.org (Trent Nelson) Date: Tue, 21 Aug 2012 01:13:42 +0000 Subject: [issue15285] test_timeout failure when system on IPv4 10.x.x.x subnet In-Reply-To: <1341678423.78.0.865179228191.issue15285@psf.upfronthosting.co.za> Message-ID: <1345511622.22.0.520755406586.issue15285@psf.upfronthosting.co.za> Changes by Trent Nelson : ---------- assignee: -> trent _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 03:19:37 2012 From: report at bugs.python.org (Miki Tebeka) Date: Tue, 21 Aug 2012 01:19:37 +0000 Subject: [issue1228112] code.py use sys.excepthook to display exceptions Message-ID: <1345511977.05.0.232395531875.issue1228112@psf.upfronthosting.co.za> Miki Tebeka added the comment: Seems like #12643 did solve this. Closing. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 03:41:42 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 21 Aug 2012 01:41:42 +0000 Subject: [issue15285] test_timeout failure when system on IPv4 10.x.x.x subnet In-Reply-To: <1341678423.78.0.865179228191.issue15285@psf.upfronthosting.co.za> Message-ID: <3X1F3X5BVtzQQs@mail.python.org> Roundup Robot added the comment: New changeset 9c22222af1f9 by Trent Nelson in branch '3.2': Issue #15285: Refactor connect timeout test in test_timeout. http://hg.python.org/cpython/rev/9c22222af1f9 New changeset b86f3af4746c by Trent Nelson in branch 'default': Issue #15285: Refactor connect timeout test in test_timeout. http://hg.python.org/cpython/rev/b86f3af4746c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 03:45:25 2012 From: report at bugs.python.org (Trent Nelson) Date: Tue, 21 Aug 2012 01:45:25 +0000 Subject: [issue15285] test_timeout failure when system on IPv4 10.x.x.x subnet In-Reply-To: <1341678423.78.0.865179228191.issue15285@psf.upfronthosting.co.za> Message-ID: <1345513524.99.0.492498576009.issue15285@psf.upfronthosting.co.za> Trent Nelson added the comment: Fixed in 3.2: changeset: 78690:9c22222af1f9 branch: 3.2 parent: 78686:8600ae913b63 user: Trent Nelson date: Mon Aug 20 21:22:59 2012 -0400 summary: Issue #15285: Refactor connect timeout test in test_timeout. Fixed in 3.x: changeset: 78691:b86f3af4746c tag: tip parent: 78689:f8eabfed9a1d parent: 78690:9c22222af1f9 user: Trent Nelson date: Mon Aug 20 21:40:21 2012 -0400 summary: Issue #15285: Refactor connect timeout test in test_timeout. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 04:15:55 2012 From: report at bugs.python.org (Trent Nelson) Date: Tue, 21 Aug 2012 02:15:55 +0000 Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS Message-ID: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za> New submission from Trent Nelson: I've got two FreeBSD buildslaves running on ZFS (8.2 and 9.1) experiencing this: ====================================================================== FAIL: test_futimes_ns (test.test_os.StatAttributeTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_os.py", line 369, in test_futimes_ns self._test_utime_ns(futimes_ns, test_dir=False) File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_os.py", line 339, in _test_utime_ns self._test_utime(self.fname, getattr_ns, set_times_ns, ten_s) File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_os.py", line 318, in _test_utime self.assertEqual(attr(st0, "st_mtime"), attr(st1, "st_mtime")) AssertionError: 1345497270884503433 != 1345497270884503000 ====================================================================== FAIL: test_lutimes_ns (test.test_os.StatAttributeTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_os.py", line 362, in test_lutimes_ns self._test_utime_ns(lutimes_ns) File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_os.py", line 339, in _test_utime_ns self._test_utime(self.fname, getattr_ns, set_times_ns, ten_s) File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_os.py", line 318, in _test_utime self.assertEqual(attr(st0, "st_mtime"), attr(st1, "st_mtime")) AssertionError: 1345497270888847634 != 1345497270888847000 ====================================================================== FAIL: test_utime (test.test_os.StatAttributeTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_os.py", line 331, in test_utime self._test_utime(self.fname, getattr, utime, 10) File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_os.py", line 318, in _test_utime self.assertEqual(attr(st0, "st_mtime"), attr(st1, "st_mtime")) AssertionError: 1345497270.8923829 != 1345497270.892382 ====================================================================== FAIL: test_utime_ns (test.test_os.StatAttributeTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_os.py", line 346, in test_utime_ns self._test_utime_ns(utime_ns) File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_os.py", line 339, in _test_utime_ns self._test_utime(self.fname, getattr_ns, set_times_ns, ten_s) File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_os.py", line 318, in _test_utime self.assertEqual(attr(st0, "st_mtime"), attr(st1, "st_mtime")) AssertionError: 1345497270894558518 != 1345497270894558000 I briefly stepped through the test on one of the affected slaves. There's a rounding issue somewhere... I personally think this method is involved: def _test_utime_ns(self, set_times_ns, test_dir=True): def getattr_ns(o, attr): return getattr(o, attr + "_ns") ten_s = 10 * 1000 * 1000 * 1000 self._test_utime(self.fname, getattr_ns, set_times_ns, ten_s) if test_dir: self._test_utime(support.TESTFN, getattr_ns, set_times_ns, ten_s) I didn't have enough time to keep debugging, so I'm raising this as a placeholder until I can pick it back up again. ---------- assignee: trent messages: 168728 nosy: trent priority: normal severity: normal stage: needs patch status: open title: Numerous utime ns tests fail on FreeBSD w/ ZFS type: behavior versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 04:17:52 2012 From: report at bugs.python.org (Trent Nelson) Date: Tue, 21 Aug 2012 02:17:52 +0000 Subject: [issue15746] test_winsound bombing out on 2003 buildslave Message-ID: <1345515472.32.0.153802141999.issue15746@psf.upfronthosting.co.za> New submission from Trent Nelson: The 'Windows Server 2003 R2 SP1' build slave I set up keeps bombing out on test_winsound: ====================================================================== FAIL: test_alias_nofallback (test.test_winsound.PlaySoundTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "E:\Data\buildslave\cpython\2.7.snakebite-win2k3r2sp2-x86\build\lib\test\test_winsound.py", line 199, in test_alias_nofallback '!"$%&/(#+*', winsound.SND_ALIAS | winsound.SND_NODEFAULT AssertionError: RuntimeError not raised Raising this as a placeholder until I can look into it in more detail. ---------- assignee: trent messages: 168729 nosy: trent priority: normal severity: normal status: open title: test_winsound bombing out on 2003 buildslave type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 04:24:16 2012 From: report at bugs.python.org (Trent Nelson) Date: Tue, 21 Aug 2012 02:24:16 +0000 Subject: [issue15747] Various chflags tests failing on FreeBSD/ZFS Message-ID: <1345515856.04.0.888770182553.issue15747@psf.upfronthosting.co.za> New submission from Trent Nelson: Both of my FreeBSD ZFS slaves (8.2 and 9.1) have chflags tests failing as follows: ====================================================================== ERROR: test_chflags (test.test_posix.PosixTester) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/buildslave/cpython/3.2.snakebite-freebsd91-amd64/build/Lib/test/test_posix.py", line 350, in test_chflags self._test_chflags_regular_file(posix.chflags, support.TESTFN) File "/home/buildslave/cpython/3.2.snakebite-freebsd91-amd64/build/Lib/test/test_posix.py", line 337, in _test_chflags_regular_file chflags_func(target_file, st.st_flags | stat.UF_IMMUTABLE) OSError: [Errno 45] Operation not supported: '@test_48794_tmp' ====================================================================== ERROR: test_lchflags_regular_file (test.test_posix.PosixTester) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/buildslave/cpython/3.2.snakebite-freebsd91-amd64/build/Lib/test/test_posix.py", line 354, in test_lchflags_regular_file self._test_chflags_regular_file(posix.lchflags, support.TESTFN) File "/home/buildslave/cpython/3.2.snakebite-freebsd91-amd64/build/Lib/test/test_posix.py", line 337, in _test_chflags_regular_file chflags_func(target_file, st.st_flags | stat.UF_IMMUTABLE) OSError: [Errno 45] Operation not supported: '@test_48794_tmp' ====================================================================== ERROR: test_lchflags_symlink (test.test_posix.PosixTester) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/buildslave/cpython/3.2.snakebite-freebsd91-amd64/build/Lib/test/test_posix.py", line 367, in test_lchflags_symlink dummy_symlink_st.st_flags | stat.UF_IMMUTABLE) OSError: [Errno 45] Operation not supported: '/tmp/@test_48794_tmp-dummy-symlink' ---------------------------------------------------------------------- >From the FreeBSD chflags(1) manual page: The flags are specified as an octal number or a comma separated list of keywords. The following keywords are currently defined: arch, archived set the archived flag (super-user only) opaque set the opaque flag (owner or super-user only) nodump set the nodump flag (owner or super-user only) sappnd, sappend set the system append-only flag (super-user only) schg, schange, simmutable set the system immutable flag (super-user only) sunlnk, sunlink set the system undeletable flag (super-user only) uappnd, uappend set the user append-only flag (owner or super-user only) uchg, uchange, uimmutable set the user immutable flag (owner or super-user only) uunlnk, uunlink set the user undeletable flag (owner or super-user only) That indicates only root can set the immutable flag -- but if this were the case, I wonder why none of the other FreeBSD build slaves have run into it? Either way, placeholder issue until I can spend some more time on it. ---------- assignee: trent components: Tests messages: 168730 nosy: trent priority: normal severity: normal status: open title: Various chflags tests failing on FreeBSD/ZFS type: behavior versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 04:27:18 2012 From: report at bugs.python.org (Trent Nelson) Date: Tue, 21 Aug 2012 02:27:18 +0000 Subject: [issue15748] Various symlink test failures in test_shutil on FreeBSD Message-ID: <1345516038.44.0.114148239105.issue15748@psf.upfronthosting.co.za> New submission from Trent Nelson: FreeBSD slaves are running into this: ====================================================================== ERROR: test_copy2_symlinks (test.test_shutil.TestShutil) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_shutil.py", line 490, in test_copy2_symlinks shutil.copy2(src_link, dst, follow_symlinks=False) File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/shutil.py", line 237, in copy2 copyfile(src, dst, follow_symlinks=follow_symlinks) File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/shutil.py", line 107, in copyfile os.symlink(os.readlink(src), dst) TypeError: embedded NUL character ====================================================================== ERROR: test_copy_symlinks (test.test_shutil.TestShutil) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_shutil.py", line 463, in test_copy_symlinks shutil.copy(src_link, dst, follow_symlinks=False) File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/shutil.py", line 221, in copy copyfile(src, dst, follow_symlinks=follow_symlinks) File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/shutil.py", line 107, in copyfile os.symlink(os.readlink(src), dst) TypeError: embedded NUL character ====================================================================== FAIL: test_copytree_symlinks (test.test_shutil.TestShutil) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_shutil.py", line 606, in test_copytree_symlinks os.path.join(src_dir, 'file.txt')) AssertionError: '/tmp/tmpqlihz5/src/file.' != '/tmp/tmpqlihz5/src/file.txt' - /tmp/tmpqlihz5/src/file. + /tmp/tmpqlihz5/src/file.txt ? +++ Haven't had time to debug it any further yet. Have no clue what's going on either just from a cursory look at the error messages. Not sure if it's ZFS related like the other FreeBSD issues. ---------- assignee: trent components: Tests messages: 168731 nosy: trent priority: normal severity: normal status: open title: Various symlink test failures in test_shutil on FreeBSD type: behavior versions: Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 05:05:36 2012 From: report at bugs.python.org (Ned Deily) Date: Tue, 21 Aug 2012 03:05:36 +0000 Subject: [issue15739] Python crashes with "Bus error: 10" In-Reply-To: <1345470434.58.0.741490128779.issue15739@psf.upfronthosting.co.za> Message-ID: <1345518336.13.0.392690080448.issue15739@psf.upfronthosting.co.za> Ned Deily added the comment: I believe the issue Ronald is referring to is Issue9670. I tried your test program with a current MacPorts Python 2.7.3 and Django 1.4 and, as Ross saw, it failed gracefully with a "maximum recursion depth exceeded while calling a Python object" exception. Note in that issue there is currently no perfect fix for this: we've had to heuristically adjust the maximum default stack size based on experience with different compilers and trying not to unnecessarily increase memory usage for pathological cases. The last adjustment was released in 2.7.2, so presumably not in the compiler used for the Apple-supplied Python 2.7.1 in Lion. I'm going to close this as a duplicate of #9670. Feel free to reopen if the problem can be reproduced with a current 2.7.3 or if someone has a better long-term solution. ---------- nosy: +ned.deily resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> Exceed Recursion Limit in Thread _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 05:08:24 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 21 Aug 2012 03:08:24 +0000 Subject: [issue12834] memoryview.to_bytes() and PyBuffer_ToContiguous() incorrect for non-contiguous arrays In-Reply-To: <1314211505.01.0.756597830367.issue12834@psf.upfronthosting.co.za> Message-ID: <1345518504.05.0.850333608931.issue12834@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 05:11:42 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 21 Aug 2012 03:11:42 +0000 Subject: [issue14130] memoryview: add multi-dimensional indexing and slicing In-Reply-To: <1330259007.41.0.197339877072.issue14130@psf.upfronthosting.co.za> Message-ID: <1345518702.24.0.811421628947.issue14130@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 05:14:59 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 21 Aug 2012 03:14:59 +0000 Subject: [issue3132] implement PEP 3118 struct changes In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za> Message-ID: <1345518899.68.0.281579373369.issue3132@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- nosy: +belopolsky -Alexander.Belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 05:45:29 2012 From: report at bugs.python.org (Ned Deily) Date: Tue, 21 Aug 2012 03:45:29 +0000 Subject: [issue15740] test_ssl failure when cacert.org CA cert in system keychain on OSX In-Reply-To: <1345472699.98.0.29406283833.issue15740@psf.upfronthosting.co.za> Message-ID: <1345520729.58.0.264547014487.issue15740@psf.upfronthosting.co.za> Ned Deily added the comment: As Ronald is aware, there is also the issue that Apple has deprecated use of OpenSSL in OS X: "Although OpenSSL is commonly used in the open source community, OpenSSL does not provide a stable API from version to version. For this reason, although OS X provides OpenSSL libraries, the OpenSSL libraries in OS X are deprecated, and OpenSSL has never been provided as part of iOS. Use of the OS X OpenSSL libraries by applications is strongly discouraged. If your application depends on OpenSSL, you should compile OpenSSL yourself and statically link a known version of OpenSSL into your application." In OS X 10.7, for instance, OpenSSL is at 0.9.8r. I think the same is true for 10.8. We should probably bite the bullet here and do as Apple urges, that is, supply our own libssl 1.0.x for the python.org OS X installer builds. http://developer.apple.com/library/mac/#documentation/security/Conceptual/cryptoservices/GeneralPurposeCrypto/GeneralPurposeCrypto.html ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 06:34:24 2012 From: report at bugs.python.org (Apple Grew) Date: Tue, 21 Aug 2012 04:34:24 +0000 Subject: [issue15739] Python crashes with "Bus error: 10" In-Reply-To: <1345470434.58.0.741490128779.issue15739@psf.upfronthosting.co.za> Message-ID: <1345523664.23.0.456224321444.issue15739@psf.upfronthosting.co.za> Apple Grew added the comment: Thanks. I tested with 2.7.3 (macport) and it indeed works. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 06:36:35 2012 From: report at bugs.python.org (aliles) Date: Tue, 21 Aug 2012 04:36:35 +0000 Subject: [issue15749] cgitb prints html for text when display disabled. Message-ID: <1345523795.76.0.397222969623.issue15749@psf.upfronthosting.co.za> New submission from aliles: If cgitb has been enabled to format as text but suppress the display, the output is formated as html. (Prefixed with

) >>> gitb.enable(display=0, format='txt') >>> raise ValueError('Oops!')

A problem occurred in a Python script. The patch changes the prefix used when display is suppressed based on whether output is formatted as html or text. Includes unit tests and documentation updates. ---------- components: Library (Lib) files: p1345523495.diff keywords: patch messages: 168735 nosy: aliles, ncoghlan priority: normal severity: normal status: open title: cgitb prints html for text when display disabled. type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file26941/p1345523495.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 06:54:51 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 21 Aug 2012 04:54:51 +0000 Subject: [issue15739] Python crashes with "Bus error: 10" In-Reply-To: <1345470434.58.0.741490128779.issue15739@psf.upfronthosting.co.za> Message-ID: <1345524891.94.0.253103692363.issue15739@psf.upfronthosting.co.za> Ronald Oussoren added the comment: The stack size problem was issue #9670. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 07:00:47 2012 From: report at bugs.python.org (Ned Deily) Date: Tue, 21 Aug 2012 05:00:47 +0000 Subject: [issue15645] 2to3 Grammar pickles not created when upgrading to 3.3.0b2 In-Reply-To: <1344932180.41.0.826216341416.issue15645@psf.upfronthosting.co.za> Message-ID: <1345525247.06.0.855208644955.issue15645@psf.upfronthosting.co.za> Ned Deily added the comment: Patch LGTM and I verified that it does indeed install the pickles properly on both a vanilla Linux build/install and with an OS X framework build/install. (Note that, as expected, previously installed versioned pickles in the install library directory are not removed. They will harmlessly accumulate until you do a clean install or manually remove them.) ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 07:05:42 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 21 Aug 2012 05:05:42 +0000 Subject: [issue15740] test_ssl failure when cacert.org CA cert in system keychain on OSX In-Reply-To: <1345472699.98.0.29406283833.issue15740@psf.upfronthosting.co.za> Message-ID: <1345525542.94.0.61755159878.issue15740@psf.upfronthosting.co.za> Ronald Oussoren added the comment: What's rather annoying is that I cannot find OpenSSL on opensource.apple.com, which means we cannot check if they use patches add functionality that our users would like to have. One such feature is likely keychain integration (that is, use the CA roots from the user and system keychain instead of a CA root store in the file system). I'm not 100% sure that this functionality is actually present, but as _ssl automaticly finds a CA root certificate that I have added to the system keychain gives a pretty clear indication. BTW. It might be worthwhile to investigate if it would be possible to write a version of the _ssl extension that links with Apple frameworks (like CommonCrypto) instead of OpenSSL. There are two obvious reason why this might not work out: Apple's frameworks might not over all functionality needed to implement _ssl (and _hashlib, and the additional code adds maintenance overhead that could be too high. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 07:10:38 2012 From: report at bugs.python.org (Trent Nelson) Date: Tue, 21 Aug 2012 05:10:38 +0000 Subject: [issue15747] Various chflags tests failing on FreeBSD/ZFS In-Reply-To: <1345515856.04.0.888770182553.issue15747@psf.upfronthosting.co.za> Message-ID: <1345525838.37.0.759126637091.issue15747@psf.upfronthosting.co.za> Trent Nelson added the comment: Turns out ZFS doesn't support any of the traditional chflags flags -- it returns EOPNOTSUPP for all of them. Attached patch factors this into the various chflags tests. ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file26942/test_posix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 07:10:46 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 21 Aug 2012 05:10:46 +0000 Subject: [issue15740] test_ssl failure when cacert.org CA cert in system keychain on OSX In-Reply-To: <1345472699.98.0.29406283833.issue15740@psf.upfronthosting.co.za> Message-ID: <1345525846.68.0.983394415547.issue15740@psf.upfronthosting.co.za> Ronald Oussoren added the comment: Antoine: Apple almost certainly has hacked their copy of OpenSSL, they do so for other libraries (including python) as well. Apple does not ship CAcerts root certificate, I've added it to the System Keychain on my machine because I use a number of machines that use CAcert signed certificates. And I've found Apple's copy of the OpenSSL sources: ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 07:15:36 2012 From: report at bugs.python.org (Trent Nelson) Date: Tue, 21 Aug 2012 05:15:36 +0000 Subject: [issue15750] test_localtime_daylight_false_dst_true raises OverflowError: mktime argument out of range Message-ID: <1345526136.06.0.661867821529.issue15750@psf.upfronthosting.co.za> New submission from Trent Nelson: On the FreeBSD 8.2 build slave: ====================================================================== ERROR: test_localtime_daylight_false_dst_true (test_utils.LocaltimeTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/buildslave/python/3.x.snakebite-freebsd82-amd64/build/Lib/test/test_email/test_utils.py", line 86, in test_localtime_daylight_false_dst_true t1 = utils.localtime(t0, isdst=1) File "/home/buildslave/python/3.x.snakebite-freebsd82-amd64/build/Lib/email/utils.py", line 397, in localtime seconds = time.mktime(tm) OverflowError: mktime argument out of range ====================================================================== ERROR: test_localtime_daylight_true_dst_true (test_utils.LocaltimeTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/buildslave/python/3.x.snakebite-freebsd82-amd64/build/Lib/test/test_email/test_utils.py", line 79, in test_localtime_daylight_true_dst_true t1 = utils.localtime(t0, isdst=1) File "/home/buildslave/python/3.x.snakebite-freebsd82-amd64/build/Lib/email/utils.py", line 397, in localtime seconds = time.mktime(tm) OverflowError: mktime argument out of range ---------------------------------------------------------------------- Placeholder issue, haven't looked into it in detail yet. ---------- components: Tests messages: 168741 nosy: trent priority: normal severity: normal stage: needs patch status: open title: test_localtime_daylight_false_dst_true raises OverflowError: mktime argument out of range type: behavior versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 07:18:21 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 21 Aug 2012 05:18:21 +0000 Subject: [issue15751] Add PyGILState_SwitchInterpreter Message-ID: <1345526301.75.0.455071650321.issue15751@psf.upfronthosting.co.za> New submission from Nick Coghlan: Currently, modules that use the PyGILState* APIs cannot be used with mod_wsgi, as mod_wsgi uses the subinterpreter support. Graham Dumpleton and I spent some time discussing this at PyCon AU 2012, and we believe that the incompatibility can be resolved with a single API in the core: a function that mod_wsgi can call to set the interpreter used by the GIL state APIs to implicitly create new thread states. This is still only a seed of an idea (and it's entirely possible we've missed something), but it's a place to start in resolving this longstanding incompatibility. ---------- messages: 168742 nosy: ncoghlan priority: normal severity: normal stage: needs patch status: open title: Add PyGILState_SwitchInterpreter type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 07:32:19 2012 From: report at bugs.python.org (Trent Nelson) Date: Tue, 21 Aug 2012 05:32:19 +0000 Subject: [issue15750] test_localtime_daylight_false_dst_true raises OverflowError: mktime argument out of range In-Reply-To: <1345526136.06.0.661867821529.issue15750@psf.upfronthosting.co.za> Message-ID: <1345527139.3.0.960549174178.issue15750@psf.upfronthosting.co.za> Trent Nelson added the comment: Narrowed it down to the following snippet: >>> time.mktime((2012, 3, 12, 1, 1, 0, 0, 72, -1)) 1331514060.0 [70780 refs] >>> time.mktime((2012, 3, 12, 1, 1, 0, 0, 72, 1)) Traceback (most recent call last): File "", line 1, in OverflowError: mktime argument out of range [70832 refs] On all my FreeBSD boxes, that latter invocation always raises an OverflowError. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 07:33:07 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 21 Aug 2012 05:33:07 +0000 Subject: [issue15740] test_ssl failure when cacert.org CA cert in system keychain on OSX In-Reply-To: <1345472699.98.0.29406283833.issue15740@psf.upfronthosting.co.za> Message-ID: <1345527187.26.0.0888290460435.issue15740@psf.upfronthosting.co.za> Ronald Oussoren added the comment: More interesingly are the download archives for OpenSSL098, which is the openssl version that's used on newer OSX releases. Sadly enough the version used on OSX 10.8 is not present there (that seems to be OpenSSL098-47, the latest download is -35). Download link: I've downloaded the most recent release from that link and based on a 5 minute glance at the code this does seem to integrate with the system keychain ("src/crypto/x509/x509_vfy_apple.c" in the source tee) And that code also pointed to a way to disable that functionality, and that resolves the test failure on my machine. Without workaround: $ ./python.exe -m test.regrtest -uall test_ssl [1/1] test_ssl test test_ssl failed -- multiple errors occurred; run in verbose mode for details 1 test failed: test_ssl With workaround: $ env OPENSSL_X509_TEA_DISABLE=1 ./python.exe -m test.regrtest -uall test_ssl [1/1] test_ssl Resource 'ipv6.google.com' is not available Warning -- asyncore.socket_map was modified by test_ssl 1 test altered the execution environment: test_ssl (And test.regrtest -v also shows that all tests passed) The attached (crufty) patch sets the environment variable during test_ssl.NetworkedTests and that also avoids the test failure. It might be useful to add this functionality to the test case (but less crufty, and with a comment that explains why this is done). ---------- Added file: http://bugs.python.org/file26943/issue15740.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 08:31:56 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 21 Aug 2012 06:31:56 +0000 Subject: [issue15736] Crash #2 (constructed overflow) in _PySequence_BytesToCharpArray() In-Reply-To: <1345456530.94.0.929465650961.issue15736@psf.upfronthosting.co.za> Message-ID: <3X1MVP4dSqzQK9@mail.python.org> Roundup Robot added the comment: New changeset dbbf3ccf72e8 by Stefan Krah in branch '3.2': Issue #15736: Fix overflow in _PySequence_BytesToCharpArray(). http://hg.python.org/cpython/rev/dbbf3ccf72e8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 08:37:28 2012 From: report at bugs.python.org (Stefan Krah) Date: Tue, 21 Aug 2012 06:37:28 +0000 Subject: [issue15736] Crash #2 (constructed overflow) in _PySequence_BytesToCharpArray() In-Reply-To: <1345456530.94.0.929465650961.issue15736@psf.upfronthosting.co.za> Message-ID: <1345531048.53.0.717566379813.issue15736@psf.upfronthosting.co.za> Stefan Krah added the comment: I used the cast for gcc >= 4.6 and the assert() as a courtesy to authors of buggy sq_length() functions. Thanks for the comments! ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 08:48:11 2012 From: report at bugs.python.org (Trent Nelson) Date: Tue, 21 Aug 2012 06:48:11 +0000 Subject: [issue15750] test_localtime_daylight_false_dst_true raises OverflowError: mktime argument out of range In-Reply-To: <1345526136.06.0.661867821529.issue15750@psf.upfronthosting.co.za> Message-ID: <1345531691.61.0.215808294291.issue15750@psf.upfronthosting.co.za> Trent Nelson added the comment: All my servers are set to use UTC, which affects how FreeBSD (and other BSDs) treat the isdst param in struct tm in mktime: #include #include #include int main(int argc, char **argv) { struct tm tm1, tm2; time_t t1, t2; memset((void *)&tm1, 0, sizeof(struct tm)); memset((void *)&tm2, 0, sizeof(struct tm)); // UTC setenv("TZ", "UTC", 1); tzset(); tm1.tm_sec = 0; tm1.tm_min = 1; tm1.tm_hour = 1; tm1.tm_mday = 12; tm1.tm_mon = 3; tm1.tm_year = 2012; tm1.tm_wday = -1; tm1.tm_yday = -1; tm1.tm_isdst = 1; t1 = mktime(&tm1); printf("t1 (UTC): %d\n", t1); // EST setenv("TZ", "CET", 1); tzset(); tm2.tm_sec = 0; tm2.tm_min = 1; tm2.tm_hour = 1; tm2.tm_mday = 12; tm2.tm_mon = 3; tm2.tm_year = 2012; tm2.tm_wday = -1; tm2.tm_yday = -1; tm2.tm_isdst = 1; t2 = mktime(&tm2); printf("t2 (CET): %d\n", t2); return 0; } % gcc -g test_mktime.c -o test_time && ./test_time t1 (UTC): -1 t2 (CET): 1162787116 The two tests causing problems are Lib/test/test_email/test_utils.py: def test_localtime_daylight_false_dst_false(self): test.support.patch(self, time, 'daylight', False) t0 = datetime.datetime(2012, 3, 12, 1, 1) t1 = utils.localtime(t0, isdst=-1) t2 = utils.localtime(t1) self.assertEqual(t1, t2) def test_localtime_daylight_true_dst_true(self): test.support.patch(self, time, 'daylight', True) t0 = datetime.datetime(2012, 3, 12, 1, 1) t1 = utils.localtime(t0, isdst=1) t2 = utils.localtime(t1) self.assertEqual(t1, t2) In order for those tests to work on a *BSD server with a TZ set to UTC, TZ is going to need to be set to something else first, and then tzset() called. Otherwise, mktime() will return -1, which triggers the overflow error. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 09:20:33 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 21 Aug 2012 07:20:33 +0000 Subject: [issue13299] namedtuple row factory for sqlite3 In-Reply-To: <1320021145.59.0.53370875256.issue13299@psf.upfronthosting.co.za> Message-ID: <1345533633.7.0.181567811328.issue13299@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Caching based on the cursor going to be problematic because a single cursor can be used multiple times with different descriptions: c = conn.cursor() c.execute('select symbol from stocks') print c.description c.execute('select price from stocks') print c.description # same cursor, different layout, needs a new named tuple It might make more sense to cache the namedtuple() factory itself: sql_namedtuple = lru_cache(maxsize=20)(namedtuple) Also, the example in the docs is too lengthy and indirect. Cut-out the step for creating an populating the database -- just assume db created in the example at the top of the page: For example:: >>> conn.row_factory = sqlite3.NamedTupleRow >>> c = conn.cursor() >>> for record in c.execute('select * from stocks'): print record Row(date='2006-01-05', trans='BUY', symbol='RHAT', qty=100.0, price=35.14) Row(date='2006-01-05', trans='BUY', symbol='RHAT', qty=100, price=35.14) Row(date='2006-03-28', trans='BUY', symbol='IBM', qty=1000, price-45.0) No need to go into a further lesson on how to use named tuples. Also, the patch uses star-unpacking: _namedtuple_row(cursor)(*row) Instead, it should use _make: _namedtuple_row(cursor)._make(row) (u'2006-04-05', u'BUY', u'MSFT', 1000, 72.0) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 09:28:56 2012 From: report at bugs.python.org (Trent Nelson) Date: Tue, 21 Aug 2012 07:28:56 +0000 Subject: [issue15748] Various symlink test failures in test_shutil on FreeBSD In-Reply-To: <1345516038.44.0.114148239105.issue15748@psf.upfronthosting.co.za> Message-ID: <1345534136.96.0.164004654743.issue15748@psf.upfronthosting.co.za> Trent Nelson added the comment: Looks like os.readlink() is busted: > /home/trent/src/cpython/Lib/shutil.py(107)copyfile() -> os.symlink(os.readlink(src), dst) (Pdb) s TypeError: embedded NUL character > /home/trent/src/cpython/Lib/shutil.py(107)copyfile() -> os.symlink(os.readlink(src), dst) (Pdb) os.readlink(src) '/tmp/tmpr3obfj/foo\x00\x00\x00\x00\x00\x00' (Pdb) p src '/tmp/tmpr3obfj/baz' (Pdb) l 102 # XXX What about other special files? (sockets, devices...) 103 if stat.S_ISFIFO(st.st_mode): 104 raise SpecialFileError("`%s` is a named pipe" % fn) 105 106 if not follow_symlinks and os.path.islink(src): 107 -> os.symlink(os.readlink(src), dst) 108 else: 109 with open(src, 'rb') as fsrc: 110 with open(dst, 'wb') as fdst: 111 copyfileobj(fsrc, fdst) 112 return dst > /home/trent/src/cpython/Lib/shutil.py(107)copyfile() -> os.symlink(os.readlink(src), dst) (Pdb) s TypeError: embedded NUL character > /home/trent/src/cpython/Lib/shutil.py(107)copyfile() -> os.symlink(os.readlink(src), dst) (Pdb) os.readlink(src) '/tmp/tmpr3obfj/foo\x00\x00\x00\x00\x00\x00' (Pdb) p src '/tmp/tmpr3obfj/baz' (Pdb) l 102 # XXX What about other special files? (sockets, devices...) 103 if stat.S_ISFIFO(st.st_mode): 104 raise SpecialFileError("`%s` is a named pipe" % fn) 105 106 if not follow_symlinks and os.path.islink(src): 107 -> os.symlink(os.readlink(src), dst) 108 else: 109 with open(src, 'rb') as fsrc: 110 with open(dst, 'wb') as fdst: 111 copyfileobj(fsrc, fdst) 112 return dst i.e.: (Pdb) os.readlink(src) '/tmp/tmpr3obfj/foo\x00\x00\x00\x00\x00\x00' Started another session with gdb, set a breakpoint at posix_readlink: Breakpoint 1, posix_readlink (self=0x800909858, args=0x805ec2840, kwargs=0x0) at ./Modules/posixmodule.c:7007 7007 int dir_fd = DEFAULT_DIR_FD; (gdb) l 7002 7003 static PyObject * 7004 posix_readlink(PyObject *self, PyObject *args, PyObject *kwargs) 7005 { 7006 path_t path; 7007 int dir_fd = DEFAULT_DIR_FD; 7008 char buffer[MAXPATHLEN]; 7009 ssize_t length; 7010 PyObject *return_value = NULL; 7011 static char *keywords[] = {"path", "dir_fd", NULL}; (gdb) n 7013 memset(&path, 0, sizeof(path)); (gdb) 7014 if (!PyArg_ParseTupleAndKeywords(args, kwargs, "O&|$O&:readlink", keywords, (gdb) 7024 Py_BEGIN_ALLOW_THREADS (gdb) 7026 if (dir_fd != DEFAULT_DIR_FD) (gdb) p path $1 = {function_name = 0x0, argument_name = 0x0, nullable = 0, allow_fd = 0, wide = 0x0, narrow = 0x805ec0f10 "/tmp/tmpko8vo_/baz", fd = -1, length = 18, object = 0x805e30d60, cleanup = 0x805ec0ee0} path.narrow and length are correct at that point. (gdb) p dir_fd $2 = -100 (gdb) n 7024 Py_BEGIN_ALLOW_THREADS (gdb) n 7026 if (dir_fd != DEFAULT_DIR_FD) (gdb) n 7030 length = readlink(path.narrow, buffer, sizeof(buffer)); (gdb) n 7031 Py_END_ALLOW_THREADS (gdb) p length $3 = 24 (gdb) p sizeof(buffer) $7 = 1024 (gdb) p buffer $9 = "/tmp/tmpko8vo_/foo\000\000\000\000\000\000?\r\001\b\000\000\000\000\000\000\000??????A", '\0' , "??\203\000\b\000\000\000?v???\177\000\000??A", '\0' , "f\023J", '\0' , "??A\000\000\000\000\000\001\000\000\000\000\000\000\000\030u???\177\000\000 u???\177\000\000RCJ\000\000\000\000\000\000\001\000\000\000\000\000\000??A\000\000\000\000\000?v???\177\000\000?(?\005\b\000\000\0000?L\002\b\000\000\000\210N?\005\b\000\000\000\001\000\000\000\000\000\000\000??A\000\000\000\000\000?"... No idea why readlink is returning 24. Need to look into it more. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 10:32:47 2012 From: report at bugs.python.org (Jeff Knupp) Date: Tue, 21 Aug 2012 08:32:47 +0000 Subject: [issue15752] change test_json's use of deprecated unittest function Message-ID: <1345537967.19.0.778134017296.issue15752@psf.upfronthosting.co.za> New submission from Jeff Knupp: patch to test_json to not use assert(Raises)Regexp, which has been deprecated in favor of assert(Raises)Regex. ---------- components: Tests files: json_deprecated.patch keywords: patch messages: 168750 nosy: Jeff.Knupp priority: normal severity: normal status: open title: change test_json's use of deprecated unittest function versions: Python 3.3 Added file: http://bugs.python.org/file26944/json_deprecated.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 10:40:06 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 21 Aug 2012 08:40:06 +0000 Subject: [issue15752] change test_json's use of deprecated unittest function In-Reply-To: <1345537967.19.0.778134017296.issue15752@psf.upfronthosting.co.za> Message-ID: <3X1QLX42jvzQM3@mail.python.org> Roundup Robot added the comment: New changeset 3a02a1f7d069 by Ezio Melotti in branch '3.2': #15752: s/assertRaisesRegexp/assertRaisesRegex/g http://hg.python.org/cpython/rev/3a02a1f7d069 New changeset b36ce0a3a844 by Ezio Melotti in branch 'default': #15752: merge with 3.2. http://hg.python.org/cpython/rev/b36ce0a3a844 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 10:41:00 2012 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 21 Aug 2012 08:41:00 +0000 Subject: [issue15752] change test_json's use of deprecated unittest function In-Reply-To: <1345537967.19.0.778134017296.issue15752@psf.upfronthosting.co.za> Message-ID: <1345538460.91.0.200781799813.issue15752@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the patch! ---------- assignee: -> ezio.melotti nosy: +ezio.melotti resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> enhancement versions: +Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 12:44:00 2012 From: report at bugs.python.org (Ned Deily) Date: Tue, 21 Aug 2012 10:44:00 +0000 Subject: [issue13370] test_ctypes fails when building python with clang In-Reply-To: <1320761474.93.0.268896325495.issue13370@psf.upfronthosting.co.za> Message-ID: <1345545840.55.0.0761166756766.issue13370@psf.upfronthosting.co.za> Ned Deily added the comment: The patch as it stands causes _ctypes build failures when using the 10.4u SDK as in the traditional 10.3+ 32-bit-only installer configuration. Apparently, in ppc-ffi_darwin.c, the skip that the patch removes was because OSCacheControl.h doesn't exist in the 10.4u SDK. It is in the 10.5 SDK and _ctypes.so builds and tests OK on both PPC and i386 with it. --- a/Modules/_ctypes/libffi_osx/powerpc/ppc-ffi_darwin.c +++ b/Modules/_ctypes/libffi_osx/powerpc/ppc-ffi_darwin.c @@ -37,19 +37,10 @@ #include #include -#if 0 #if defined(POWERPC_DARWIN) #include // for sys_icache_invalidate() #endif -#else - -#pragma weak sys_icache_invalidate -extern void sys_icache_invalidate(void *start, size_t len); - -#endif ./Modules/_ctypes/libffi_osx/powerpc/ppc-ffi_darwin.c:41:67: error: libkern/OSCacheControl.h: No such file or directory ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 13:26:09 2012 From: report at bugs.python.org (=?utf-8?q?George-Cristian_B=C3=AErzan?=) Date: Tue, 21 Aug 2012 11:26:09 +0000 Subject: [issue13922] argparse handling multiple "--" in args improperly In-Reply-To: <1328132556.72.0.92385645061.issue13922@psf.upfronthosting.co.za> Message-ID: <1345548369.07.0.801591274252.issue13922@psf.upfronthosting.co.za> George-Cristian B?rzan added the comment: This patch introduced a regression. Before, parse_args would take a tuple as an argument, and in _get_values it was converted to a list via list comprehension, which meant it was working with tuples too. In the current version, that raises an AttributeError, since tuples do not have .remove(). The simplest solution would be to convert arg_strings to a list before calling .remove(). The downside is that it will break silently when you pass it a string, whereas now you get a confusing error message (but, this is the same behavior as before this fix) ---------- nosy: +gcbirzan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 13:38:58 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 21 Aug 2012 11:38:58 +0000 Subject: [issue15750] test_localtime_daylight_false_dst_true raises OverflowError: mktime argument out of range In-Reply-To: <1345526136.06.0.661867821529.issue15750@psf.upfronthosting.co.za> Message-ID: <1345549138.11.0.925378611242.issue15750@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +belopolsky, haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 13:40:18 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 21 Aug 2012 11:40:18 +0000 Subject: [issue15750] test_localtime_daylight_false_dst_true raises OverflowError: mktime argument out of range In-Reply-To: <1345526136.06.0.661867821529.issue15750@psf.upfronthosting.co.za> Message-ID: <1345549218.2.0.671020761553.issue15750@psf.upfronthosting.co.za> STINNER Victor added the comment: email.utils.localtime() may reuse the new datetime.datetime.timestamp() method, except that this method doesn't support setting isdst (it is set to -1). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 13:46:56 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 21 Aug 2012 11:46:56 +0000 Subject: [issue15746] test_winsound bombing out on 2003 buildslave In-Reply-To: <1345515472.32.0.153802141999.issue15746@psf.upfronthosting.co.za> Message-ID: <1345549616.0.0.76252811384.issue15746@psf.upfronthosting.co.za> STINNER Victor added the comment: Copy of the test: def test_alias_nofallback(self): if _have_soundcard(): # Note that this is not the same as asserting RuntimeError # will get raised: you cannot convert this to # self.assertRaises(...) form. The attempt may or may not # raise RuntimeError, but it shouldn't raise anything other # than RuntimeError, and that's all we're trying to test # here. The MS docs aren't clear about whether the SDK # PlaySound() with SND_ALIAS and SND_NODEFAULT will return # True or False when the alias is unknown. On Tim's WinXP # box today, it returns True (no exception is raised). What # we'd really like to test is that no sound is played, but # that requires first wiring an eardrum class into unittest # . try: winsound.PlaySound( '!"$%&/(#+*', winsound.SND_ALIAS | winsound.SND_NODEFAULT ) except RuntimeError: pass else: self.assertRaises( <~~~~ HERE RuntimeError, winsound.PlaySound, '!"$%&/(#+*', winsound.SND_ALIAS | winsound.SND_NODEFAULT ) So according to Lib/test/check_soundcard.vbs, the buildbot has no soundcard. Is this correct? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 13:51:24 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 21 Aug 2012 11:51:24 +0000 Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS In-Reply-To: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za> Message-ID: <1345549884.43.0.282638791358.issue15745@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 13:52:40 2012 From: report at bugs.python.org (James) Date: Tue, 21 Aug 2012 11:52:40 +0000 Subject: [issue15753] No-argument super in method with variable arguments raises SystemError Message-ID: <1345549960.82.0.102703520127.issue15753@psf.upfronthosting.co.za> New submission from James: For example: Python 3.2.2 (default, Feb 10 2012, 09:23:17) [GCC 4.4.5 20110214 (Red Hat 4.4.5-6)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class A: ... def f(*args): ... print(super().__repr__()) ... >>> A().f() Traceback (most recent call last): File "", line 1, in File "", line 3, in f SystemError: super(): no arguments (There is no change in the current development version 3.3.0b2+) I guess that the problem here is related to the fact that the super call makes sense if we call A().f() but not if we call A.f() (which is allowed by the method signature)? I understand that not including self in the signature is almost always bad style, but occasionally it is necessary, for example if you want to allow arbitrary keyword arguments as dict.update does. Also, how come using the no-argument form of super outside a method raises SystemError - isn't that supposed to be for internal errors? ---------- components: Interpreter Core messages: 168757 nosy: james.sanders priority: normal severity: normal status: open title: No-argument super in method with variable arguments raises SystemError type: behavior versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 13:54:57 2012 From: report at bugs.python.org (Steven Bethard) Date: Tue, 21 Aug 2012 11:54:57 +0000 Subject: [issue13922] argparse handling multiple "--" in args improperly In-Reply-To: <1328132556.72.0.92385645061.issue13922@psf.upfronthosting.co.za> Message-ID: <1345550097.95.0.835034356687.issue13922@psf.upfronthosting.co.za> Steven Bethard added the comment: @gcbirzan: Could you please open up a new issue? The current issue is fixed - it's just that the fix caused a new issue. I would say that the `args` parameter was never intended to be anything but a list, so currently there's a documentation bug since that isn't stated explicitly anywhere. (But certainly the tests only test for lists, not any other sequences.) Adding support for stuff other than lists feels more like a feature request, but given that it apparently worked by accident before, I guess we need to treat it as a bug. Probably the fix for that bug needs to have a ton of tests that check whether tuples work in all the various ways that parse_args is used. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 13:56:35 2012 From: report at bugs.python.org (Graham Dumpleton) Date: Tue, 21 Aug 2012 11:56:35 +0000 Subject: [issue15751] Add PyGILState_SwitchInterpreter In-Reply-To: <1345526301.75.0.455071650321.issue15751@psf.upfronthosting.co.za> Message-ID: <1345550195.32.0.618367529475.issue15751@psf.upfronthosting.co.za> Graham Dumpleton added the comment: Just to clarify. One can still tell WSGI applications under mod_wsgi to run in the main interpreter and in that case modules using PyGILState* do work. By default though, sub interpreters are used as noted. The mechanism for forcing use of main interpreter is the directive: WSGIApplicationGroup %{GLOBAL} Some details about this issue can be found in: http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Python_Simplified_GIL_State_API ---------- nosy: +grahamd _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 14:10:05 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 21 Aug 2012 12:10:05 +0000 Subject: [issue15750] test_localtime_daylight_false_dst_true raises OverflowError: mktime argument out of range In-Reply-To: <1345526136.06.0.661867821529.issue15750@psf.upfronthosting.co.za> Message-ID: <1345551005.72.0.29047840902.issue15750@psf.upfronthosting.co.za> R. David Murray added the comment: This is 3.3 only, as those tests and the function they test were only introduced in 3.3. ---------- components: +email nosy: +barry, r.david.murray versions: -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 14:16:26 2012 From: report at bugs.python.org (Russell Sim) Date: Tue, 21 Aug 2012 12:16:26 +0000 Subject: [issue13299] namedtuple row factory for sqlite3 In-Reply-To: <1320021145.59.0.53370875256.issue13299@psf.upfronthosting.co.za> Message-ID: <1345551386.57.0.952468837498.issue13299@psf.upfronthosting.co.za> Russell Sim added the comment: Raymond, Thanks for the comprehensive feedback! It's fantastic! I have updated the patch with most of you feedback... but there was one part that I couldn't follow entirely. I am now using the _make method but I have had to use star unpacking to allow the method to be cached, lru_cache won't allow a key to be a list because they aren't hash-able. ---------- Added file: http://bugs.python.org/file26945/issue_13299.1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 14:28:08 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 21 Aug 2012 12:28:08 +0000 Subject: [issue15753] No-argument super in method with variable arguments raises SystemError In-Reply-To: <1345549960.82.0.102703520127.issue15753@psf.upfronthosting.co.za> Message-ID: <1345552088.26.0.753408672678.issue15753@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 14:35:55 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 21 Aug 2012 12:35:55 +0000 Subject: [issue13299] namedtuple row factory for sqlite3 In-Reply-To: <1320021145.59.0.53370875256.issue13299@psf.upfronthosting.co.za> Message-ID: <1345552555.98.0.120939152521.issue13299@psf.upfronthosting.co.za> Nick Coghlan added the comment: You should be able to just use "tuple(col[0] for col in cursor.description)" instead of the current list comprehension in order to make the argument hashable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 14:49:56 2012 From: report at bugs.python.org (Russell Sim) Date: Tue, 21 Aug 2012 12:49:56 +0000 Subject: [issue13299] namedtuple row factory for sqlite3 In-Reply-To: <1320021145.59.0.53370875256.issue13299@psf.upfronthosting.co.za> Message-ID: <1345553396.26.0.513525060364.issue13299@psf.upfronthosting.co.za> Russell Sim added the comment: Nick, Thanks for the tip. I have removed the star unpacking. ---------- Added file: http://bugs.python.org/file26946/issue_13299.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 14:56:22 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 21 Aug 2012 12:56:22 +0000 Subject: [issue15751] Add PyGILState_SwitchInterpreter In-Reply-To: <1345526301.75.0.455071650321.issue15751@psf.upfronthosting.co.za> Message-ID: <1345553782.35.0.419632681843.issue15751@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > a function that mod_wsgi can call to set the interpreter used by the > GIL state APIs to implicitly create new thread states. How would it work? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 15:00:27 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 21 Aug 2012 13:00:27 +0000 Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS In-Reply-To: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za> Message-ID: <1345554027.65.0.61910005593.issue15745@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 15:02:22 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 21 Aug 2012 13:02:22 +0000 Subject: [issue15740] test_ssl failure when cacert.org CA cert in system keychain on OSX In-Reply-To: <1345472699.98.0.29406283833.issue15740@psf.upfronthosting.co.za> Message-ID: <1345554142.86.0.943250738397.issue15740@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > The attached (crufty) patch sets the environment variable during > test_ssl.NetworkedTests and that also avoids the test failure. It might > be useful to add this functionality to the test case (but less crufty, > and with a comment that explains why this is done). I would prefer it to be done only under OS X platforms. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 15:21:30 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 21 Aug 2012 13:21:30 +0000 Subject: [issue15751] Add PyGILState_SwitchInterpreter In-Reply-To: <1345526301.75.0.455071650321.issue15751@psf.upfronthosting.co.za> Message-ID: <1345555290.19.0.391142883608.issue15751@psf.upfronthosting.co.za> Nick Coghlan added the comment: It would twiddle the autoInterpreterState and autoTLSkey entries in the pystate.c global variables to point to a different subinterpreter. As I understand the situation, mod_wsgi doesn't need arbitrary externally created threads to be able to call back into arbitrary subinterpreters, it just needs to be able to direct externally created threads in a process to a subinterpreter other than the main one. Graham, looking at the current impl - have you experimented with just calling _PyGILState_Init() with the interpreter state and current thread state for the desired subinterpreter to see what happens? I think the new method could just be a cleaner combination of _PyGILState_ReInit and _PyGILState_Init. If I'm right, then calling _PyGILState_Init should convert the current crashes and deadlocks into a relatively less harmful memory leak (since the old entry in the TLS won't get deleted properly). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 15:22:09 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Tue, 21 Aug 2012 13:22:09 +0000 Subject: [issue15526] test_startfile crash on Windows 7 AMD64 In-Reply-To: <1343827804.07.0.425515249327.issue15526@psf.upfronthosting.co.za> Message-ID: <1345555329.04.0.456312429419.issue15526@psf.upfronthosting.co.za> Jeremy Kloth added the comment: Here is the patch implementing option #2 ---------- keywords: +patch nosy: +jkloth Added file: http://bugs.python.org/file26947/test_startfile.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 15:25:51 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 21 Aug 2012 13:25:51 +0000 Subject: [issue15751] Add PyGILState_SwitchInterpreter In-Reply-To: <1345526301.75.0.455071650321.issue15751@psf.upfronthosting.co.za> Message-ID: <1345555551.61.0.96917429017.issue15751@psf.upfronthosting.co.za> Nick Coghlan added the comment: Graham, even better would be if you could try the following combination: _PyGILState_Fini(); _PyGILState_Init(si, st); (where si and st are the interpreter state and thread state for the target subinterpreter) If a new PyGILState_SwitchInterpreter API is going to be able to solve this in 3.4, then I believe those private APIs should be enough to make it possible in *current* versions. If those private APIs *aren't* enough, then I'm missing something and this isn't going to be as easy as I thought. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 15:28:07 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 21 Aug 2012 13:28:07 +0000 Subject: [issue15751] Add PyGILState_SwitchInterpreter In-Reply-To: <1345555290.19.0.391142883608.issue15751@psf.upfronthosting.co.za> Message-ID: <1345555493.3383.2.camel@localhost.localdomain> Antoine Pitrou added the comment: > As I understand the situation, mod_wsgi doesn't need arbitrary > externally created threads to be able to call back into arbitrary > subinterpreters, it just needs to be able to direct externally created > threads in a process to a subinterpreter other than the main one. But how does it know that the right externally created thread will point to the right subinterpreter? The OS is free to schedule threads as it desires. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 15:45:06 2012 From: report at bugs.python.org (Stefan Krah) Date: Tue, 21 Aug 2012 13:45:06 +0000 Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS In-Reply-To: <1345554027.71.0.931334724577.issue15745@psf.upfronthosting.co.za> Message-ID: <20120821134506.GA551@sleipnir.bytereef.org> Stefan Krah added the comment: Looks like a ZFS/nanosecond issue. My FreeBSD buildbot uses FFS and does not have the failures. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 16:06:08 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 21 Aug 2012 14:06:08 +0000 Subject: [issue15751] Add PyGILState_SwitchInterpreter In-Reply-To: <1345526301.75.0.455071650321.issue15751@psf.upfronthosting.co.za> Message-ID: <1345557968.83.0.983343835339.issue15751@psf.upfronthosting.co.za> Nick Coghlan added the comment: Just as they do today, all externally created threads will still go to *one* interpreter when they hit PyGILState_Ensure(). It's just that interpreter won't be the main one. Since the whole point of the PyGILState API is to support threads that don't have a previously created thread state, there's no getting around the requirement to have a single blessed interpreter that handles all externally created threads in a given process. It will be up to mod_wsgi (and any other embedding application that uses the new function) to make sure it calls this at a time when there aren't any existing calls to PyGILState that would be disrupted. (Assuming we can't figure out a locking scheme that *ensures* no such threads are running when the switch occurs) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 16:10:23 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 21 Aug 2012 14:10:23 +0000 Subject: [issue15751] Add PyGILState_SwitchInterpreter In-Reply-To: <1345557968.83.0.983343835339.issue15751@psf.upfronthosting.co.za> Message-ID: <1345558024.3383.3.camel@localhost.localdomain> Antoine Pitrou added the comment: > Just as they do today, all externally created threads will still go to > *one* interpreter when they hit PyGILState_Ensure(). It's just that > interpreter won't be the main one. Uh but how does it solve the issue? (unless you create a mod_wsgi app with only a single worker thread) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 16:16:39 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 21 Aug 2012 14:16:39 +0000 Subject: [issue15637] Segfault reading null VMA (works fine in python 2.x) In-Reply-To: <1344860415.33.0.2201769173.issue15637@psf.upfronthosting.co.za> Message-ID: <1345558599.59.0.822374489851.issue15637@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: The example script has two errors IMO: - XOpenDisplay accepts a char*, but display_url is certainly a unicode string; it should be converted to a bytes string:: xlib.XOpenDisplay(display_url.encode('utf-8')) - XOpenDisplay.restype is not set, so it will be coerced to a C int (and truncated in the case of a 64bit pointer) I strongly suggest to set .argtypes and .restype, to ensure proper type check and conversion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 16:19:19 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 21 Aug 2012 14:19:19 +0000 Subject: [issue15740] test_ssl failure when cacert.org CA cert in system keychain on OSX In-Reply-To: <1345472699.98.0.29406283833.issue15740@psf.upfronthosting.co.za> Message-ID: <1345558759.82.0.825388100923.issue15740@psf.upfronthosting.co.za> Ronald Oussoren added the comment: Attached cleaner version of the test: * use self.addCleanup instead of a tearDown method * add comment that explains why the code is present * setUp method is only active on OSX ---------- Added file: http://bugs.python.org/file26948/issue15740-2.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 16:21:33 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 21 Aug 2012 14:21:33 +0000 Subject: [issue15740] test_ssl failure when cacert.org CA cert in system keychain on OSX In-Reply-To: <1345558759.82.0.825388100923.issue15740@psf.upfronthosting.co.za> Message-ID: <1345558699.3383.5.camel@localhost.localdomain> Antoine Pitrou added the comment: > Attached cleaner version of the test: > > * use self.addCleanup instead of a tearDown method > * add comment that explains why the code is present > * setUp method is only active on OSX Looks good to me, thank you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 16:33:44 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 21 Aug 2012 14:33:44 +0000 Subject: [issue15751] Add PyGILState_SwitchInterpreter In-Reply-To: <1345526301.75.0.455071650321.issue15751@psf.upfronthosting.co.za> Message-ID: <1345559624.38.0.254577276692.issue15751@psf.upfronthosting.co.za> Nick Coghlan added the comment: My understanding of the mod_wsgi architecture is that it uses subinterpreters to maintain a persistent process, while still providing a relatively pristine interpreter state to handle each new request. This means even when you're using multiple processes with a single request handling thread per process, you're running a subinterpreter unless you explicitly configure mod_wsgi to always run in the main interpreter (which, I believe, will result in additional state persistence across requests). The proposed API change can only fix scenarios where *at a given point in time*, *all* PyGILState_Ensure calls should be directed to a particular subinterpreter. The target subinterpreter may change *later*, but there still cannot be two desired targets within the same process at the same time. However, at the moment, PyGILState doesn't even allow that - all externally created threads are handled in the *main* interpreter even if that isn't what the embedding application wants. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 16:36:27 2012 From: report at bugs.python.org (John Taylor) Date: Tue, 21 Aug 2012 14:36:27 +0000 Subject: [issue15754] Traceback message not returning SQLite check constraint details Message-ID: <1345559787.18.0.3645038202.issue15754@psf.upfronthosting.co.za> New submission from John Taylor: According to: http://www.sqlite.org/releaselog/3_7_12.html SQLite has the ability to, "Report the name of specific CHECK constraints that fail." CPython 3.3.0b2 which uses SQLite version 3.7.12 does not report which constraint failed. -- import platform, sqlite3 print("Platform : %s %s" % (platform.python_implementation(),platform.python_version())) print("SQLite : %s" % (sqlite3.sqlite_version)) print() tbl="""\ create table test1 ( db_insert_date timestamp, check( cast(substr(db_insert_date,1,4) as integer) >= 2000 and cast(substr(db_insert_date,1,4) as integer) <= 2025), check( cast(substr(db_insert_date,6,2) as integer) >= 1 and cast(substr(db_insert_date,6,2) as integer) <= 12), check( cast(substr(db_insert_date,9,2) as integer) >= 1 and cast(substr(db_insert_date,9,2) as integer) <= 31) ) """ conn = sqlite3.connect(":memory:") c = conn.cursor() c.execute(tbl) query = "insert into test1 values( ? )" c.execute(query, ("2012-08-20", ) ) conn.commit() # this works c.execute(query, ("2012-18-20", ) ) conn.commit() # returns: sqlite3.IntegrityError: constraint failed (but which constraint?) """ Traceback (most recent call last): File "C:bug.py", line 34, in c.execute(query, ("2012-18-20", ) ) sqlite3.IntegrityError: constraint failed """ ---------- components: Extension Modules messages: 168777 nosy: ghaering, jftuga priority: normal severity: normal status: open title: Traceback message not returning SQLite check constraint details type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 16:41:01 2012 From: report at bugs.python.org (John Taylor) Date: Tue, 21 Aug 2012 14:41:01 +0000 Subject: [issue15754] Traceback message not returning SQLite check constraint details In-Reply-To: <1345559787.18.0.3645038202.issue15754@psf.upfronthosting.co.za> Message-ID: <1345560061.94.0.312266049662.issue15754@psf.upfronthosting.co.za> John Taylor added the comment: When I run this under Windows 7: Platform : CPython 3.3.0b2 SQLite : 3.7.12 Traceback (most recent call last): File "C:bug.py", line 34, in c.execute(query, ("2012-18-20", ) ) sqlite3.IntegrityError: constraint failed ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 16:44:04 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 21 Aug 2012 14:44:04 +0000 Subject: [issue15751] Add PyGILState_SwitchInterpreter In-Reply-To: <1345526301.75.0.455071650321.issue15751@psf.upfronthosting.co.za> Message-ID: <1345560244.0.0.788419040922.issue15751@psf.upfronthosting.co.za> Nick Coghlan added the comment: Sorry, I mischaracterised the way mod_wsgi works slightly. However, my understanding is still that the scope of this particular fix is merely to allow all external threads to be redirected to a different subinterpreter at various times over the life of a process. It does not need to allow different external threads to be redirected to different subinterpreters. (Note: I am assuming that any hooks Apache/mod_wsgi has into external thread creation could already just create an appropriate thread state if that was the desired behaviour. It may be I'm incorrect on this, and what Graham really wants is the ability to change the target interpreter state just for the current thread. However, if that's what he wants, then there's additional background info I need on mod_wsgi and its ability to influence thread creation within a process, because I didn't get the impression on the weekend that that is what he was after) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 16:47:26 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 21 Aug 2012 14:47:26 +0000 Subject: [issue15751] Add PyGILState_SwitchInterpreter In-Reply-To: <1345559624.38.0.254577276692.issue15751@psf.upfronthosting.co.za> Message-ID: <1345560247.3383.9.camel@localhost.localdomain> Antoine Pitrou added the comment: > My understanding of the mod_wsgi architecture is that it uses > subinterpreters to maintain a persistent process, while still > providing a relatively pristine interpreter state to handle each new > request. I don't think that's true. On hg.python.org, the hglookup application keeps a cached mapping of changeset ids to repo URLs, which wouldn't be possible if its interpreter was re-bootstrapped for each new request. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 16:48:45 2012 From: report at bugs.python.org (danblack) Date: Tue, 21 Aug 2012 14:48:45 +0000 Subject: [issue10852] SSL/TLS sni use in smtp, pop, imap, nntp, ftp client libs by default In-Reply-To: <1294375380.08.0.187691378511.issue10852@psf.upfronthosting.co.za> Message-ID: <1345560525.66.0.49541457425.issue10852@psf.upfronthosting.co.za> Changes by danblack : Removed file: http://bugs.python.org/file26918/issue_10852_pop-smtp-imap-nntp.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 16:49:48 2012 From: report at bugs.python.org (danblack) Date: Tue, 21 Aug 2012 14:49:48 +0000 Subject: [issue10852] SSL/TLS sni use in smtp, pop, imap, nntp, ftp client libs by default In-Reply-To: <1294375380.08.0.187691378511.issue10852@psf.upfronthosting.co.za> Message-ID: <1345560588.93.0.679220110972.issue10852@psf.upfronthosting.co.za> danblack added the comment: previous patch had dumb error and even failed test suit. Now fixed. ---------- Added file: http://bugs.python.org/file26949/issue10852-sni.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 16:55:51 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 21 Aug 2012 14:55:51 +0000 Subject: [issue15754] Traceback message not returning SQLite check constraint details In-Reply-To: <1345559787.18.0.3645038202.issue15754@psf.upfronthosting.co.za> Message-ID: <1345560951.94.0.341653797861.issue15754@psf.upfronthosting.co.za> R. David Murray added the comment: This is a new feature (ie: adding support for a new feature of sqlite). Would you like to propose a patch? ---------- nosy: +r.david.murray stage: -> needs patch type: behavior -> enhancement versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 16:55:51 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 21 Aug 2012 14:55:51 +0000 Subject: [issue10852] SSL/TLS sni use in smtp, pop, imap, nntp, ftp client libs by default In-Reply-To: <1294375380.08.0.187691378511.issue10852@psf.upfronthosting.co.za> Message-ID: <1345560951.5.0.724591135751.issue10852@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks for the patch, Daniel. 3.3 is nearing the release candidate phase, so I'm re-targetting to 3.4. I'll take a detailed look soon. (I suppose there's no easy way to write automated tests for this, unfortunately) ---------- stage: -> patch review versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 16:56:46 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 21 Aug 2012 14:56:46 +0000 Subject: [issue10852] SSL/TLS sni use in smtp, pop, imap, nntp, ftp client libs by default In-Reply-To: <1294375380.08.0.187691378511.issue10852@psf.upfronthosting.co.za> Message-ID: <1345561006.5.0.344924889341.issue10852@psf.upfronthosting.co.za> Antoine Pitrou added the comment: By the way, could you sign a contributor agreement? You can find instructions at http://www.python.org/psf/contrib/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 16:56:52 2012 From: report at bugs.python.org (Jody McIntyre) Date: Tue, 21 Aug 2012 14:56:52 +0000 Subject: [issue14452] SysLogHandler sends invalid messages when using unicode In-Reply-To: <1333105941.84.0.159307303218.issue14452@psf.upfronthosting.co.za> Message-ID: <1345561012.81.0.0570061854859.issue14452@psf.upfronthosting.co.za> Changes by Jody McIntyre : ---------- nosy: +scjody _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 16:59:12 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 21 Aug 2012 14:59:12 +0000 Subject: [issue15754] Traceback message not returning SQLite check constraint details In-Reply-To: <1345559787.18.0.3645038202.issue15754@psf.upfronthosting.co.za> Message-ID: <1345561152.9.0.257304735699.issue15754@psf.upfronthosting.co.za> R. David Murray added the comment: Having said this is a feature, since it would only affect the error message, I'm actually open to it as a bug fix. It won't make it into 3.3.0 even if someone proposes a patch, though, given that we are so late in the release process. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 16:59:51 2012 From: report at bugs.python.org (Alberto Milone) Date: Tue, 21 Aug 2012 14:59:51 +0000 Subject: [issue15637] Segfault reading null VMA (works fine in python 2.x) In-Reply-To: <1344860415.33.0.2201769173.issue15637@psf.upfronthosting.co.za> Message-ID: <1345561191.86.0.377845266594.issue15637@psf.upfronthosting.co.za> Alberto Milone added the comment: I can confirm that the suggested changes solve the problem here. Thanks everyone! ---------- resolution: -> invalid _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 17:03:16 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 21 Aug 2012 15:03:16 +0000 Subject: [issue10852] SSL/TLS sni use in smtp, pop, imap, nntp, ftp client libs by default In-Reply-To: <1294375380.08.0.187691378511.issue10852@psf.upfronthosting.co.za> Message-ID: <1345561396.86.0.369121952392.issue10852@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 17:23:56 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 21 Aug 2012 15:23:56 +0000 Subject: [issue15751] Add PyGILState_SwitchInterpreter In-Reply-To: <1345526301.75.0.455071650321.issue15751@psf.upfronthosting.co.za> Message-ID: <1345562636.98.0.452173213175.issue15751@psf.upfronthosting.co.za> Nick Coghlan added the comment: s/slightly/completely/ (I believe my description of the core problem was right, but my description of why that problem exists was wrong - it actually has to do with the way mod_wsgi handles virtual hosts and endpoints) If we expose an official way to switch the destination of the PyGILState APIs, then what it means is that mod_wsgi can, over the lifecycle of a single process in the pool, *switch* the virtual host and WSGI endpoint that process is handling by changing the active interpreter. There are still some extension modules where that won't work (because they create persistent threads that periodically call back into Python, so they may still end up calling back in to the wrong interpreter), but it will allow those that just do callbacks from external worker threads (or other operations that are similarly bound by the lifecycle of a request) to start working properly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 17:43:36 2012 From: report at bugs.python.org (John Taylor) Date: Tue, 21 Aug 2012 15:43:36 +0000 Subject: [issue15754] Traceback message not returning SQLite check constraint details In-Reply-To: <1345559787.18.0.3645038202.issue15754@psf.upfronthosting.co.za> Message-ID: <1345563816.3.0.834306418999.issue15754@psf.upfronthosting.co.za> John Taylor added the comment: I believe patching Python is beyond my programming capability. I would be very interested in seeing this in 3.3.1. How else could I assist in making this happen? Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 17:51:24 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 21 Aug 2012 15:51:24 +0000 Subject: [issue15751] Add PyGILState_SwitchInterpreter In-Reply-To: <1345562636.98.0.452173213175.issue15751@psf.upfronthosting.co.za> Message-ID: <1345564090.3326.1.camel@localhost.localdomain> Antoine Pitrou added the comment: > If we expose an official way to switch the destination of the > PyGILState APIs, then what it means is that mod_wsgi can, over the > lifecycle of a single process in the pool, *switch* the virtual host > and WSGI endpoint that process is handling by changing the active > interpreter. I don't understand what that means. It's the OS which switches threads, including interpreter threads. (by the way, the real fix to the GILState vs. subinterpreters issue would be to create new API functions which take an interpreter as argument, so that you have a distinct TLS key per interpreter) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 18:08:02 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 21 Aug 2012 16:08:02 +0000 Subject: [issue15751] Add PyGILState_SwitchInterpreter In-Reply-To: <1345526301.75.0.455071650321.issue15751@psf.upfronthosting.co.za> Message-ID: <1345565282.5.0.339036185331.issue15751@psf.upfronthosting.co.za> Nick Coghlan added the comment: Umm, no. The whole point of the GILState API is that you can call it from a thread which knows *nothing* about Python. It will then use the *process global* state in the pystate.c statics to initialise that thread with a Python thread state. Currently, that thread state will always be for the main Python interpreter for the process. All Graham wants is an officially supported way to change which interpreter the pystate.c globals reference *without* shutting down and reinitialising Python completely. There are going to be limitations on how effective this will be - it still won't support *all* extension modules that use the PyGILState APIs. It will, however, support many more of them than the status quo (which is zero, unless you force your WSGI app to use the main interpreter, which has its own problems). And you absolutely can control when the OS switches threads - controlling that is what synchronisation primitives are *for*. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 18:08:48 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 21 Aug 2012 16:08:48 +0000 Subject: [issue15754] Traceback message not returning SQLite check constraint details In-Reply-To: <1345559787.18.0.3645038202.issue15754@psf.upfronthosting.co.za> Message-ID: <1345565328.5.0.714640028981.issue15754@psf.upfronthosting.co.za> R. David Murray added the comment: Well, it would be patching the sqlite extension module. Not that that is much different :) Hopefully the current sqlite extension maintainer will think this is worthwhile doing. Short of waiting for that, you could perhaps ask on the python-list email list to see if there is anyone with the requisite skill set interested in contributing a patch. I will mention it on the core-mentorship mailing list, and perhaps someone there will decided to pick it up (there's a pretty decent chance of that, I think). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 18:27:33 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 21 Aug 2012 16:27:33 +0000 Subject: [issue15751] Add PyGILState_SwitchInterpreter In-Reply-To: <1345565282.5.0.339036185331.issue15751@psf.upfronthosting.co.za> Message-ID: <1345566257.3326.17.camel@localhost.localdomain> Antoine Pitrou added the comment: > Umm, no. The whole point of the GILState API is that you can call it > from a thread which knows *nothing* about Python. No to what? Any sane callback API allows to pass it some user data, that user data can just as well include the pointer to the desired interpreter. Really, that's the right way to do it. Since a new API is required, we can indeed add tweaks to the current API until the migration is done, but I'm quite sure any proper solution to the problem requires explicitly passing the interpreter. > There are going to be limitations on how effective this will be - it > still won't support *all* extension modules that use the PyGILState > APIs. It will, however, support many more of them than the status quo I still don't understand how that allows to "support some extension modules" (which ones?). A typical mod_wsgi setup uses several threads per daemon process, and each thread (AFAIU) uses a separate subinterpreter for its WSGI application instance (Graham, is that false?). Therefore, an externally-launched thread can relate to *any* of these subintepreters, which are themselves scheduled by the OS. > And you absolutely can control when the OS switches threads - > controlling that is what synchronisation primitives are *for*. I don't think mod_wsgi has access to enough hooks or information to do that satisfyingly (like the OS would do). Besides, I don't understand how mod_wsgi could have control over the scheduling of externally-launched threads. Therefore, an externally-launched thread could be scheduled at any time, and not only after the "right" interpreter thread was interrupted. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 18:52:55 2012 From: report at bugs.python.org (danblack) Date: Tue, 21 Aug 2012 16:52:55 +0000 Subject: [issue8109] Server-side support for TLS Server Name Indication extension In-Reply-To: <1268234047.5.0.702223567094.issue8109@psf.upfronthosting.co.za> Message-ID: <1345567975.06.0.0363143252565.issue8109@psf.upfronthosting.co.za> danblack added the comment: test_sni not working. getpeercert() not returning a certificate. ---------- keywords: +patch nosy: +daniel-black Added file: http://bugs.python.org/file26950/issue8109_server_side_sni.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 18:53:18 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 21 Aug 2012 16:53:18 +0000 Subject: [issue15754] Traceback message not returning SQLite check constraint details In-Reply-To: <1345559787.18.0.3645038202.issue15754@psf.upfronthosting.co.za> Message-ID: <1345567998.94.0.661342344053.issue15754@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I would be happy to take a look at this and propose a patch. ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 20:08:24 2012 From: report at bugs.python.org (Ned Deily) Date: Tue, 21 Aug 2012 18:08:24 +0000 Subject: [issue15754] Traceback message not returning SQLite check constraint details In-Reply-To: <1345559787.18.0.3645038202.issue15754@psf.upfronthosting.co.za> Message-ID: <1345572504.95.0.865058684872.issue15754@psf.upfronthosting.co.za> Ned Deily added the comment: Keep in mind that Python itself does not release with nor mandate a specific version of sqlite3. When building CPython yourself, it will use what version is found on your system. Distributors of built Pythons, including the python.org Windows and OS X installers, may supply a local version or, in some cases, may link dynamically with an operating system supplied version. So any changes to Python's sqlite3 module and support extension module have to continue to check at either build or run time whether version-specific features are available. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 20:43:34 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Tue, 21 Aug 2012 18:43:34 +0000 Subject: [issue6422] timeit called from within Python should allow autoranging In-Reply-To: <1246806912.2.0.722769600334.issue6422@psf.upfronthosting.co.za> Message-ID: <1345574614.89.0.0102375353468.issue6422@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 20:47:53 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 21 Aug 2012 18:47:53 +0000 Subject: [issue6422] timeit called from within Python should allow autoranging In-Reply-To: <1246806912.2.0.722769600334.issue6422@psf.upfronthosting.co.za> Message-ID: <1345574873.8.0.858323437184.issue6422@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > In #5442, I proposed leaving the architecture of the module alone, and > simply exposing the main module functionality as a high level helper > function: Agreed with Nick's approach above. Victor, if you want to improve timeit's reliability, please open a separate issue. ---------- stage: patch review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 21:15:17 2012 From: report at bugs.python.org (Todd Whiteman) Date: Tue, 21 Aug 2012 19:15:17 +0000 Subject: [issue15756] subprocess.poll() does not handle errno.ECHILD "No child processes" Message-ID: <1345576517.75.0.906463701582.issue15756@psf.upfronthosting.co.za> New submission from Todd Whiteman: In the case of a "errno.ECHILD" exception - Python's subprocess module misses the fact that the process has already ended. The following code will wait indefinitely, even though the launched process is quickly ended: import subprocess, signal signal.signal(signal.SIGCLD, signal.SIG_IGN) p = subprocess.Popen(['echo','foo']) while p.poll() is None: pass # wait for the process to exit Note: This is the exact same issue as issue1731717, but applying to the subprocess.poll() method instead of the subprocess.wait() method. ---------- components: Library (Lib) messages: 168798 nosy: twhitema priority: normal severity: normal status: open title: subprocess.poll() does not handle errno.ECHILD "No child processes" type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 21:15:33 2012 From: report at bugs.python.org (Todd Whiteman) Date: Tue, 21 Aug 2012 19:15:33 +0000 Subject: [issue15756] subprocess.poll() does not handle errno.ECHILD "No child processes" In-Reply-To: <1345576517.75.0.906463701582.issue15756@psf.upfronthosting.co.za> Message-ID: <1345576533.89.0.362896816335.issue15756@psf.upfronthosting.co.za> Changes by Todd Whiteman : ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 21:20:37 2012 From: report at bugs.python.org (Todd Whiteman) Date: Tue, 21 Aug 2012 19:20:37 +0000 Subject: [issue15756] subprocess.poll() does not handle errno.ECHILD "No child processes" In-Reply-To: <1345576517.75.0.906463701582.issue15756@psf.upfronthosting.co.za> Message-ID: <1345576837.17.0.719154103797.issue15756@psf.upfronthosting.co.za> Todd Whiteman added the comment: The attached patch handles errno.ECHILD in the _internal_poll() method and I've updated the existing "sigchild_ignore.py" test file to perform polling as well. An unpatched version of Pyhton would normally hang on this particular test, whilst the patched version will run successfully. ---------- keywords: +patch Added file: http://bugs.python.org/file26951/issue15756_poll_v1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 22:07:27 2012 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 21 Aug 2012 20:07:27 +0000 Subject: [issue10712] 2to3 fixer for deprecated unittest method names In-Reply-To: <1292441796.9.0.018359428873.issue10712@psf.upfronthosting.co.za> Message-ID: <1345579647.88.0.374388778194.issue10712@psf.upfronthosting.co.za> Ezio Melotti added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 22:29:25 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 21 Aug 2012 20:29:25 +0000 Subject: [issue15754] Traceback message not returning SQLite check constraint details In-Reply-To: <1345559787.18.0.3645038202.issue15754@psf.upfronthosting.co.za> Message-ID: <1345580965.18.0.721042457783.issue15754@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I haven't been able to test this via Python because my system sqlite3 version isn't new enough. But I was able to test this against sqlite3 directly. I suspect there may be no issue. John, have you tried naming your constraint? http://www.sqlite.org/syntaxdiagrams.html#column-constraint Specifically, if I try your example in sqlite3 3.7.13 (from the command-line, independent of Python), I get the generic error message: "Error: constraint failed" But if I add "CONSTRAINT name" to your test case SQL, e.g. create table test1 ( db_insert_date timestamp, CONSTRAINT test_constraint1 check(cast(substr(db_insert_date,1,4) as integer) <= 2025), CONSTRAINT test_constraint2 check(cast(substr(db_insert_date,6,2) as integer) <= 12) ); I get the error message "Error: constraint test_constraint2 failed". I suspect things will work fine in Python because the Python code seems simply to use whatever error message sqlite3 provides it: case SQLITE_CONSTRAINT: case SQLITE_MISMATCH: PyErr_SetString(pysqlite_IntegrityError, sqlite3_errmsg(db)); break; (from http://hg.python.org/cpython/file/ca54c27a9045/Modules/_sqlite/util.c#l92 ) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 22:46:02 2012 From: report at bugs.python.org (Georg Brandl) Date: Tue, 21 Aug 2012 20:46:02 +0000 Subject: [issue15748] Various symlink test failures in test_shutil on FreeBSD In-Reply-To: <1345516038.44.0.114148239105.issue15748@psf.upfronthosting.co.za> Message-ID: <1345581962.31.0.750841424306.issue15748@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 22:54:54 2012 From: report at bugs.python.org (John Taylor) Date: Tue, 21 Aug 2012 20:54:54 +0000 Subject: [issue15754] Traceback message not returning SQLite check constraint details In-Reply-To: <1345559787.18.0.3645038202.issue15754@psf.upfronthosting.co.za> Message-ID: <1345582493.99.0.765759263247.issue15754@psf.upfronthosting.co.za> John Taylor added the comment: Chris, I will try naming the constraints and will then follow-up. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 23:23:40 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 21 Aug 2012 21:23:40 +0000 Subject: [issue15637] Segfault reading null VMA (works fine in python 2.x) In-Reply-To: <1344860415.33.0.2201769173.issue15637@psf.upfronthosting.co.za> Message-ID: <1345584220.74.0.654583691509.issue15637@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 23:25:04 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 21 Aug 2012 21:25:04 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1345584304.91.0.402021581193.issue14468@psf.upfronthosting.co.za> ?ric Araujo added the comment: FWIW I agree with Antoine?s comments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 23:28:21 2012 From: report at bugs.python.org (Larry Hastings) Date: Tue, 21 Aug 2012 21:28:21 +0000 Subject: [issue15748] Various symlink test failures in test_shutil on FreeBSD In-Reply-To: <1345516038.44.0.114148239105.issue15748@psf.upfronthosting.co.za> Message-ID: <1345584501.39.0.572389626427.issue15748@psf.upfronthosting.co.za> Larry Hastings added the comment: I'll ask the obvious: was that an optimized build? Not that that explains the bug--but that might explain why "length" appeared to contain 24. It's hard to believe this is really an OS bug... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 23:29:41 2012 From: report at bugs.python.org (Trent Nelson) Date: Tue, 21 Aug 2012 21:29:41 +0000 Subject: [issue15757] ./configure --with-pydebug on FreeBSD results in -O2 -pipe eventually ending up in CFLAGS. Message-ID: <1345584581.07.0.102502771699.issue15757@psf.upfronthosting.co.za> New submission from Trent Nelson: All the FreeBSD build slaves seem to be experiencing the same symptom: ./configure --with-pydebug eventually results in this: gcc -pthread -c -fno-strict-aliasing -g -O0 -Wall -Wstrict-prototypes -O2 -pipe -fno-strict-aliasing -Wall -march=native -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c What I find odd: % grep -e '-O2' Makefile | wc -l 0 There are references to -O2 elsewhere, like in configure.ac|configure, but, the Makefile doesn't source any of those. (Right?) This is occurring on all of my slaves as well as others, so I'm pretty sure it's not just specific to my environment. ---------- assignee: trent messages: 168805 nosy: koobs, skrah, trent priority: normal severity: normal status: open title: ./configure --with-pydebug on FreeBSD results in -O2 -pipe eventually ending up in CFLAGS. type: behavior versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 23:33:00 2012 From: report at bugs.python.org (Trent Nelson) Date: Tue, 21 Aug 2012 21:33:00 +0000 Subject: [issue15748] Various symlink test failures in test_shutil on FreeBSD In-Reply-To: <1345516038.44.0.114148239105.issue15748@psf.upfronthosting.co.za> Message-ID: <1345584780.9.0.08082562245.issue15748@psf.upfronthosting.co.za> Trent Nelson added the comment: Hi Larry, Funnily enough, I just tried to step through a heavily hacked version of posix_readlink again, only to get gdb telling me I couldn't 'print' the variables I had added in. Turns out, `./configure --with-pydebug` on FreeBSD ends up with '-O2' being appended to CFLAGS some how. I've raised a separate issue for this: http://bugs.python.org/issue15748. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 23:34:42 2012 From: report at bugs.python.org (Trent Nelson) Date: Tue, 21 Aug 2012 21:34:42 +0000 Subject: [issue15757] ./configure --with-pydebug on FreeBSD results in -O2 -pipe eventually ending up in CFLAGS. In-Reply-To: <1345584581.07.0.102502771699.issue15757@psf.upfronthosting.co.za> Message-ID: <1345584882.09.0.882333330151.issue15757@psf.upfronthosting.co.za> Trent Nelson added the comment: Ah! % gmake gcc -pthread -c -fno-strict-aliasing -g -O0 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c gcc -pthread -c -fno-strict-aliasing -g -O0 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Parser/acceler.o Parser/acceler.c ^C % make % make gcc -pthread -c -fno-strict-aliasing -g -O0 -Wall -Wstrict-prototypes -O2 -pipe -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c gcc -pthread -c -fno-strict-aliasing -g -O0 -Wall -Wstrict-prototypes -O2 -pipe -I. -I./Include -DPy_BUILD_CORE -o Parser/acceler.o Parser/acceler.c gcc -pthread -c -fno-strict-aliasing -g -O0 -Wall -Wstrict-prototypes -O2 -pipe -I. -I./Include -DPy_BUILD_CORE -o Parser/grammar1.o Parser/grammar1.c ^C So, the default BSD make likes to add in -O2 -pipe. I'll do a bit more digging. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 23:52:05 2012 From: report at bugs.python.org (Larry Hastings) Date: Tue, 21 Aug 2012 21:52:05 +0000 Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS In-Reply-To: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za> Message-ID: <1345585925.75.0.314432895672.issue15745@psf.upfronthosting.co.za> Larry Hastings added the comment: Can you tell me which code path it took? Either by walking through the code as it runs, or by telling me about the preprocessor defines used by utime (HAVE_FUTIMES, HAVE_FUTIMENS, HAVE_FUTIMESAT, HAVE_UTIMENSAT, HAVE_UTIMES, HAVE_UTIME_H). The easy way to do this would be to say from posix import _have_functions print(_have_functions) and paste the result in. Then also tell me if you have a file "utime.h" in either your standard include directory or in the "sys" subdirectory of that directory. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 23:53:01 2012 From: report at bugs.python.org (Alexandre Vassalotti) Date: Tue, 21 Aug 2012 21:53:01 +0000 Subject: [issue15642] Integrate pickle protocol version 4 GSoC work by Stefan Mihaila In-Reply-To: <1344890920.23.0.695633734046.issue15642@psf.upfronthosting.co.za> Message-ID: <1345585981.21.0.331309474363.issue15642@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: Some quick thoughts about the new implicit memoization scheme in Stefan's implementation. - The new scheme will need to be documented in PEP 3154 before we can accept the change. - I don't really like the idea of changing the semantics of the PUT and GET opcodes. I would prefer new opcodes if possible. - I would like to see benchmarks for this change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 21 23:58:20 2012 From: report at bugs.python.org (Trent Nelson) Date: Tue, 21 Aug 2012 21:58:20 +0000 Subject: [issue15757] ./configure --with-pydebug on FreeBSD results in -O2 -pipe eventually ending up in CFLAGS. In-Reply-To: <1345584581.07.0.102502771699.issue15757@psf.upfronthosting.co.za> Message-ID: <1345586300.5.0.087898850836.issue15757@psf.upfronthosting.co.za> Trent Nelson added the comment: So, looks like FreeBSD's /usr/share/mk/sys.mk is to blame here. It unconditionally sets CFLAGS to `-O2 -pipe`. [trent at hydrogen/ttypts/1(~s/cpython)%] uname -a FreeBSD hydrogen.snakebite.net 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0 r0: Mon Jul 16 06:28:19 UTC 2012 root at hydrogen.snakebite.net:/usr/obj/src/freebsd/9/r238513m/sys/AMD64 amd64 [trent at hydrogen/ttypts/1(~s/cpython)%] grep -A3 'bsd_make_test' Makefile bsd_make_test: @echo "CFLAGS: $(CFLAGS)" @echo "EXTRA_CFLAGS: $(EXTRA_CFLAGS)" [trent at hydrogen/ttypts/1(~s/cpython)%] make bsd_make_test CFLAGS: -O2 -pipe EXTRA_CFLAGS: [trent at hydrogen/ttypts/1(~s/cpython)%] make CFLAGS= bsd_make_test CFLAGS: EXTRA_CFLAGS: I can think of a few ways to work around this... some better than others. 1. Change the FreeBSD buildbots to always invoke make via `make CFLAGS=`. 2. Hack configure.* to automatically invoke make via `make CFLAGS=` when `-O2 -pipe` crops up in a `--with-pydebug` build. Some of the less desirable ones: 3. Switch FreeBSD to gmake. 4. Patch FreeBSD make so that it is 'debug aware' and stops appending `-O2` everywhere. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 00:06:05 2012 From: report at bugs.python.org (Trent Nelson) Date: Tue, 21 Aug 2012 22:06:05 +0000 Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS In-Reply-To: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za> Message-ID: <1345586765.77.0.536833714788.issue15745@psf.upfronthosting.co.za> Trent Nelson added the comment: >>> print(_have_functions) ['HAVE_FACCESSAT', 'HAVE_FCHDIR', 'HAVE_FCHMOD', 'HAVE_FCHMODAT', 'HAVE_FCHOWN', 'HAVE_FEXECVE', 'HAVE_FDOPENDIR', 'HAVE_FPATHCONF', 'HAVE_FSTATAT', 'HAVE_FSTATVFS', 'HAVE_FTRUNCATE', 'HAVE_FUTIMES', 'HAVE_FUTIMESAT', 'HAVE_LINKAT', 'HAVE_LCHFLAGS', 'HAVE_LCHMOD', 'HAVE_LCHOWN', 'HAVE_LSTAT', 'HAVE_LUTIMES', 'HAVE_MKDIRAT', 'HAVE_MKFIFOAT', 'HAVE_MKNODAT', 'HAVE_OPENAT', 'HAVE_READLINKAT', 'HAVE_RENAMEAT', 'HAVE_SYMLINKAT', 'HAVE_UNLINKAT'] /usr/include/utime.h exists. FWIW, when I stepped through it a few nights ago, I remember that all the code paths eventually visited the point where the mtime gets converted into a decimal: ====================================================================== FAIL: test_utime (test.test_os.StatAttributeTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_os.py", line 331, in test_utime self._test_utime(self.fname, getattr, utime, 10) File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_os.py", line 318, in _test_utime self.assertEqual(attr(st0, "st_mtime"), attr(st1, "st_mtime")) AssertionError: 1345497270.8923829 != 1345497270.892382 However, for the other errors: AssertionError: 1345497270884503433 != 1345497270884503000 AssertionError: 1345497270888847634 != 1345497270888847000 ....they'd get cast back before the assertEqual test would be done. As for this: 1345497270.8923829 != 1345497270.892382 The trailing 9 is getting lopped off, which results in the rounding errors. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 00:14:32 2012 From: report at bugs.python.org (Graham Dumpleton) Date: Tue, 21 Aug 2012 22:14:32 +0000 Subject: [issue15751] Add PyGILState_SwitchInterpreter In-Reply-To: <1345526301.75.0.455071650321.issue15751@psf.upfronthosting.co.za> Message-ID: <1345587272.98.0.214034944684.issue15751@psf.upfronthosting.co.za> Graham Dumpleton added the comment: In both embedded mode and daemon mode of mod_wsgi, albeit how thread pool is managed is different, there is a fixed number of threads with those being dedicated to handling web requests. On a request arriving next available thread from the thread pool handles accepting of request at C code level, that thread may then map to any WSGI application and so any sub interpreter, or even the main interpreter. Thus there is no one to one mapping between thread and (sub)interpreter. The way the mod_wsgi code works now is that when it knows it will be calling into the main interpreter, it uses PyGILState_Ensure(). If not, it will use a thread state for that thread specific to the sub interpreter it is calling in to. At the end of the request, the thread state is remembered and not thrown away so that thread locals still work for that thread across requests for that sub interpreter. Thus, there can be more than one thread state per thread, but this is fine so long as it is only used against the sub interpreter it was created for. This is actually an enforced requirement of Python, because if you create more than one thread state for a thread for the same sub interpreter, or even an additional one for the main interpreter when there is also the auto TLS, then Python will die if you compile and run it is in debug mode. Now, since mod_wsgi always knows which interpreter it is calling into, the intent was that there was this single API call so that mod_wsgi could say that at this time, this thread is going to be calling into that interpreter. It could then just call PyGILState_Ensure(). Any third party module then which uses the simplistic calling sequence of calling PyGILState_Release() on exiting Python code and thence within the same thread calling PyGILState_Ensure() when coming back into Python with a callback will work, as mod_wsgi has specified the interpreter context for that thread at that time. As pointed out, if a third party module was creating its own background threads at C level and calling PyGILState_Ensure() when calling back into Python code, this could pose a problem. This could also be an issue for Python created background threads. In the case of the latter, if a Python thread is created in a specific sub interpreter, it should automatically designate for that thread that that is its interpreter context, so if it calls out and does the Release/Ensure dance, that it goes back into the same sub interpreter. The C initiated thread is a bit more complicated though and may not be solvable, but a lot of the main third party modules which don't work in sub interpreters, such as lxml, don't use background threads, so the simplistic approach means that will work at least. So, in summary, saw a single API call which allowed designation of which interpreter a thread is operating against, overriding the implicit default of the main interpreter. PyGILState API will need to manage a set of interpreter states for each interpreter, with potential for more than one thread state for a thread due to a thread being able to call into multiple interpreters at different times. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 00:25:10 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 21 Aug 2012 22:25:10 +0000 Subject: [issue15758] 500x speed up for Popen.communicate() on Windows Message-ID: <1345587910.43.0.919180045188.issue15758@psf.upfronthosting.co.za> New submission from Richard Oudkerk: Piping significant amounts of data through a subprocess using Popen.communicate() is crazily slow on Windows. The attached program just pushes data through mingw's cat.exe. Python 3.3: amount = 1 MB; time taken = 0.07 secs; rate = 13.51 MB/s amount = 2 MB; time taken = 0.31 secs; rate = 6.51 MB/s amount = 4 MB; time taken = 1.30 secs; rate = 3.08 MB/s amount = 8 MB; time taken = 5.43 secs; rate = 1.47 MB/s amount = 16 MB; time taken = 21.64 secs; rate = 0.74 MB/s amount = 32 MB; time taken = 87.36 secs; rate = 0.37 MB/s Python 2.7: amount = 1 MB; time taken = 0.02 secs; rate = 66.67 MB/s amount = 2 MB; time taken = 0.03 secs; rate = 68.97 MB/s amount = 4 MB; time taken = 0.05 secs; rate = 76.92 MB/s amount = 8 MB; time taken = 0.10 secs; rate = 82.47 MB/s amount = 16 MB; time taken = 0.27 secs; rate = 60.38 MB/s amount = 32 MB; time taken = 0.88 secs; rate = 36.36 MB/s amount = 64 MB; time taken = 3.20 secs; rate = 20.03 MB/s amount = 128 MB; time taken = 12.36 secs; rate = 10.35 MB/s For Python 3.3 this looks like O(n^2) complexity to me. 2.7 is better but still struggles for large amounts. Changing Popen._readerthread() to read in chunks rather than using FileIO.readall() produces a huge speed up: Python 3.3 with patch: amount = 1 MB; time taken = 0.01 secs; rate = 76.92 MB/s amount = 2 MB; time taken = 0.03 secs; rate = 76.92 MB/s amount = 4 MB; time taken = 0.04 secs; rate = 111.10 MB/s amount = 8 MB; time taken = 0.05 secs; rate = 148.14 MB/s amount = 16 MB; time taken = 0.10 secs; rate = 156.85 MB/s amount = 32 MB; time taken = 0.16 secs; rate = 198.75 MB/s amount = 64 MB; time taken = 0.31 secs; rate = 205.78 MB/s amount = 128 MB; time taken = 0.61 secs; rate = 209.82 MB/s Maybe FileIO.readall() should do something similar for files whose size cannot be determined by stat(). ---------- components: Library (Lib) files: push-thru-cat.py messages: 168813 nosy: sbt priority: normal severity: normal stage: patch review status: open title: 500x speed up for Popen.communicate() on Windows type: performance Added file: http://bugs.python.org/file26952/push-thru-cat.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 00:26:34 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 21 Aug 2012 22:26:34 +0000 Subject: [issue15758] 500x speed up for Popen.communicate() on Windows In-Reply-To: <1345587910.43.0.919180045188.issue15758@psf.upfronthosting.co.za> Message-ID: <1345587994.52.0.729533089336.issue15758@psf.upfronthosting.co.za> Changes by Richard Oudkerk : ---------- keywords: +patch Added file: http://bugs.python.org/file26953/popen_communicate.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 00:28:57 2012 From: report at bugs.python.org (Trent Nelson) Date: Tue, 21 Aug 2012 22:28:57 +0000 Subject: [issue15748] Various symlink test failures in test_shutil on FreeBSD In-Reply-To: <1345516038.44.0.114148239105.issue15748@psf.upfronthosting.co.za> Message-ID: <1345588137.71.0.308322500564.issue15748@psf.upfronthosting.co.za> Trent Nelson added the comment: Well, bugger me, check this out: import os import stat import tempfile d = tempfile.mkdtemp() src = os.path.join(d, 'foo') dst = os.path.join(d, 'bar') src_link = os.path.join(d, 'baz') dst_link = os.path.join(d, 'qux') sf = open(dst, 'w') sf.write('foo') sf.flush() sf.close() df = open(dst, 'w') df.write('bar') df.flush() df.close() os.symlink(src, src_link) os.symlink(dst, dst_link) os.lchmod(src_link, stat.S_IRWXU | stat.S_IRWXO) os.readlink(dst_link) os.readlink(src_link) Results of the last two calls: >>> os.readlink(dst_link) path 1: /tmp/tmpfz5v6h/qux, length 1: 18, buf 1: /tmp/tmpfz5v6h/bar path 2: /tmp/tmpfz5v6h/qux, length 2: 18, buf 2: /tmp/tmpfz5v6h/bar '/tmp/tmpfz5v6h/bar' [73299 refs] >>> os.readlink(src_link) path 1: /tmp/tmpfz5v6h/baz, length 1: 24, buf 1: /tmp/tmpfz5v6h/foo path 2: /tmp/tmpfz5v6h/baz, length 2: 24, buf 2: /tmp/tmpfz5v6h/foo '/tmp/tmpfz5v6h/foo\x00\x00\x00\x00\x00\x00' [73299 refs] So, without the os.lchmod() call, the length is returned correctly. With it, it gets returned as 24. Looks like an OS bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 00:31:53 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 21 Aug 2012 22:31:53 +0000 Subject: [issue15751] Add PyGILState_SwitchInterpreter In-Reply-To: <1345587272.98.0.214034944684.issue15751@psf.upfronthosting.co.za> Message-ID: <1345588102.3326.21.camel@localhost.localdomain> Antoine Pitrou added the comment: Le mardi 21 ao?t 2012 ? 22:14 +0000, Graham Dumpleton a ?crit : > Any third party module then which uses the simplistic calling sequence > of calling PyGILState_Release() on exiting Python code and thence > within the same thread calling PyGILState_Ensure() when coming back > into Python with a callback will work, as mod_wsgi has specified the > interpreter context for that thread at that time. Why would a module do that, instead of using Py_{BEGIN,END}_ALLOW_THREADS? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 00:36:40 2012 From: report at bugs.python.org (Graham Dumpleton) Date: Tue, 21 Aug 2012 22:36:40 +0000 Subject: [issue15751] Add PyGILState_SwitchInterpreter In-Reply-To: <1345526301.75.0.455071650321.issue15751@psf.upfronthosting.co.za> Message-ID: <1345588600.67.0.0529685927947.issue15751@psf.upfronthosting.co.za> Graham Dumpleton added the comment: Those macros only work for general GIL releasing and pop straight away, not for the case where released, calls into some non Python C library, which then calls back into Python. My recollection is, and so unless they have changed it, SWIG generated calls use the GILState calls. See: https://issues.apache.org/jira/browse/MODPYTHON-217 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 00:37:57 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 21 Aug 2012 22:37:57 +0000 Subject: [issue15754] Traceback message not returning SQLite check constraint details In-Reply-To: <1345559787.18.0.3645038202.issue15754@psf.upfronthosting.co.za> Message-ID: <1345588677.11.0.67704377034.issue15754@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > When building CPython yourself, it will use what version is found on your system. Ned, this is somewhat off-topic to the issue, but do you know of any ways to tell CPython to use a particular version of sqlite3 at compile time if a system has different versions installed at different locations? Or perhaps by putting the SQLite source code at an appropriate location in the Python source hierarchy (e.g. using the SQLite amalgamation files: http://www.sqlite.org/download.html ) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 00:56:45 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 21 Aug 2012 22:56:45 +0000 Subject: [issue15751] Add PyGILState_SwitchInterpreter In-Reply-To: <1345588600.67.0.0529685927947.issue15751@psf.upfronthosting.co.za> Message-ID: <1345589609.3326.24.camel@localhost.localdomain> Antoine Pitrou added the comment: > Those macros only work for general GIL releasing and pop straight > away, not for the case where released, calls into some non Python C > library, which then calls back into Python. I see, so you are right that this new API could be useful. However, we should also add a new GIL state API that fixes the issue for good (by passing an interpreter), otherwise we will still have such discussions in five years and it will be very silly. > My recollection is, and so unless they have changed it, SWIG generated > calls use the GILState calls. See: Well, if SWIG isn't fixed, people should stop using an unmaintained and buggy tool. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 00:59:43 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 21 Aug 2012 22:59:43 +0000 Subject: [issue15758] 500x speed up for Popen.communicate() on Windows In-Reply-To: <1345587910.43.0.919180045188.issue15758@psf.upfronthosting.co.za> Message-ID: <1345589983.15.0.329152831962.issue15758@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Yes, I think FileIO.readall() should be fixed rather than avoided. ---------- nosy: +pitrou versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 01:16:04 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 21 Aug 2012 23:16:04 +0000 Subject: [issue13520] Patch to make pickle aware of __qualname__ In-Reply-To: <1322843353.56.0.297081736881.issue13520@psf.upfronthosting.co.za> Message-ID: <1345590964.14.0.139572634752.issue13520@psf.upfronthosting.co.za> Richard Oudkerk added the comment: There is a cute way to use operator.attrgetter to produce backwards compatible pickles using the qualname: import pickle, copyreg, operator, sys, pickletools, types class AttrGetter(object): def __init__(self, name): self.name = name def __call__(self): # pretend to be callable raise RuntimeError def __reduce__(self): return operator.attrgetter, (self.name,) def reduce_by_qualname(obj): mod = sys.modules[obj.__module__] first, rest = obj.__qualname__.split('.', 1) firstobj = getattr(mod, first) assert operator.attrgetter(rest)(firstobj) is obj return AttrGetter(rest), (firstobj,) # FunctionType defaults to save_global but uses fallback if it fails copyreg.pickle(types.FunctionType, reduce_by_qualname) class A(object): class B(object): class C(object): @staticmethod def foo(): print("foo foo foo") def bar(): print("bar bar bar") for obj in [A.B.C.foo, bar]: data = pickle.dumps(obj, 2) pickletools.dis(data) func = pickle.loads(data) assert func is obj func() This produces 0: \x80 PROTO 2 2: c GLOBAL 'operator attrgetter' 23: q BINPUT 0 25: X BINUNICODE 'B.C.foo' 37: q BINPUT 1 39: \x85 TUPLE1 40: q BINPUT 2 42: R REDUCE 43: q BINPUT 3 45: c GLOBAL '__main__ A' 57: q BINPUT 4 59: \x85 TUPLE1 60: q BINPUT 5 62: R REDUCE 63: q BINPUT 6 65: . STOP highest protocol among opcodes = 2 foo foo foo 0: \x80 PROTO 2 2: c GLOBAL '__main__ bar' 16: q BINPUT 0 18: . STOP highest protocol among opcodes = 2 bar bar bar ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 01:22:12 2012 From: report at bugs.python.org (Ned Deily) Date: Tue, 21 Aug 2012 23:22:12 +0000 Subject: [issue15754] Traceback message not returning SQLite check constraint details In-Reply-To: <1345559787.18.0.3645038202.issue15754@psf.upfronthosting.co.za> Message-ID: <1345591332.42.0.234255978743.issue15754@psf.upfronthosting.co.za> Ned Deily added the comment: The magic for building the standard library's dynamically loaded extensions is in the top-level setup.py. It uses Distutils to do the work with a lot of hacking around in setup.py. Without modifying setup.py, it can be a little tricky to override the search order if you are trying to substitute a library that already exists in one of the normal system locations, particularly if you only want to override for that particular library. Perhaps the easiest and surest approach is to build and install the library (in this case libsqlite3) into a unique install root and then include the paths to the include and lib directories in the ./configure command for Python, so something like: ./configure [other options] LDFLAGS='-L /path/to/sqlite3/lib ' CPPFLAGS='-I /path/to/sqlite3/include ' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 01:38:23 2012 From: report at bugs.python.org (Larry Hastings) Date: Tue, 21 Aug 2012 23:38:23 +0000 Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS In-Reply-To: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za> Message-ID: <1345592303.33.0.778586732716.issue15745@psf.upfronthosting.co.za> Larry Hastings added the comment: mtime is never converted into a "decimal". Do you perhaps mean "double"? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 01:42:13 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 21 Aug 2012 23:42:13 +0000 Subject: [issue15747] Various chflags tests failing on FreeBSD/ZFS In-Reply-To: <1345515856.04.0.888770182553.issue15747@psf.upfronthosting.co.za> Message-ID: <3X1pMS2K9HzQW6@mail.python.org> Roundup Robot added the comment: New changeset 019a2390b014 by Trent Nelson in branch '3.2': Issue #15747: skip chflags UF_IMMUTABLE tests if EOPNOTSUPP is raised. http://hg.python.org/cpython/rev/019a2390b014 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 01:42:47 2012 From: report at bugs.python.org (John Taylor) Date: Tue, 21 Aug 2012 23:42:47 +0000 Subject: [issue15754] Traceback message not returning SQLite check constraint details In-Reply-To: <1345559787.18.0.3645038202.issue15754@psf.upfronthosting.co.za> Message-ID: <1345592567.16.0.184373604026.issue15754@psf.upfronthosting.co.za> John Taylor added the comment: Please close this ticket. This is not a bug. As per cjerdonek's suggestion, defining a constraint as follows: constraint my_name check (...) returns the actual name of the constraint, when it fails: sqlite3.IntegrityError: constraint my_name failed ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 01:45:57 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 21 Aug 2012 23:45:57 +0000 Subject: [issue15758] 500x speed up for Popen.communicate() on Windows In-Reply-To: <1345587910.43.0.919180045188.issue15758@psf.upfronthosting.co.za> Message-ID: <1345592757.15.0.784125458163.issue15758@psf.upfronthosting.co.za> Richard Oudkerk added the comment: RawIOBase.readall() does the sensible thing already. Maybe FileIO should be allowed to inherit it. The alternative patch (which probably only works for raw unbuffered case) diff -r ca54c27a9045 Lib/subprocess.py --- a/Lib/subprocess.py Tue Aug 21 14:54:22 2012 +0100 +++ b/Lib/subprocess.py Wed Aug 22 00:39:32 2012 +0100 @@ -1152,7 +1152,7 @@ def _readerthread(self, fh, buffer): - buffer.append(fh.read()) + buffer.append(io.RawIOBase.readall(fh)) fh.close() produces amount = 1 MB; time taken = 0.01 secs; rate = 71.42 MB/s amount = 2 MB; time taken = 0.02 secs; rate = 83.33 MB/s amount = 4 MB; time taken = 0.04 secs; rate = 105.26 MB/s amount = 8 MB; time taken = 0.06 secs; rate = 135.59 MB/s amount = 16 MB; time taken = 0.09 secs; rate = 170.20 MB/s amount = 32 MB; time taken = 0.17 secs; rate = 190.46 MB/s amount = 64 MB; time taken = 0.32 secs; rate = 202.52 MB/s amount = 128 MB; time taken = 0.61 secs; rate = 211.56 MB/s ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 01:47:08 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 21 Aug 2012 23:47:08 +0000 Subject: [issue15754] Traceback message not returning SQLite check constraint details In-Reply-To: <1345559787.18.0.3645038202.issue15754@psf.upfronthosting.co.za> Message-ID: <1345592828.69.0.705673112294.issue15754@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- resolution: works for me -> invalid stage: needs patch -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 01:58:43 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 21 Aug 2012 23:58:43 +0000 Subject: [issue15758] 500x speed up for Popen.communicate() on Windows In-Reply-To: <1345587910.43.0.919180045188.issue15758@psf.upfronthosting.co.za> Message-ID: <1345593523.08.0.920624899161.issue15758@psf.upfronthosting.co.za> Antoine Pitrou added the comment: FileIO.readall() already has an overallocation mechanism which should yield linear complexity. Perhaps it needs to be tweaked a bit? (look at new_buffersize in Modules/_io/fileio.c) By the way, your results are bit weird. Why does the data rate increase with the transfered amount? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 01:59:40 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 21 Aug 2012 23:59:40 +0000 Subject: [issue15747] Various chflags tests failing on FreeBSD/ZFS In-Reply-To: <1345515856.04.0.888770182553.issue15747@psf.upfronthosting.co.za> Message-ID: <3X1plb2c0QzQXb@mail.python.org> Roundup Robot added the comment: New changeset f986d523e93d by Trent Nelson in branch 'default': Issue #15747: skip chflags UF_IMMUTABLE tests if EOPNOTSUPP is raised. http://hg.python.org/cpython/rev/f986d523e93d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 02:00:44 2012 From: report at bugs.python.org (Trent Nelson) Date: Wed, 22 Aug 2012 00:00:44 +0000 Subject: [issue15747] Various chflags tests failing on FreeBSD/ZFS In-Reply-To: <1345515856.04.0.888770182553.issue15747@psf.upfronthosting.co.za> Message-ID: <1345593644.87.0.0255253011697.issue15747@psf.upfronthosting.co.za> Changes by Trent Nelson : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 02:03:26 2012 From: report at bugs.python.org (Trent Nelson) Date: Wed, 22 Aug 2012 00:03:26 +0000 Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS In-Reply-To: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za> Message-ID: <1345593806.7.0.0657105796216.issue15745@psf.upfronthosting.co.za> Trent Nelson added the comment: Oh, heh, yes, I meant double :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 02:09:03 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Wed, 22 Aug 2012 00:09:03 +0000 Subject: [issue15758] 500x speed up for Popen.communicate() on Windows In-Reply-To: <1345587910.43.0.919180045188.issue15758@psf.upfronthosting.co.za> Message-ID: <1345594143.49.0.368389141509.issue15758@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > FileIO.readall() already has an overallocation mechanism which should > yield linear complexity. Perhaps it needs to be tweaked a bit? > (look at new_buffersize in Modules/_io/fileio.c) I think it needs a bit more than a tweak;-) Looks like it increases by 12.5% at time. Does not seem to work as intended though. > By the way, your results are bit weird. Why does the data rate increase > with the transfered amount? The rates are completely unreliable for those benchmarks which take less than 0.1 seconds. They level off after 0.1 secs when the overheads become insignificant. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 02:15:24 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 22 Aug 2012 00:15:24 +0000 Subject: [issue15316] runpy swallows ImportError information with relative imports In-Reply-To: <1341898758.4.0.623810416258.issue15316@psf.upfronthosting.co.za> Message-ID: <1345594524.86.0.181028336556.issue15316@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I randomly ran into this issue again. I'm not sure this was ever resolved (i.e. I think it may always have been different from issue 15111). I still get the above behavior in the default branch. And here is what I get in the 3.2 branch (the error information is not swallowed): $ ./python.exe -m foo *** Traceback (most recent call last): File ".../Lib/runpy.py", line 161, in _run_module_as_main "__main__", fname, loader, pkg_name) File ".../Lib/runpy.py", line 74, in _run_code exec(code, run_globals) File ".../foo/__main__.py", line 1, in from foo import bar File "foo/bar.py", line 2, in raise ImportError('test...') ImportError: test... ---------- nosy: +brett.cannon, ncoghlan resolution: duplicate -> status: closed -> open superseder: Wrong ImportError message with importlib -> type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 02:25:26 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 22 Aug 2012 00:25:26 +0000 Subject: [issue15316] runpy swallows ImportError information with relative imports In-Reply-To: <1341898758.4.0.623810416258.issue15316@psf.upfronthosting.co.za> Message-ID: <1345595126.57.0.802308964987.issue15316@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I ran into this again because an error while running `./python.exe -m test` was getting masked. The use of __main__.py in the package may be the distinguishing characteristic. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 02:44:13 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 22 Aug 2012 00:44:13 +0000 Subject: [issue1207589] Right Click Context Menu Message-ID: <1345596253.68.0.117633702328.issue1207589@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- versions: +Python 3.4 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 02:46:30 2012 From: report at bugs.python.org (Graham Dumpleton) Date: Wed, 22 Aug 2012 00:46:30 +0000 Subject: [issue15751] Add PyGILState_SwitchInterpreter In-Reply-To: <1345526301.75.0.455071650321.issue15751@psf.upfronthosting.co.za> Message-ID: <1345596390.71.0.193369062575.issue15751@psf.upfronthosting.co.za> Graham Dumpleton added the comment: If you have a Ex version of Ensure, then if the interpreter argument is NULL, then it should assume main interpreter. That way the normal version of Ensure can just call PyGILState_EnsureEx(NULL). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 03:17:34 2012 From: report at bugs.python.org (Yap Sok Ann) Date: Wed, 22 Aug 2012 01:17:34 +0000 Subject: [issue15207] mimetypes.read_windows_registry() uses the wrong regkey, creates wrong mappings In-Reply-To: <1340813009.36.0.80214060404.issue15207@psf.upfronthosting.co.za> Message-ID: <1345598254.6.0.0710228259437.issue15207@psf.upfronthosting.co.za> Yap Sok Ann added the comment: On Python 2.7, I need to add this to the original diff by Dave, in the same try-except block: mimetype = mimetype.encode(default_encoding) # omit in 3.x! ---------- nosy: +sayap _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 03:39:33 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 22 Aug 2012 01:39:33 +0000 Subject: [issue665194] datetime-RFC2822 roundtripping Message-ID: <1345599573.0.0.794388009054.issue665194@psf.upfronthosting.co.za> R. David Murray added the comment: Alexander, this slipped off my radar. Some of the tests Brian added fail with the patch applied. I fixed most of them by adding back the support for converting an aware datetime to an aware localtime. The remaining two I believe are what you are fixing with this patch (in addition to converting to using astimezone for the current-localtime case). So there I fixed the tests. Hopefully I got this right, and hopefully you can find time to review it. I'll probably check it in before the RC regardless, since it looks like an improvement to me. ---------- Added file: http://bugs.python.org/file26954/localtime.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 03:55:30 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 22 Aug 2012 01:55:30 +0000 Subject: [issue665194] datetime-RFC2822 roundtripping Message-ID: <1345600530.33.0.561436674148.issue665194@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I'll take a look tomorrow morning. (EDT:-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 04:03:51 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 22 Aug 2012 02:03:51 +0000 Subject: [issue15750] test_localtime_daylight_false_dst_true raises OverflowError: mktime argument out of range In-Reply-To: <1345526136.06.0.661867821529.issue15750@psf.upfronthosting.co.za> Message-ID: <1345601031.98.0.990826920603.issue15750@psf.upfronthosting.co.za> R. David Murray added the comment: So you are saying that if the current timezone is UTC, FreeBSD's mktime just arbitrarily returns -1 for any time passed to it with the 'guess the DST flag' value set for is_dst? And for is_dst set to 1 as well? This isn't mentioned on the FreeBSD man page for mktime, as far as I can see. If this is the real problem, we can fix it with the support.run_with_tz decorator, but...compiling and running your program on my linux box, I get -1 in both prints. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 04:04:38 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 22 Aug 2012 02:04:38 +0000 Subject: [issue665194] datetime-RFC2822 roundtripping Message-ID: <1345601078.2.0.2160500782.issue665194@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I noticed this part: + # We have an aware datetime. Use aware datetime arithmetic to find the + # seconds since the epoch. + delta = dt - datetime.datetime(*time.gmtime(0)[:6], + tzinfo=datetime.timezone.utc) + seconds = delta.total_seconds() Why don't you just return dt.astimezone() here? A round trip through a floating point timestamp always makes me nervous. I doubt loss of precision is a problem for the e-mail package, but who knows. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 04:10:34 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 22 Aug 2012 02:10:34 +0000 Subject: [issue665194] datetime-RFC2822 roundtripping Message-ID: <1345601434.87.0.1229529173.issue665194@psf.upfronthosting.co.za> R. David Murray added the comment: Heh, I was just copying the previous code, and didn't think about being able to update it. Will make that change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 04:13:04 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 22 Aug 2012 02:13:04 +0000 Subject: [issue15750] test_localtime_daylight_false_dst_true raises OverflowError: mktime argument out of range In-Reply-To: <1345526136.06.0.661867821529.issue15750@psf.upfronthosting.co.za> Message-ID: <1345601584.3.0.477861360381.issue15750@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > So you are saying that if the current timezone is UTC, FreeBSD's mktime > just arbitrarily returns -1 for any time passed to it with the 'guess > the DST flag' value set for is_dst? I don't know about FreeBSD, but I recall seeing a comment in mxDT sources that some systems only allow isdst flag of -1 in mktime. Adding Marc-Andre. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 04:24:32 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 22 Aug 2012 02:24:32 +0000 Subject: [issue665194] datetime-RFC2822 roundtripping Message-ID: <1345602272.13.0.669973395712.issue665194@psf.upfronthosting.co.za> R. David Murray added the comment: And my tests and code were wrong, and I was wrong about what you were trying to fix. So since the other tests were passing before, presumably there is some test that could be added to exercise the bug you were fixing. Do you remember what that was? ---------- Added file: http://bugs.python.org/file26955/localtime.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 04:25:20 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 22 Aug 2012 02:25:20 +0000 Subject: [issue15316] runpy swallows ImportError information with relative imports In-Reply-To: <1341898758.4.0.623810416258.issue15316@psf.upfronthosting.co.za> Message-ID: <1345602320.75.0.673313807542.issue15316@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- keywords: +3.2regression _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 04:38:31 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 22 Aug 2012 02:38:31 +0000 Subject: [issue665194] datetime-RFC2822 roundtripping Message-ID: <1345603111.43.0.633030139523.issue665194@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > So since the other tests were passing before, presumably there > is some test that could be added to exercise the bug you were > fixing. Do you remember what that was? Yes, the issue was the one that was mentioned in an XXX comment: in many places UTC offset was different at different historical times but standard C library and Python's time module provides a single constant for it. There are plenty of examples that can be found in Olson's database (Europe/Kiev comes to mind), but it is not easy to devise a test that will work cross-platform. Maybe we should just restrict the test to Linux/BSD family of OSes? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 07:34:23 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 22 Aug 2012 05:34:23 +0000 Subject: [issue15759] "make suspicious" doesn't display instructions in case of failure Message-ID: <1345613663.78.0.519613331574.issue15759@psf.upfronthosting.co.za> New submission from Ezio Melotti: I was running "make suspicious" in Doc/ and this was the output after finding 3 suspicious markups: writing output... [ 52%] library/inspect WARNING: [library/inspect:437] ":int" found in ">>> def foo(a, *, b:int, **kwargs):" WARNING: [library/inspect:437] ":int" found in "'(a, *, b:int, **kwargs)'" WARNING: [library/inspect:437] ":int" found in "'b:int'" writing output... [100%] whatsnew/index build finished with problems, 3 warnings. make: *** [build] Error 1 After figuring out how to mark these as false positives and adding the relevant entries to susp-ignored.csv, I ran "make suspicious" again, and got this useful message at the end: writing output... [100%] whatsnew/index build succeeded. Suspicious check complete; look for any errors in the above output or in build/suspicious /suspicious.csv. If all issues are false positives, append that file to tools/sphinxext/susp-ignored.csv. The problem is that this message should be displayed when there are failures, but it's not. Attached an attempt to fix the Makefile to avoid exiting in case of failures when the builder is "suspicious". Given that I'm not really familiar with makefiles, it probably doesn't make much sense. ---------- assignee: docs at python components: Documentation files: issue15759.diff keywords: patch messages: 168842 nosy: docs at python, eric.araujo, ezio.melotti, georg.brandl priority: normal severity: normal stage: patch review status: open title: "make suspicious" doesn't display instructions in case of failure type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file26956/issue15759.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 08:40:15 2012 From: report at bugs.python.org (Trent Nelson) Date: Wed, 22 Aug 2012 06:40:15 +0000 Subject: [issue15746] test_winsound bombing out on 2003 buildslave In-Reply-To: <1345515472.32.0.153802141999.issue15746@psf.upfronthosting.co.za> Message-ID: <1345617615.56.0.436031412864.issue15746@psf.upfronthosting.co.za> Trent Nelson added the comment: Affirmative: E:\Apps\activestate-python-2.7.2.5-x86>python ActivePython 2.7.2.5 (ActiveState Software Inc.) based on Python 2.7.2 (default, Jun 24 2011, 12:21:10) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import test.test_winsound >>> test.test_winsound._have_soundcard() False >>> import winsound >>> winsound.PlaySound('!"$%&/(#+*', winsound.SND_ALIAS | winsound.SND_NODEFAULT) >>> No exception raised. (No sound is played, either, FWIW.) I like the approach taken by the method before test_alias_nofallback(): def test_alias_fallback(self): # This test can't be expected to work on all systems. The MS # PlaySound() docs say: # # If it cannot find the specified sound, PlaySound uses the # default system event sound entry instead. If the function # can find neither the system default entry nor the default # sound, it makes no sound and returns FALSE. # # It's known to return FALSE on some real systems. # winsound.PlaySound('!"$%&/(#+*', winsound.SND_ALIAS) return I suspect that'll solve all our problems ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 08:51:57 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Wed, 22 Aug 2012 06:51:57 +0000 Subject: [issue7741] Allow multiple statements in code.InteractiveConsole.push In-Reply-To: <1263912723.35.0.93131684665.issue7741@psf.upfronthosting.co.za> Message-ID: <1345618317.07.0.961211301237.issue7741@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: What's the purpose of the new patch, particularly 2/2 since it is equivalent to multiple push() calls? I.e. since this issue has laid dormant for two years, what prompts the sudden activity? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 09:13:15 2012 From: report at bugs.python.org (Nashev) Date: Wed, 22 Aug 2012 07:13:15 +0000 Subject: [issue1207589] Right Click Context Menu Message-ID: <1345619595.82.0.730397392423.issue1207589@psf.upfronthosting.co.za> Nashev added the comment: display assigned hot keys in popup menu is must-have feature, that allow users to teach them while using commands by menu or by context menu. For examples look Delphi IDE ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 09:21:23 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 22 Aug 2012 07:21:23 +0000 Subject: [issue15316] runpy swallows ImportError information with relative imports In-Reply-To: <1341898758.4.0.623810416258.issue15316@psf.upfronthosting.co.za> Message-ID: <1345620083.97.0.2291164875.issue15316@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Should this issue be fixed before the release? If it is not fixed, certain problems found after the release may become harder to report and diagnose (because the true source of error will be masked). Two months ago issue 15111 which was thought to be the same was given a priority of "high". ---------- nosy: +georg.brandl, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 09:37:57 2012 From: report at bugs.python.org (Louis Deflandre) Date: Wed, 22 Aug 2012 07:37:57 +0000 Subject: [issue5088] optparse: inconsistent default value for append actions In-Reply-To: <1233140307.53.0.685208172708.issue5088@psf.upfronthosting.co.za> Message-ID: <1345621077.86.0.50938916937.issue5088@psf.upfronthosting.co.za> Louis Deflandre added the comment: Hello, Tell me if the issue is too old to deserve comments anymore. But I would like to challenge the conclusion made in this issue. The message msg9944 stated "Think of the default as the initial list" but it is inconsistent with the proper meaning of default which can be defined as : "a preselected option adopted by a computer program or other mechanism WHEN NO ALTERNATIVE IS SPECIFIED" (http://www.wordreference.com/definition/default - Oxford Dictionary). The "initial list" conclusion seems to me more implementation oriented than really user oriented ---------- nosy: +louis.deflandre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 09:45:25 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 22 Aug 2012 07:45:25 +0000 Subject: [issue7741] Allow multiple statements in code.InteractiveConsole.push In-Reply-To: <1263912723.35.0.93131684665.issue7741@psf.upfronthosting.co.za> Message-ID: <1345621525.08.0.734899345208.issue7741@psf.upfronthosting.co.za> Nick Coghlan added the comment: Aaron was looking for something to work on for the PyConAU sprints, and set himself the task of closing as many issues related to the code module as possible. The main outcome of that was the new test suite added in #12643, which should make it easier to work on the module (at least in 3.3+) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 09:47:24 2012 From: report at bugs.python.org (Stefan Krah) Date: Wed, 22 Aug 2012 07:47:24 +0000 Subject: [issue15757] ./configure --with-pydebug on FreeBSD results in -O2 -pipe eventually ending up in CFLAGS. In-Reply-To: <1345586300.5.0.087898850836.issue15757@psf.upfronthosting.co.za> Message-ID: <20120822074724.GA12325@sleipnir.bytereef.org> Stefan Krah added the comment: > So, looks like FreeBSD's /usr/share/mk/sys.mk is to blame here. > It unconditionally sets CFLAGS to `-O2 -pipe`. I've been debugging this once, too. My conclusion was that if the OS is set up that way, we shouldn't do anything about it in the Python source tree. All important features of --with-pydebug should also work if -O0 is overridden by -O2. So I think that FreeBSD users who really want -O0 should change sys.mk or set CFLAGS manually. For the buildbots it should not matter, except that compile times are slower. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 09:48:32 2012 From: report at bugs.python.org (danblack) Date: Wed, 22 Aug 2012 07:48:32 +0000 Subject: [issue10852] SSL/TLS sni use in smtp, pop, imap, nntp, ftp client libs by default In-Reply-To: <1294375380.08.0.187691378511.issue10852@psf.upfronthosting.co.za> Message-ID: <1345621712.69.0.463224899071.issue10852@psf.upfronthosting.co.za> danblack added the comment: > Thanks for the patch > Daniel. 3.3 is nearing the release candidate phase, so I'm re-targetting to 3.4. I'll take a detailed look soon. Welcome. Just noticed conflicts with #4473 in the client POP implementation. Hopefully they are close anyway. > (I suppose there's no easy way to write automated tests for this, unfortunately) Well since #8109 writes the server SNI its getting easier. In Lib/test/test_ssl.py combined with the changes of #8109 it would seem that changing ConnectionHandler.run to respond to "AUTH TLS", "AUTH SSL" (ftp) and "STLS" for pop (preempt #4473). Changing server_params_test to support a proper arguments that correspond the the client protocol would be the way to do it. > By the way, could you sign a contributor agreement yes - emailed in. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 09:52:10 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 22 Aug 2012 07:52:10 +0000 Subject: [issue14292] OS X installer build script doesn't set $CXX, so it ends up as "c++" In-Reply-To: <1331671465.67.0.741908765122.issue14292@psf.upfronthosting.co.za> Message-ID: <1345621930.27.0.941704235666.issue14292@psf.upfronthosting.co.za> Ronald Oussoren added the comment: The attached patch sets not just 'CC' but 'CXX' as well. I haven't tested the patch beyond building on an OSX 10.8 system (that is, the primary use of the script is not tested) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 09:52:21 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 22 Aug 2012 07:52:21 +0000 Subject: [issue14292] OS X installer build script doesn't set $CXX, so it ends up as "c++" In-Reply-To: <1331671465.67.0.741908765122.issue14292@psf.upfronthosting.co.za> Message-ID: <1345621941.54.0.210914564815.issue14292@psf.upfronthosting.co.za> Changes by Ronald Oussoren : Added file: http://bugs.python.org/file26957/issue14292.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 10:02:12 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 22 Aug 2012 08:02:12 +0000 Subject: [issue13370] test_ctypes fails when building python with clang In-Reply-To: <1320761474.93.0.268896325495.issue13370@psf.upfronthosting.co.za> Message-ID: <1345622532.45.0.268966637107.issue13370@psf.upfronthosting.co.za> Ronald Oussoren added the comment: The change to ppc-ffi_darwin.c was unintentional and should be removed. I must have been sleeping during the merge, as I only intended to copy the files for i386/x86_64 and not for PPC as the latter architecture didn't have problems when compiled with clang. I've copied the ppc-ffi_darwin.c file from Python's tree into the PyObjC tree to avoid problems when there are future merges. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 10:03:57 2012 From: report at bugs.python.org (Samuel John) Date: Wed, 22 Aug 2012 08:03:57 +0000 Subject: [issue13405] Add DTrace probes In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za> Message-ID: <1345622637.25.0.598417857608.issue13405@psf.upfronthosting.co.za> Samuel John added the comment: On OS X 10.8 with Xcode only (no command line tools), I get the following err (when using clang or when using llvm-gcc): ``` dtrace: failed to compile script ./Include/pydtrace.d: Preprocessor not found make: *** [Include/pydtrace.h] Error 1 ``` At homebrew we optionally try to apply your patch to python https://github.com/mxcl/homebrew/pull/14343. I'd really like to be able to make the "Command Line Tools for Xcode" optional. Note, there is no "cpp" for clang. Usually, the "CC=/path/to/clang" just works. (I have seen "CPP = $CC -E" before, but that did *not* do the trick here). Any ideas? ---------- nosy: +samueljohn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 10:15:56 2012 From: report at bugs.python.org (Lennart Regebro) Date: Wed, 22 Aug 2012 08:15:56 +0000 Subject: [issue15760] make install should generate grammar file Message-ID: <1345623356.64.0.534348274406.issue15760@psf.upfronthosting.co.za> New submission from Lennart Regebro: If you install Python 3.3b2 with "sudo make install", a standard way of installing it so that users don't have rights to install global modules, then everytime lib2to3.pgen2.driver.load_grammar() is called, it aims to generate a a grammar table and write it as a pickle to a cache file. However, unless you are superuser when doing this, writing the file will of course fail, with a message similar to this: INFO:root:Generating grammar tables from /opt/python33/lib/python3.3/lib2to3/PatternGrammar.txt INFO:root:Writing grammar tables to /opt/python33/lib/python3.3/lib2to3/PatternGrammar3.3.0.beta.2.pickle INFO:root:Writing failed:[Errno 13] Permission denied: '/opt/python33/lib/python3.3/lib2to3/PatternGrammar3.3.0.beta.2.pickle' A workaround is to run the script that creates the above errors as superuser once, and the message goes away. I think the correct thing to do here is for make install to Generate these grammar tables and write the pickle. Steps to reproduce: 1. Install Python 3.3.b2 with "./configure;make;sudo make install" 2. Check out the Distribute sources: "hg clone https://bitbucket.org/stefanholek/distribute" 3. Run the Distribute tests: "python3.3 setup.py test" ---------- messages: 168854 nosy: lregebro priority: normal severity: normal status: open title: make install should generate grammar file type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 10:16:05 2012 From: report at bugs.python.org (Lennart Regebro) Date: Wed, 22 Aug 2012 08:16:05 +0000 Subject: [issue15760] make install should generate grammar file In-Reply-To: <1345623356.64.0.534348274406.issue15760@psf.upfronthosting.co.za> Message-ID: <1345623365.01.0.0504258965828.issue15760@psf.upfronthosting.co.za> Changes by Lennart Regebro : ---------- components: +Installation _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 10:19:46 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Wed, 22 Aug 2012 08:19:46 +0000 Subject: [issue15760] make install should generate grammar file In-Reply-To: <1345623356.64.0.534348274406.issue15760@psf.upfronthosting.co.za> Message-ID: <1345623586.87.0.969262525828.issue15760@psf.upfronthosting.co.za> Hynek Schlawack added the comment: Seems related to #15645, no? ---------- nosy: +hynek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 10:21:47 2012 From: report at bugs.python.org (Ned Deily) Date: Wed, 22 Aug 2012 08:21:47 +0000 Subject: [issue15761] Setting PYTHONEXECUTABLE can cause segfaults on OS X Message-ID: <1345623707.33.0.86377230375.issue15761@psf.upfronthosting.co.za> New submission from Ned Deily: Setting the environment variable PYTHONEXECUTABLE can cause the interpreter to crash with a segfault or to otherwise fail during initialization. Another manifestation is the failure of test test_osx_env with: AssertionError: -10 != 2 : expected PYTHONEXECUTABLE == sys.executable (-10 means the interpreter subprocess under test segfaulted) I have not yet been able to identify the root cause or the minimum set of conditions to produce a crash. So far it seems that the interpreter must be 32-bit and running on 10.6 or later. In all of the failures I've seen, PYTHONEXECUTABLE was set to an absolute path, not necessarily a valid path. When running a debug build, I've seen two failure modes: Assertion failed: (value), function PyDict_SetItem, file Objects/dictobject.c, line 1197. #0 0x942a9332 in __kill () #1 0x942a8932 in kill$UNIX2003 () #2 0x98563c0c in abort () #3 0x9859820b in __assert_rtn () #4 0x00091b0f in PyDict_SetItem (op=0x48f438, key=0x487610, value=0x0) at Objects/dictobject.c:1197 #5 0x0009669d in PyDict_SetItemString (v=0x48f438, key=0x30ccfd "version", item=0x0) at Objects/dictobject.c:2695 #6 0x00245616 in make_impl_info (version_info=0x0) at ./Python/sysmodule.c:1525 #7 0x00244a00 in _PySys_Init () at ./Python/sysmodule.c:1690 #8 0x0022fdc1 in _Py_InitializeEx_Private (install_sigs=1, install_importlib=1) at Python/pythonrun.c:334 #9 0x00231577 in Py_InitializeEx (install_sigs=1) at Python/pythonrun.c:401 #10 0x0023159a in Py_Initialize () at Python/pythonrun.c:407 #11 0x00269138 in Py_Main (argc=3, argv=0x446028) at Modules/main.c:646 Also: Could not find platform independent libraries Could not find platform dependent libraries Consider setting $PYTHONHOME to [:] Fatal Python error: Py_Initialize: unable to load the file system codec ImportError: No module named 'encodings' #0 0x942a9332 in __kill () #1 0x942a8932 in kill$UNIX2003 () #2 0x98563c0c in abort () #3 0x001a8d09 in Py_FatalError ( msg=0x2506d4 "Py_Initialize: unable to load the file system codec") at Python/pythonrun.c:2358 #4 0x001a3320 in _Py_InitializeEx_Private (install_sigs=1, install_importlib=1) at Python/pythonrun.c:374 #5 0x001a3442 in Py_InitializeEx (install_sigs=1) at Python/pythonrun.c:401 #6 0x001a3456 in Py_Initialize () at Python/pythonrun.c:407 #7 0x001cd0f2 in Py_Main (argc=1, argv=0x394028) at Modules/main.c:646 #8 0x000025e7 in main (argc=1, argv=0xbffff994) at python.c:66 Inspecting and gdb stepping through main.c, getpath.c, and pythonrun.c has not uncovered anything obvious yet. Note, there have been changes in these areas for 3.3 in support of venv and bug fixes. PYTHONEXECUTABLE is a somewhat vestigial environment variable supported only on OS X. AFAIK, it was only intended for used with the deprecated bundlebuilder.py tool but it is externally documented; it's also still used by IDLE.app initialization which is based on bundlebuilder. So it might not be a release blocker to fix immediately but it is disquieting. As there are other higher priority issues at the moment, I probably won't be able to get back to this until after rc1. ---------- assignee: ronaldoussoren components: Macintosh messages: 168856 nosy: ned.deily, ronaldoussoren priority: high severity: normal status: open title: Setting PYTHONEXECUTABLE can cause segfaults on OS X type: crash versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 10:27:29 2012 From: report at bugs.python.org (Lennart Regebro) Date: Wed, 22 Aug 2012 08:27:29 +0000 Subject: [issue15760] make install should generate grammar file In-Reply-To: <1345623356.64.0.534348274406.issue15760@psf.upfronthosting.co.za> Message-ID: <1345624049.72.0.156662602249.issue15760@psf.upfronthosting.co.za> Lennart Regebro added the comment: Yes, and for some reason it didn't show up when I searched for "Grammar" 10 minutes ago, but now it does. :-) It's a duplicate, indeed. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 10:29:07 2012 From: report at bugs.python.org (Lennart Regebro) Date: Wed, 22 Aug 2012 08:29:07 +0000 Subject: [issue15645] 2to3 Grammar pickles not created when upgrading to 3.3.0b2 In-Reply-To: <1344932180.41.0.826216341416.issue15645@psf.upfronthosting.co.za> Message-ID: <1345624147.45.0.478345947966.issue15645@psf.upfronthosting.co.za> Lennart Regebro added the comment: I can confirm that this is an issue on Ubuntu 12.04 as well, and that removing the existing pre 3.3b2 install before installing solves the problem. ---------- nosy: +lregebro _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 10:53:25 2012 From: report at bugs.python.org (Aaron Galea) Date: Wed, 22 Aug 2012 08:53:25 +0000 Subject: [issue15762] Windows 8 certification Message-ID: <1345625605.38.0.633732854192.issue15762@psf.upfronthosting.co.za> New submission from Aaron Galea: Hi We have an application created with python2.7 and created into an executable using py2exe. However we are getting an issue with Windows 8 certification due to compiler parameters. We would like to have this application Windows 8 certified but we can't get pass the following warning: =============================================== Windows security features test WARNING Binary analyzer ? Warning: The binary analyzer test detected the following errors: ?File C:\Program Files (x86)\TestApp\test.exe has failed the DBCheck check. ?File C:\Program Files (x86)\TestApp\test.exe has failed the NXCheck check. ? Impact if not fixed: If the app doesn?t use the available Windows protections, it can increase the vulnerability of customer's computer to malware. ? How to fix: Apply the SAFESEH, DYNAMICBASE, and NXCOMPAT options when you link the app. See link below for more information: Fixing Binary Analyzer Errors ======================================================================== In order to fix this issue I had to modify the file msvc9compiler.py by changing the following line from: self.ldflags_shared = ['/DLL', '/nologo', '/INCREMENTAL:NO'] to self.ldflags_shared = ['/DLL', '/nologo', '/INCREMENTAL:NO', '/DYNAMICBASE', '/SAFESEH', '/NXCOMPAT'] and rebuild py2exe. Once I have done this the test passed. I could go about it by having local patch available to my team but preferably I try to avoid patching the standard python modules. My question is if there is another way to do this? and whether it would be a good idea to include these flags in future distutils? ---------- assignee: eric.araujo components: Distutils messages: 168859 nosy: agale031176, eric.araujo, tarek priority: normal severity: normal status: open title: Windows 8 certification type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 10:59:11 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 22 Aug 2012 08:59:11 +0000 Subject: [issue15761] Setting PYTHONEXECUTABLE can cause segfaults on OS X In-Reply-To: <1345623707.33.0.86377230375.issue15761@psf.upfronthosting.co.za> Message-ID: <1345625951.66.0.642998232013.issue15761@psf.upfronthosting.co.za> Ronald Oussoren added the comment: There could be an off by one error in the decoding of PYTHONEXECUTABLE, mbstowcs will only add a NUL character when there is room for one and when the environment variable is all ASCII the buffer isn't large enough which means the argument to Py_SetProgramName is not NUL-terminated unless there happens to be a NUL byte just beyond the allocated buffer. The attached patch ensures that there is room for a NUL character. I don't know if this actually fixes the crash as I've been unable to reproduce the issue (with various values of PYTHONEXECUBLE and with/without malloc checking environment variables (see malloc(3)). ---------- Added file: http://bugs.python.org/file26958/issue15761.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 11:11:02 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 22 Aug 2012 09:11:02 +0000 Subject: [issue15761] Setting PYTHONEXECUTABLE can cause segfaults on OS X In-Reply-To: <1345623707.33.0.86377230375.issue15761@psf.upfronthosting.co.za> Message-ID: <1345626662.02.0.424582717463.issue15761@psf.upfronthosting.co.za> Ronald Oussoren added the comment: I can now reproduce the isue: env PYTHONHOME=/Library/Frameworks/Python.framework/Versions/3.3 PYTHONEXECUTABLE=/bin/bash MallocGuardEdges=1 MallocStackLogging=1 MallocScribble=1 MallocStackLoggingNoCompact=1 MallocCheckHeapEach=1 arch -i386 python3.3 -c 'import sys; print(sys.executable)' This also fails with Python 3.2, but then it fails with a unicode error UnicodeEncodeError: 'utf-8' codec can't encode character '\udffa' in position 17: surrogates not allowed The error goes away when I used a patched version of python.exe, but that's one was not a framework build. Next step: rebuild and reinstall the 3.3 framework with my patch and check that the problem goes away. All of this on an OSX 10.8 box, deployment target 10.8 and archs=intel. Other notes: * The 'Malloc....' variables aren't necessary to reproduce * 'arch -i386' is necessary, no crash with 'arch -x86_64' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 11:11:08 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 22 Aug 2012 09:11:08 +0000 Subject: [issue15761] Setting PYTHONEXECUTABLE can cause segfaults on OS X In-Reply-To: <1345623707.33.0.86377230375.issue15761@psf.upfronthosting.co.za> Message-ID: <1345626668.79.0.575272153642.issue15761@psf.upfronthosting.co.za> Changes by Ronald Oussoren : ---------- versions: +Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 11:41:32 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Wed, 22 Aug 2012 09:41:32 +0000 Subject: [issue15758] 500x speed up for Popen.communicate() on Windows In-Reply-To: <1345587910.43.0.919180045188.issue15758@psf.upfronthosting.co.za> Message-ID: <1345628492.31.0.463995389148.issue15758@psf.upfronthosting.co.za> Richard Oudkerk added the comment: In each loop before calling read() the buffer size is recalculated based on the amount of space used, causing a realloc *regardless* of how much empty space is left in the buffer. And each read is only producing a smallish chunk (5120 bytes). So assuming realloc fails to do an inplace realloc (and Windows is reputedly very bad at that) the amount of data copied will be O(n^2). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 11:58:03 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Wed, 22 Aug 2012 09:58:03 +0000 Subject: [issue15758] 500x speed up for Popen.communicate() on Windows In-Reply-To: <1345587910.43.0.919180045188.issue15758@psf.upfronthosting.co.za> Message-ID: <1345629483.54.0.817302653543.issue15758@psf.upfronthosting.co.za> Richard Oudkerk added the comment: The attached patch (readall-resize.patch) makes the resizes only happen when the buffer is full. It produces amount = 1 MB; time taken = 0.02 secs; rate = 64.10 MB/s amount = 2 MB; time taken = 0.03 secs; rate = 64.10 MB/s amount = 4 MB; time taken = 0.06 secs; rate = 64.10 MB/s amount = 8 MB; time taken = 0.08 secs; rate = 102.56 MB/s amount = 16 MB; time taken = 0.17 secs; rate = 93.24 MB/s amount = 32 MB; time taken = 0.31 secs; rate = 102.56 MB/s amount = 64 MB; time taken = 0.70 secs; rate = 91.17 MB/s amount = 128 MB; time taken = 1.81 secs; rate = 70.73 MB/s ---------- Added file: http://bugs.python.org/file26959/readall-resize.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 12:02:29 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 22 Aug 2012 10:02:29 +0000 Subject: [issue11776] Constructor signatures missing in types module documentation In-Reply-To: <1302036805.33.0.506634428921.issue11776@psf.upfronthosting.co.za> Message-ID: <1345629749.77.0.894535000382.issue11776@psf.upfronthosting.co.za> Nick Coghlan added the comment: Clarifying the request: the constructor signatures for internal types should be documented in http://docs.python.org/dev/library/types, rather than just listing the types. If creation of new instances from Python is not supported, that should also be documented explicitly. Some of the items are currently missing docstrings as well. ---------- nosy: +ncoghlan title: types.MethodType() params and usage is not documented -> Constructor signatures missing in types module documentation _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 12:08:12 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Wed, 22 Aug 2012 10:08:12 +0000 Subject: [issue15758] 500x speed up for Popen.communicate() on Windows In-Reply-To: <1345587910.43.0.919180045188.issue15758@psf.upfronthosting.co.za> Message-ID: <1345630092.23.0.0120406314501.issue15758@psf.upfronthosting.co.za> Richard Oudkerk added the comment: Alternative patch (readall-chunks.patch) which delegates to RawIOBase.readall() if the file cannot be stat-ed or appears to have size zero. amount = 1 MB; time taken = 0.02 secs; rate = 64.10 MB/s amount = 2 MB; time taken = 0.02 secs; rate = 128.21 MB/s amount = 4 MB; time taken = 0.03 secs; rate = 128.20 MB/s amount = 8 MB; time taken = 0.05 secs; rate = 170.94 MB/s amount = 16 MB; time taken = 0.09 secs; rate = 170.94 MB/s amount = 32 MB; time taken = 0.16 secs; rate = 205.13 MB/s amount = 64 MB; time taken = 0.30 secs; rate = 215.92 MB/s amount = 128 MB; time taken = 0.58 secs; rate = 221.76 MB/s ---------- Added file: http://bugs.python.org/file26960/readall-chunks.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 12:20:32 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 22 Aug 2012 10:20:32 +0000 Subject: [issue11776] Constructor signatures missing in types module documentation In-Reply-To: <1302036805.33.0.506634428921.issue11776@psf.upfronthosting.co.za> Message-ID: <1345630832.91.0.639735176676.issue11776@psf.upfronthosting.co.za> Nick Coghlan added the comment: The first easy part of this patch is to document the signatures for types in that module where that info is available in the docstring: CodeType FunctionType LambdaType SimpleNamespace MethodType The second easy part is that the following need to be documented as not supporting direct creation from Python code: BuiltinFunctionType BuiltinMethodType FrameType GeneratorType GetSetDescriptorType MemberDescriptorType TracebackType This type does support direct creation and should be documented appropriately, but the docs should also direct readers to the preferred API in the imp module: ModuleType (imp.new_module) Finally, this one is missing both a docstring *and* signature documentation: MappingProxyType It's a simple API that accepts a single parameter (which must be a mapping) and returns a read-only view of the original mapping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 12:57:01 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 22 Aug 2012 10:57:01 +0000 Subject: [issue15758] 500x speed up for Popen.communicate() on Windows In-Reply-To: <1345630092.23.0.0120406314501.issue15758@psf.upfronthosting.co.za> Message-ID: <1345632821.3392.0.camel@localhost.localdomain> Antoine Pitrou added the comment: > Alternative patch (readall-chunks.patch) which delegates to > RawIOBase.readall() if the file cannot be stat-ed or appears to have > size zero. It seems we could do both (fix the resizing logic, and fallback on chunks if the size is unknown). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 13:12:45 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 22 Aug 2012 11:12:45 +0000 Subject: [issue7741] Allow multiple statements in code.InteractiveConsole.push In-Reply-To: <1263912723.35.0.93131684665.issue7741@psf.upfronthosting.co.za> Message-ID: <1345633965.7.0.518897063365.issue7741@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 13:21:56 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 22 Aug 2012 11:21:56 +0000 Subject: [issue15762] Windows 8 certification In-Reply-To: <1345625605.38.0.633732854192.issue15762@psf.upfronthosting.co.za> Message-ID: <1345634516.54.0.342366457974.issue15762@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- assignee: eric.araujo -> components: +Windows -Distutils nosy: +loewis versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 13:22:02 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 22 Aug 2012 11:22:02 +0000 Subject: [issue15762] Windows 8 certification In-Reply-To: <1345625605.38.0.633732854192.issue15762@psf.upfronthosting.co.za> Message-ID: <1345634522.41.0.177940039247.issue15762@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +brian.curtin, tim.golden _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 13:27:56 2012 From: report at bugs.python.org (aliles) Date: Wed, 22 Aug 2012 11:27:56 +0000 Subject: [issue7741] Allow multiple statements in code.InteractiveConsole.push In-Reply-To: <1263912723.35.0.93131684665.issue7741@psf.upfronthosting.co.za> Message-ID: <1345634876.18.0.894460635271.issue7741@psf.upfronthosting.co.za> aliles added the comment: I agree that the second patch adds little value to InteractiveConsole. A third alternative would be to accept default grammar start symbol to be passed to __init__(). Although this would prevent mixing use of 'single' with 'exec'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 13:28:08 2012 From: report at bugs.python.org (Helmut Jarausch) Date: Wed, 22 Aug 2012 11:28:08 +0000 Subject: [issue15763] email non-ASCII characters in TO or FROM field doesn't work Message-ID: <1345634888.16.0.670176453288.issue15763@psf.upfronthosting.co.za> New submission from Helmut Jarausch: Trying to generate an email with Latin-1 characters in the TO or FROM field either produces an exception or produces strange values in the generated email: Using Python 3.2.3+ (3.2:481f5d9ef577+, Aug 8 2012, 10:00:28) #!/usr/bin/python3 #-*- coding: latin1 -*- import smtplib from email.message import Message import datetime import sys msg= Message() msg.set_charset('latin-1') msg['Subject'] = "*** Email Test ***" # the following gives a UnicodeDecodeError: 'ascii' codec can't decode byte 0xfc .. # in File "/usr/lib64/python3.2/email/header.py", line 281, in append # msg['From'] = FromAddr = "G?nter Gro? ".encode('iso-8859-1') # The following doesn't crash Python but generates a strange "From" string : # =?utf-8?b?R8O8bnRlciBHcm/DnyA8RW1haWxfVGVzdGVyQG51bWEtc3YuaWdwbS5yd3RoLWFhY2hlbi5kZT4=?= msg['From'] = FromAddr = "G?nter Gro? " # The same with this one msg['To'] = ToAddr = "G?nter Wei?e " DATE = datetime.datetime.utcnow().strftime('%m/%d/%Y %I:%M:%S %p') msg['Date'] = datetime.datetime.utcnow().strftime('%m/%d/%Y %I:%M:%S %p') server= smtplib.SMTP("igpm.igpm.rwth-aachen.de") # server= smtplib.SMTP('relay.skynet.be') server.set_debuglevel(9) msg.set_payload("Gedanken ?ber einen Test","iso-8859-1") # server.send_message(msg) server.sendmail(FromAddr,ToAddr,msg.as_string().encode("iso-8859-1")) server.quit() ---------- components: email messages: 168869 nosy: HWJ, barry, r.david.murray priority: normal severity: normal status: open title: email non-ASCII characters in TO or FROM field doesn't work versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 13:41:44 2012 From: report at bugs.python.org (Trent Nelson) Date: Wed, 22 Aug 2012 11:41:44 +0000 Subject: [issue15748] Various symlink test failures in test_shutil on FreeBSD In-Reply-To: <1345516038.44.0.114148239105.issue15748@psf.upfronthosting.co.za> Message-ID: <1345635704.93.0.463075664051.issue15748@psf.upfronthosting.co.za> Trent Nelson added the comment: Hmmmmm... tested against other types of file systems and didn't see any issues. Tested manually against ZFS again: % ~/src/cpython/python /tmp/test_readlink.py temp dir: /mnt/t-zfs/trent/d_6i51 path 1: /mnt/t-zfs/trent/d_6i51/qux, length 1: 27, buf 1: /mnt/t-zfs/trent/d_6i51/bar path 2: /mnt/t-zfs/trent/d_6i51/qux, length 2: 27, buf 2: /mnt/t-zfs/trent/d_6i51/bar dst: /mnt/t-zfs/trent/d_6i51/bar path 1: /mnt/t-zfs/trent/d_6i51/baz, length 1: 24, buf 1: /mnt/t-zfs/trent/d_6i51/ path 2: /mnt/t-zfs/trent/d_6i51/baz, length 2: 24, buf 2: /mnt/t-zfs/trent/d_6i51/ src: /mnt/t-zfs/trent/d_6i51/ [47136 refs] This time, src got truncated by 3 characters back down to 24. (Instead of getting rounded up by 6 from 18->24 in the previous example.) Next step: replicate with a C snippet and ping the FreeBSD developers, I guess. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 13:50:22 2012 From: report at bugs.python.org (Mike Hoy) Date: Wed, 22 Aug 2012 11:50:22 +0000 Subject: [issue12716] Reorganize os docs for files/dirs/fds In-Reply-To: <1312900904.97.0.581848486096.issue12716@psf.upfronthosting.co.za> Message-ID: <1345636222.94.0.832460357959.issue12716@psf.upfronthosting.co.za> Mike Hoy added the comment: I was attempting to create a patch for this but all I have is moving fchmod() below chmod(). I was unable to find fchmodat() in os.rst. And I need further clarification on >>Also, symbolic constants should be close to the functions they are used >>in. For example, open() flags shouldn't be in their own section. ---------- keywords: +patch nosy: +mikehoy Added file: http://bugs.python.org/file26961/issue141820-function-fchmod.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 13:57:06 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 22 Aug 2012 11:57:06 +0000 Subject: [issue15740] test_ssl failure when cacert.org CA cert in system keychain on OSX In-Reply-To: <1345472699.98.0.29406283833.issue15740@psf.upfronthosting.co.za> Message-ID: <1345636626.64.0.842462254041.issue15740@psf.upfronthosting.co.za> Ronald Oussoren added the comment: This also affects 2.7, and the patch doesn't work there. It does work when I add the call to os.putenv at module scope before (before importing ssl), but I don't really like that. It is probably necessary to do it like this though, the code that checks if the keychain integration is enabled caches its results and which means my patch only works accidentally (based on the order tests happen to be run in). I've attached a 3th version of the patch that also works with 2.7 (that is, after manually applying the patch). I'm not too happy about it though, the module now changes the environment of the entire test suite (on OSX). Annoyingly the 3th version does *not* work with 'make test' for python 3.3 , even when I change os.environ. I haven't tried to debug that yet. I'm disabling the CAcert root key in my keychain for no to be able to test patches without running into this issue. ---------- versions: +Python 2.7 Added file: http://bugs.python.org/file26962/issue15740-3.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 14:01:34 2012 From: report at bugs.python.org (aliles) Date: Wed, 22 Aug 2012 12:01:34 +0000 Subject: [issue8256] input() doesn't catch _PyUnicode_AsString() exception; io.StringIO().encoding is None In-Reply-To: <1269807316.51.0.487538621224.issue8256@psf.upfronthosting.co.za> Message-ID: <1345636894.11.0.759614231332.issue8256@psf.upfronthosting.co.za> aliles added the comment: Replicated this issue on Python 3.3b2. The cause is the 'encoding' and 'errors' attributes on io.StringIO() being None. Doctest replaces sys.stdout with a StringIO subclass. The exception raised is still a TypeError. At this point I'm unsure what the fix should be: 1. Should the exception raised be more descriptive of the problem? 2. Should io.StringIO have real values for encoding and errors? 3. Should Doctest's StingIO class provide encoding and errors? ---------- nosy: +aliles _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 14:35:43 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 22 Aug 2012 12:35:43 +0000 Subject: [issue15740] test_ssl failure when cacert.org CA cert in system keychain on OSX In-Reply-To: <1345636626.64.0.842462254041.issue15740@psf.upfronthosting.co.za> Message-ID: <1345638742.3392.12.camel@localhost.localdomain> Antoine Pitrou added the comment: Le mercredi 22 ao?t 2012 ? 11:57 +0000, Ronald Oussoren a ?crit : > I've attached a 3th version of the patch that also works with 2.7 > (that is, after manually applying the patch). I'm not too happy about > it though, the module now changes the environment of the entire test > suite (on OSX). This will fail if the ssl module has already been imported by another test. Given the workaround is so fragile, I would recommend skipping the test on OS X instead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 14:39:37 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Wed, 22 Aug 2012 12:39:37 +0000 Subject: [issue15758] 500x speed up for Popen.communicate() on Windows In-Reply-To: <1345587910.43.0.919180045188.issue15758@psf.upfronthosting.co.za> Message-ID: <1345639177.09.0.405769749591.issue15758@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > It seems we could do both (fix the resizing logic, and fallback on > chunks if the size is unknown). Combined patch attached. ---------- Added file: http://bugs.python.org/file26963/readall-combined.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 14:39:37 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 22 Aug 2012 12:39:37 +0000 Subject: [issue15740] test_ssl failure when cacert.org CA cert in system keychain on OSX In-Reply-To: <1345472699.98.0.29406283833.issue15740@psf.upfronthosting.co.za> Message-ID: <1345639177.49.0.858670498664.issue15740@psf.upfronthosting.co.za> Ronald Oussoren added the comment: There is no need to unconditionally skip the test. The cacert.org root certificate is not present on most systems, I just happened to have imported it into my keychain. I've removed the cacert root from my keychain and test_ssl now passed without a patch. I agree that is it not worthwhile to pursue this further and will therefore close this issue as "wont fix". ---------- resolution: -> wont fix stage: -> committed/rejected status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 14:40:55 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 22 Aug 2012 12:40:55 +0000 Subject: [issue15716] Ability to specify the PYTHONPATH via a command line flag In-Reply-To: <1345164027.44.0.397805734201.issue15716@psf.upfronthosting.co.za> Message-ID: <3X27dx5hTTzQ6Y@mail.python.org> Roundup Robot added the comment: New changeset 526c6262d91f by Ronald Oussoren in branch '3.2': Fix for issue 15716: interpreter could crash when PYTHONEXECUTABLE was set on Mac OS X. http://hg.python.org/cpython/rev/526c6262d91f New changeset ae51329f9893 by Ronald Oussoren in branch 'default': Fix for issue 15716: interpreter could crash when PYTHONEXECUTABLE was set on Mac OS X. http://hg.python.org/cpython/rev/ae51329f9893 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 14:43:25 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 22 Aug 2012 12:43:25 +0000 Subject: [issue15761] Setting PYTHONEXECUTABLE can cause segfaults on OS X In-Reply-To: <1345623707.33.0.86377230375.issue15761@psf.upfronthosting.co.za> Message-ID: <1345639405.24.0.806059627749.issue15761@psf.upfronthosting.co.za> Ronald Oussoren added the comment: committed a patch in revisions 526c6262d91f and ae51329f9893. Those won't end up as messages in this issue due to a typo in the check-in message. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 14:44:26 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 22 Aug 2012 12:44:26 +0000 Subject: [issue15716] Ability to specify the PYTHONPATH via a command line flag In-Reply-To: <1345164027.44.0.397805734201.issue15716@psf.upfronthosting.co.za> Message-ID: <1345639466.77.0.295829281861.issue15716@psf.upfronthosting.co.za> Ronald Oussoren added the comment: My fingers are too thick. The two changesets in msg168877 are for issue 15761, not this one. Sorry about the noise. ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 14:48:34 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 22 Aug 2012 12:48:34 +0000 Subject: [issue8256] input() doesn't catch _PyUnicode_AsString() exception; io.StringIO().encoding is None In-Reply-To: <1269807316.51.0.487538621224.issue8256@psf.upfronthosting.co.za> Message-ID: <1345639714.52.0.819527441248.issue8256@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > I suggest that since PyOS_Readline() write the prompt to stderr, the > conversion uses the encoding of stderr. Agreed with Amaury. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 14:51:12 2012 From: report at bugs.python.org (Jens Henrik Leonhard Jensen) Date: Wed, 22 Aug 2012 12:51:12 +0000 Subject: [issue15764] Sqlite3 performance Message-ID: <1345639872.28.0.424388144832.issue15764@psf.upfronthosting.co.za> New submission from Jens Henrik Leonhard Jensen: The _sqlite modules uses sqlite3_prepare and not sqlite3_prepare_v2. With sqlite3_prepare_v2 enables more optiomation. Workaround: Do not use parameters as the right hand argument to GLOB or LIKE. For more documentation see http://www.sqlite.org/optoverview.html. ---------- components: Extension Modules files: db-test.py messages: 168881 nosy: jhlj priority: normal severity: normal status: open title: Sqlite3 performance type: performance versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file26964/db-test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 14:57:51 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 22 Aug 2012 12:57:51 +0000 Subject: [issue15758] 500x speed up for Popen.communicate() on Windows In-Reply-To: <1345587910.43.0.919180045188.issue15758@psf.upfronthosting.co.za> Message-ID: <1345640271.3.0.537269840101.issue15758@psf.upfronthosting.co.za> Antoine Pitrou added the comment: If new_buffersize() is only used with HAVE_FSTAT, then its code can probably be simplified. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 15:11:15 2012 From: report at bugs.python.org (Trent Nelson) Date: Wed, 22 Aug 2012 13:11:15 +0000 Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS In-Reply-To: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za> Message-ID: <1345641075.39.0.242328923498.issue15745@psf.upfronthosting.co.za> Trent Nelson added the comment: Looks like it's not specific to just FreeBSD, no ZFS. From a new NetBSD slave I set up: ====================================================================== FAIL: test_futimes_ns (test.test_os.StatAttributeTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/cpython/buildslave/3.x.snakebite-netbsd51-x86-1/build/Lib/test/test_os.py", line 369, in test_futimes_ns self._test_utime_ns(futimes_ns, test_dir=False) File "/home/cpython/buildslave/3.x.snakebite-netbsd51-x86-1/build/Lib/test/test_os.py", line 339, in _test_utime_ns self._test_utime(self.fname, getattr_ns, set_times_ns, ten_s) File "/home/cpython/buildslave/3.x.snakebite-netbsd51-x86-1/build/Lib/test/test_os.py", line 318, in _test_utime self.assertEqual(attr(st0, "st_mtime"), attr(st1, "st_mtime")) AssertionError: 1345639042446725659 != 1345639042446725000 ====================================================================== FAIL: test_lutimes_ns (test.test_os.StatAttributeTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/cpython/buildslave/3.x.snakebite-netbsd51-x86-1/build/Lib/test/test_os.py", line 362, in test_lutimes_ns self._test_utime_ns(lutimes_ns) File "/home/cpython/buildslave/3.x.snakebite-netbsd51-x86-1/build/Lib/test/test_os.py", line 339, in _test_utime_ns self._test_utime(self.fname, getattr_ns, set_times_ns, ten_s) File "/home/cpython/buildslave/3.x.snakebite-netbsd51-x86-1/build/Lib/test/test_os.py", line 318, in _test_utime self.assertEqual(attr(st0, "st_mtime"), attr(st1, "st_mtime")) AssertionError: 1345639042450323780 != 1345639042450323000 ====================================================================== FAIL: test_utime (test.test_os.StatAttributeTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/cpython/buildslave/3.x.snakebite-netbsd51-x86-1/build/Lib/test/test_os.py", line 331, in test_utime self._test_utime(self.fname, getattr, utime, 10) File "/home/cpython/buildslave/3.x.snakebite-netbsd51-x86-1/build/Lib/test/test_os.py", line 319, in _test_utime self.assertEqual(attr(st0, "st_atime"), attr(st1, "st_atime")) AssertionError: 1345639042.4583352 != 1345639042.458335 ====================================================================== FAIL: test_utime_ns (test.test_os.StatAttributeTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/cpython/buildslave/3.x.snakebite-netbsd51-x86-1/build/Lib/test/test_os.py", line 346, in test_utime_ns self._test_utime_ns(utime_ns) File "/home/cpython/buildslave/3.x.snakebite-netbsd51-x86-1/build/Lib/test/test_os.py", line 339, in _test_utime_ns self._test_utime(self.fname, getattr_ns, set_times_ns, ten_s) File "/home/cpython/buildslave/3.x.snakebite-netbsd51-x86-1/build/Lib/test/test_os.py", line 318, in _test_utime self.assertEqual(attr(st0, "st_mtime"), attr(st1, "st_mtime")) AssertionError: 1345639042463150626 != 1345639042463150000 ---------------------------------------------------------------------- (from http://buildbot.python.org/all/builders/x86%20NetBSD%205.1.2%20%5BSB%5D%203.x/builds/0/steps/test/logs/stdio) Exact same symptoms as the original FreeBSD issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 16:02:59 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 22 Aug 2012 14:02:59 +0000 Subject: [issue15758] 500x speed up for Popen.communicate() on Windows In-Reply-To: <1345587910.43.0.919180045188.issue15758@psf.upfronthosting.co.za> Message-ID: <1345644179.29.0.0241343783685.issue15758@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 16:05:29 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 22 Aug 2012 14:05:29 +0000 Subject: [issue15758] 500x speed up for Popen.communicate() on Windows In-Reply-To: <1345587910.43.0.919180045188.issue15758@psf.upfronthosting.co.za> Message-ID: <1345644329.57.0.60892829892.issue15758@psf.upfronthosting.co.za> STINNER Victor added the comment: I'm lost, there are too much patches. Could you please remove old/useless patches? Patching the subprocess module is not a good solution: if there is an issue in the io module, the io module should be fixed, and so this patch can be removed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 16:12:16 2012 From: report at bugs.python.org (Trent Nelson) Date: Wed, 22 Aug 2012 14:12:16 +0000 Subject: [issue15765] test_getcwd_long_pathnames (in test_posix) kills NetBSD Message-ID: <1345644735.97.0.561553846154.issue15765@psf.upfronthosting.co.za> New submission from Trent Nelson: The 2.7 builds of both my NetBSD slaves keep hanging on test_posix (and eventually time out after an hour). Running the test manually: netbsd51-x86-1$ pwd /home/cpython/2.7 netbsd51-x86-1$ b/test/regrtest.py -uall -rwW -v test_posix < == CPython 2.7.3+ (2.7:c1c45755397b, Aug 22 2012, 14:05:02) [GCC 4.1.3 20080704 prerelease (NetBSD nb2 20081120)] == NetBSD-5.1.2-i386-32bit-ELF little-endian == /home/cpython/2.7/build/test_python_10630 Testing with flags: sys.flags(debug=0, py3k_warning=1, division_warning=1, division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=1, tabcheck=2, verbose=0, unicode=0, bytes_warning=0, hash_randomization=1) Using random seed 2040018 test_posix testNoArgFunctions (test.test_posix.PosixTester) ... ok test_access (test.test_posix.PosixTester) ... ok test_chdir (test.test_posix.PosixTester) ... ok test_chflags (test.test_posix.PosixTester) ... ok test_chown (test.test_posix.PosixTester) ... ok test_confstr (test.test_posix.PosixTester) ... ok test_dup (test.test_posix.PosixTester) ... ok test_dup2 (test.test_posix.PosixTester) ... ok test_fchown (test.test_posix.PosixTester) ... ok test_fdopen (test.test_posix.PosixTester) ... ok test_fstat (test.test_posix.PosixTester) ... ok test_fstatvfs (test.test_posix.PosixTester) ... ok test_ftruncate (test.test_posix.PosixTester) ... ok test_getcwd_long_pathnames (test.test_posix.PosixTester) ... load: 0.50 cmd: python 10630 [runnable] 0.27u 13.07s 46% 10976k load: 0.87 cmd: python 10630 [runnable] 0.27u 94.24s 98% 10976k ^C^C Placeholder issue at the moment. ....although this looks pretty dodgy: os.chdir(dirname) try: os.getcwd() if current_path_length < 4099: _create_and_do_getcwd(dirname, current_path_length + len(dirname) + 1) ---------- assignee: trent messages: 168885 nosy: trent priority: normal severity: normal status: open title: test_getcwd_long_pathnames (in test_posix) kills NetBSD type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 16:15:59 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 22 Aug 2012 14:15:59 +0000 Subject: [issue15764] Sqlite3 performance In-Reply-To: <1345639872.28.0.424388144832.issue15764@psf.upfronthosting.co.za> Message-ID: <1345644959.71.0.450795193818.issue15764@psf.upfronthosting.co.za> STINNER Victor added the comment: Such change cannot be done in a version older than Python 3.4 (older versions only accept bugfixes, this is an improvment). ---------- nosy: +haypo versions: -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 16:21:05 2012 From: report at bugs.python.org (Ralf Schmitt) Date: Wed, 22 Aug 2012 14:21:05 +0000 Subject: [issue15758] 500x speed up for Popen.communicate() on Windows In-Reply-To: <1345587910.43.0.919180045188.issue15758@psf.upfronthosting.co.za> Message-ID: <1345645265.83.0.957164271002.issue15758@psf.upfronthosting.co.za> Changes by Ralf Schmitt : ---------- nosy: +schmir _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 16:27:30 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 22 Aug 2012 14:27:30 +0000 Subject: [issue15748] Various symlink test failures in test_shutil on FreeBSD In-Reply-To: <1345516038.44.0.114148239105.issue15748@psf.upfronthosting.co.za> Message-ID: <1345645650.15.0.985324522563.issue15748@psf.upfronthosting.co.za> STINNER Victor added the comment: I don't understand if the issue comes from symlink() or readlink(). Can you reproduce the issue using commands on the command line? $ ln -s setup.py link `link' -> `setup.py' $ readlink link setup.py (You may need to test different length for filenames.) Do you only have the issue with ZFS, or with other file systems? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 16:46:40 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 22 Aug 2012 14:46:40 +0000 Subject: [issue15763] email non-ASCII characters in TO or FROM field doesn't work In-Reply-To: <1345634888.16.0.670176453288.issue15763@psf.upfronthosting.co.za> Message-ID: <1345646800.3.0.302200567168.issue15763@psf.upfronthosting.co.za> R. David Murray added the comment: Doing non-ASCII email in python before 3.3 is a bit of a pain and not as well documented as it should be. 3.3 will work more like you expect, if you use the new provisional policies (which are intended to become standard in 3.4, after a the bake-in period in 3.3). For 3.2, you need to handle encoding addresses using utils.formataddr and header.Header: >>> h = Header(header_name='Sender') >>> h.append("?ric", 'latin-1') >>> h.append('') >>> h.encode() '=?iso-8859-1?q?=C9ric?= ' >>> m = Message() >>> m['Sender'] = h >>> print(m) Sender: =?iso-8859-1?q?=C9ric?= In 3.3 this will work: >>> m = Message() >>> m['Sender'] = formataddr(('?ric', 'eric at example.com')) >>> print(m) Sender: =?iso-8859-1?q?=C9ric?= But even better, so will this: >>> m = Message(policy=policy.SMTP) >>> m['From'] = "G?nter Wei?e " >>> print(m) From: =?utf-8?q?G=C3=BCnter_Wei=C3=9Fe?= ---------- resolution: -> works for me stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 16:52:15 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 22 Aug 2012 14:52:15 +0000 Subject: [issue1207589] Right Click Context Menu Message-ID: <1345647135.07.0.318668028725.issue1207589@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +serwy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 16:53:07 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 22 Aug 2012 14:53:07 +0000 Subject: [issue5088] optparse: inconsistent default value for append actions In-Reply-To: <1233140307.53.0.685208172708.issue5088@psf.upfronthosting.co.za> Message-ID: <1345647187.76.0.562126187414.issue5088@psf.upfronthosting.co.za> R. David Murray added the comment: It may or may not be too old to deserve comments, but it is too old to do anything about it. This can't change for backward compatibility reasons, and since optparse is deprecated in favor of argparse it isn't getting any new features. We still need to apply the doc patch, though...(makes note to self). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 16:57:49 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 22 Aug 2012 14:57:49 +0000 Subject: [issue15764] Sqlite3 performance In-Reply-To: <1345639872.28.0.424388144832.issue15764@psf.upfronthosting.co.za> Message-ID: <1345647469.92.0.996438271295.issue15764@psf.upfronthosting.co.za> Martin v. L?wis added the comment: This is a duplicate of #9303 ---------- nosy: +loewis resolution: -> duplicate status: open -> closed superseder: -> Migrate sqlite3 module to _v2 API to enhance performance _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 17:02:54 2012 From: report at bugs.python.org (Jeff Knupp) Date: Wed, 22 Aug 2012 15:02:54 +0000 Subject: [issue15316] runpy swallows ImportError information with relative imports In-Reply-To: <1341898758.4.0.623810416258.issue15316@psf.upfronthosting.co.za> Message-ID: <1345647774.98.0.43099508726.issue15316@psf.upfronthosting.co.za> Changes by Jeff Knupp : ---------- nosy: +Jeff.Knupp _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 17:10:45 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 22 Aug 2012 15:10:45 +0000 Subject: [issue15762] Windows 8 certification In-Reply-To: <1345625605.38.0.633732854192.issue15762@psf.upfronthosting.co.za> Message-ID: <1345648245.84.0.903638911829.issue15762@psf.upfronthosting.co.za> Martin v. L?wis added the comment: This is not an issue of Python, but py2exe; please report it to the py2exe maintainers. ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 17:40:37 2012 From: report at bugs.python.org (Andrew McNabb) Date: Wed, 22 Aug 2012 15:40:37 +0000 Subject: [issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse) In-Reply-To: <1279836939.11.0.811316280273.issue9334@psf.upfronthosting.co.za> Message-ID: <1345650037.88.0.984363151616.issue9334@psf.upfronthosting.co.za> Changes by Andrew McNabb : ---------- nosy: +amcnabb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 17:41:23 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 22 Aug 2012 15:41:23 +0000 Subject: [issue15766] _imp.load_dynamic() does crash with non-ASCII path and uses the wrong encoding Message-ID: <1345650083.26.0.403963695134.issue15766@psf.upfronthosting.co.za> New submission from STINNER Victor: _imp.load_dynamic() use UTF-8 (PyUnicode_FromString) to decode the error message from dlerror(), whereas the locale encoding should be used. The path is decoded from UTF-8, whereas the filesystem encoding should be used. As a result, error_ob and path can be NULL, whereas Py_DECREF() is used and so Python does crash (SIGSEGV). Attached patch should avoid a crash, but I'm not sure that it is enough to support non-ASCII path: pathname is "./" is the path is not an absolute path. PyOS_snprintf(pathbuf, sizeof(pathbuf), "./%-.255s", pathname); should maybe be replaced with pathbytes = PyBytes_FromFormat("./%s", pathname); ---------- components: Tkinter files: imp.patch keywords: patch messages: 168892 nosy: brett.cannon, haypo priority: normal severity: normal status: open title: _imp.load_dynamic() does crash with non-ASCII path and uses the wrong encoding type: crash versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file26965/imp.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 17:46:50 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 22 Aug 2012 15:46:50 +0000 Subject: [issue15766] _imp.load_dynamic() does crash with non-ASCII path and uses the wrong encoding In-Reply-To: <1345650083.26.0.403963695134.issue15766@psf.upfronthosting.co.za> Message-ID: <3X2CmT4vJpzQMh@mail.python.org> Roundup Robot added the comment: New changeset eaac55703796 by Victor Stinner in branch 'default': Issue #15766: Fix a crash in imp.load_dynamic() on PyUnicode_FromString() failure http://hg.python.org/cpython/rev/eaac55703796 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 17:49:58 2012 From: report at bugs.python.org (Stefan Mihaila) Date: Wed, 22 Aug 2012 15:49:58 +0000 Subject: [issue15642] Integrate pickle protocol version 4 GSoC work by Stefan Mihaila In-Reply-To: <1344890920.23.0.695633734046.issue15642@psf.upfronthosting.co.za> Message-ID: <1345650598.98.0.0865781880473.issue15642@psf.upfronthosting.co.za> Stefan Mihaila added the comment: >- I don't really like the idea of changing the semantics of the PUT and GET opcodes. I would prefer new opcodes if possible. Well, the semantics of PUT and GET haven't really changed. It's just that the PUT opcode is not generated anymore and memoization is done "in agreement" (i.e. both the pickler and the unpickler know when to memoize so their memo tables stay in sync). So, in fact, it's the semantics of the other opcodes that has slightly changed. >- I would like to see benchmarks for this change. I've tried the following two snippets with timeit: ./python3.3 -m timeit \ -s 'from pickle import dumps' \ -s 'd=["a"]*100' 'dumps(d,3)' # replace 3 with 4 for comparison ./python3.3 -m timeit \ -s 'from pickle import dumps' \ -s 'd=list(map(chr,range(0,256)))' \ 'dumps(d,3)' # replace 3 with 4 for comparison # you can also use loads(dumps(d,3)) here to benchmark both # operations at once The first one generates 99 BINGET opcodes. It generates 1 BINPUT opcode in pickle3 and no BINPUT opcodes in pickle4. There appears no noticeable speed difference. The second one generates no BINGET opcodes. It generates no BINPUT opcodes in v4, respectively 256 BINPUT opcodes in v3. It appears the v4 one is slightly faster, but I have a hard time comparing correctly, given that the measurements seem to have a very large standard deviation (v4 gets times somewhere between 32.3 and 44.2, whereas v3 gets times between 37.7 and 52.2). I'm not sure this is the best way to benchmark, so let me know what is usually used. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 18:00:03 2012 From: report at bugs.python.org (Torsten Landschoff) Date: Wed, 22 Aug 2012 16:00:03 +0000 Subject: [issue14965] super() and property inheritance behavior In-Reply-To: <1338433441.66.0.975494137492.issue14965@psf.upfronthosting.co.za> Message-ID: <1345651203.3.0.091313114742.issue14965@psf.upfronthosting.co.za> Torsten Landschoff added the comment: I stumbled across this omission as well in 2010 and brought this up on python-dev: http://mail.python.org/pipermail/python-dev/2010-April/099672.html There were no replies, but perhaps my post adds a bit of information and also there is another patch linked from there. I attached my patch from 2010 for reference. ---------- nosy: +torsten Added file: http://bugs.python.org/file26966/44560_44559.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 18:33:34 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 22 Aug 2012 16:33:34 +0000 Subject: [issue15316] runpy swallows ImportError information with relative imports In-Reply-To: <1341898758.4.0.623810416258.issue15316@psf.upfronthosting.co.za> Message-ID: <1345653214.23.0.727702490854.issue15316@psf.upfronthosting.co.za> Brett Cannon added the comment: It has nothing to do with runpy and __main__.py and everything to do with rev 78619:0d52f125dd32 (which fixed issue #15715) which was done to ignore bogus names in fromlist. If you simply change the import line to "import foo.bar" then you get the expected result. The options I see to solve this without invalidating issue #15715 is: 1) Parse the ImportError message to notice that it was a lookup failure and not some other ImportError (ewww) 2) Importlib has to tag every exception is raises because of a finder failure to know when an ImportError was triggered because the module wasn't found (less eww, but still brittle as it means only importlib or people aware of the flag will have the expected semantics) 3) Create a ModuleNotFoundError exception that subclasses ImportError and catch that (breaks doctests and introduces a new exception that people will need to be aware of, plus the question of whether it should just exist in importlib or be a builtin) 4) change importlib._bootstrap._handle_fromlist (and various other bits of importlib code) to call _find_module() and silently ignore when no finder is found as desired (probably need to add a flag to _find_and_load() to signal whether finder failure just returns None or raises ImportError) While I prefer 3, I think it's a bit late in the release to try to introduce a new exception to begin separating the meaning of 16 different ``raise ImportError`` cases in importlib._bootstrap based on inheritance. My gut says 4 is the best solution given the timeframe. I should be able to get a patch in on Friday if that works for people. ---------- assignee: -> brett.cannon priority: normal -> release blocker stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 18:47:52 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 22 Aug 2012 16:47:52 +0000 Subject: [issue15642] Integrate pickle protocol version 4 GSoC work by Stefan Mihaila In-Reply-To: <1345650598.98.0.0865781880473.issue15642@psf.upfronthosting.co.za> Message-ID: <1345653875.3317.1.camel@localhost.localdomain> Antoine Pitrou added the comment: Le mercredi 22 ao?t 2012 ? 15:49 +0000, Stefan Mihaila a ?crit : > I'm not sure this is the best way to benchmark, so let me know what is > usually used. http://hg.python.org/benchmarks/ has pickling benchmarks, you may have to modify them to test different pickling protocols. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 19:04:35 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 22 Aug 2012 17:04:35 +0000 Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS In-Reply-To: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za> Message-ID: <1345655075.54.0.367440606916.issue15745@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > AssertionError: 1345639042446725659 != 1345639042446725000 Well, by the looks of it, some filesystems only have microsecond precision? Would be best to confirm with a {Free,Net}BSD mailing-list, I think. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 19:29:38 2012 From: report at bugs.python.org (Matthias Klose) Date: Wed, 22 Aug 2012 17:29:38 +0000 Subject: [issue9374] urlparse should parse query and fragment for arbitrary schemes In-Reply-To: <1280012321.31.0.791086727515.issue9374@psf.upfronthosting.co.za> Message-ID: <1345656578.53.0.598996518451.issue9374@psf.upfronthosting.co.za> Matthias Klose added the comment: this breaks the following upstream builds: createrepo, linkchecker, gwibber, pegasus-wm there is no need to remove is_hierarchical on the branches. it's not used by urlparse at all. is it safe to just keep the uses_query and uses_fragment lists on the branches as well? raising to a release blocker, I consider this as a regression for the 2.7 and 3.2 release series. ---------- nosy: +benjamin.peterson, doko, georg.brandl priority: normal -> release blocker resolution: fixed -> remind _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 19:33:14 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 22 Aug 2012 17:33:14 +0000 Subject: [issue15766] _imp.load_dynamic() does crash with non-ASCII path and uses the wrong encoding In-Reply-To: <1345650083.26.0.403963695134.issue15766@psf.upfronthosting.co.za> Message-ID: <1345656794.88.0.684060014752.issue15766@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The patch is still insufficient. Any of the functions can fail because of memory exhaustion, so a fix should really use the standard error handling procedure. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 19:44:11 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 22 Aug 2012 17:44:11 +0000 Subject: [issue11776] Constructor signatures missing in types module documentation In-Reply-To: <1302036805.33.0.506634428921.issue11776@psf.upfronthosting.co.za> Message-ID: <1345657451.44.0.73368479333.issue11776@psf.upfronthosting.co.za> Terry J. Reedy added the comment: "class types.MappingProxyType(mapping) Read-only proxy of a mapping. ..." is the only class in 7.11.2. Standard Interpreter Types that *does* have a signature given in the text. However, the extra word 'class' here and for SimpleNamespace confuses me (I do not understand what it is intended to convey) and seems unnecessary. The two entries with signatures in 7.11.1 do not have that. Once parenthesized signatures are given, perhaps one statement at the top like "Classes listed without a signature cannot be directly created from Python code." would be sufficient. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 19:51:50 2012 From: report at bugs.python.org (Stefan Krah) Date: Wed, 22 Aug 2012 17:51:50 +0000 Subject: [issue15765] test_getcwd_long_pathnames (in test_posix) kills NetBSD In-Reply-To: <1345644735.97.0.561553846154.issue15765@psf.upfronthosting.co.za> Message-ID: <1345657910.84.0.584436969945.issue15765@psf.upfronthosting.co.za> Stefan Krah added the comment: The timeouts on NetBSD and OpenBSD are very likely related to bugs in the user-space thread libraries. See also #8714. I would recommend running these bots --without-threads. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 21:08:02 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 22 Aug 2012 19:08:02 +0000 Subject: [issue15316] runpy swallows ImportError information with relative imports In-Reply-To: <1341898758.4.0.623810416258.issue15316@psf.upfronthosting.co.za> Message-ID: <1345662482.28.0.00688679958556.issue15316@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Here is a formal unit test case that passes in 3.2 but not in 3.3 (a "simpler" case not using __main__.py). (script_helper.create_empty_file() doesn't seem to be available in 3.2.) ---------- keywords: +patch Added file: http://bugs.python.org/file26967/issue-15316-failing-test-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 21:12:40 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 22 Aug 2012 19:12:40 +0000 Subject: [issue15316] runpy swallows ImportError information with relative imports In-Reply-To: <1341898758.4.0.623810416258.issue15316@psf.upfronthosting.co.za> Message-ID: <1345662760.2.0.438174754363.issue15316@psf.upfronthosting.co.za> Brett Cannon added the comment: Thanks for the test, Chris. It can probably be simplified using the utilities in test_importlib (e.g. managing the cleanup of sys.path, using mocked loaders to raise the exception instead of having to write to the file system, etc.), but otherwise the idea of the test is accurate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 21:18:13 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 22 Aug 2012 19:18:13 +0000 Subject: [issue15316] runpy swallows ImportError information with relative imports In-Reply-To: <1341898758.4.0.623810416258.issue15316@psf.upfronthosting.co.za> Message-ID: <1345663093.06.0.781052008567.issue15316@psf.upfronthosting.co.za> Chris Jerdonek added the comment: You're welcome, Brett. I'll let you or someone else recast the test using the latest preferred techniques. I was just using the style of the immediately surrounding tests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 21:45:18 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 22 Aug 2012 19:45:18 +0000 Subject: [issue15767] add ModuleNotFoundError Message-ID: <1345664718.23.0.712313947558.issue15767@psf.upfronthosting.co.za> New submission from Eric Snow: In issue 15316 (msg168896, Brett Cannon): Create a ModuleNotFoundError exception that subclasses ImportError and catch that (breaks doctests and introduces a new exception that people will need to be aware of, plus the question of whether it should just exist in importlib or be a builtin) While it's too late to go into 3.3, this is a reasonable addition for 3.4. Perhaps other ImportError subclasses are warranted, but they can be addressed separately. ---------- components: Interpreter Core messages: 168906 nosy: brett.cannon, eric.snow priority: normal severity: normal stage: needs patch status: open title: add ModuleNotFoundError type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 21:46:30 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 22 Aug 2012 19:46:30 +0000 Subject: [issue15316] runpy swallows ImportError information with relative imports In-Reply-To: <1341898758.4.0.623810416258.issue15316@psf.upfronthosting.co.za> Message-ID: <1345664790.08.0.83283431306.issue15316@psf.upfronthosting.co.za> Eric Snow added the comment: > While I prefer 3, I think it's a bit late in the release to try to > introduce a new exception to begin separating the meaning of 16 > different ``raise ImportError`` cases in importlib._bootstrap based on > inheritance. My gut says 4 is the best solution given the timeframe. Agreed. I still think option 3 would be suitable and have created issue 15767 to track it. ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 22:14:50 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 22 Aug 2012 20:14:50 +0000 Subject: [issue15767] add ModuleNotFoundError In-Reply-To: <1345664718.23.0.712313947558.issue15767@psf.upfronthosting.co.za> Message-ID: <1345666490.75.0.437898986491.issue15767@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 22 23:09:13 2012 From: report at bugs.python.org (Larry Hastings) Date: Wed, 22 Aug 2012 21:09:13 +0000 Subject: [issue15748] Various symlink test failures in test_shutil on FreeBSD In-Reply-To: <1345516038.44.0.114148239105.issue15748@psf.upfronthosting.co.za> Message-ID: <1345669753.33.0.12092241161.issue15748@psf.upfronthosting.co.za> Larry Hastings added the comment: haypo: If a series of shell commands duplicated the problem, then okay, but I suspect the problem has to do with persistent state in the process and will only be reproducible with a C program. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 02:03:05 2012 From: report at bugs.python.org (Eric Cousineau) Date: Thu, 23 Aug 2012 00:03:05 +0000 Subject: [issue15768] re.sub() with re.MULTILINE not replacing all occurrences Message-ID: <1345680185.37.0.726682909185.issue15768@psf.upfronthosting.co.za> New submission from Eric Cousineau: [Copying post I made here: http://stackoverflow.com/questions/12082886/bug-in-python-regex-re-sub-with-re-multiline] I'm noticing some odd behavior in Python's Regex library, and I'm not sure if I'm doing something wrong. If I run a regex on it using re.sub(), with re.MULTILINE. It seems to only replace the first few occurrences. It replaces all occurrences if I turn off re.MULTILINE, use re.subn(..., count = 0, flags = re.MULTILINE), or compile the regex using re.compile(..., re.MULTILINE). I am running Python 2.7 on Ubuntu 12.04. I've posted a random example on: http://pastebin.com/49SU8Mm2 - Output from terminal http://codepad.org/2RO2iS4O - Script, confirming behavior (except for re.subn(), which is different on 2.5) ---------- components: Regular Expressions messages: 168909 nosy: eacousineau, ezio.melotti, mrabarnett priority: normal severity: normal status: open title: re.sub() with re.MULTILINE not replacing all occurrences type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 02:05:03 2012 From: report at bugs.python.org (Eric Cousineau) Date: Thu, 23 Aug 2012 00:05:03 +0000 Subject: [issue15768] re.sub() with re.MULTILINE not replacing all occurrences In-Reply-To: <1345680185.37.0.726682909185.issue15768@psf.upfronthosting.co.za> Message-ID: <1345680303.25.0.0115996385766.issue15768@psf.upfronthosting.co.za> Eric Cousineau added the comment: Looks like I was just writing my code incorrectly - I should have been using re.sub(..., flags = re.MULTILINE). That explains it. ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 02:34:39 2012 From: report at bugs.python.org (Larry Hastings) Date: Thu, 23 Aug 2012 00:34:39 +0000 Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS In-Reply-To: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za> Message-ID: <1345682079.37.0.341611916703.issue15745@psf.upfronthosting.co.za> Larry Hastings added the comment: Yes, but the code should still work. The test that's failing reads the atime/mtime from a file, then writes those values out to the file, then reads again to confirm that they're the same. That should always work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 03:11:30 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 23 Aug 2012 01:11:30 +0000 Subject: [issue665194] datetime-RFC2822 roundtripping Message-ID: <1345684290.38.0.284476000715.issue665194@psf.upfronthosting.co.za> R. David Murray added the comment: I think restricting the test is fine. If we find a platform-specific bug on another platform we can add a test specific to that platform when we fix the bug. Can you provide the test? I'm going to commit what I've got at this point to make sure I don't miss the RC. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 03:24:51 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 23 Aug 2012 01:24:51 +0000 Subject: [issue665194] datetime-RFC2822 roundtripping In-Reply-To: <1345684290.38.0.284476000715.issue665194@psf.upfronthosting.co.za> Message-ID: Alexander Belopolsky added the comment: Please commit. I'll add the test. On Wed, Aug 22, 2012 at 9:11 PM, R. David Murray wrote: > > R. David Murray added the comment: > > I think restricting the test is fine. If we find a platform-specific bug on another platform we can add a test specific to that platform when we fix the bug. > > Can you provide the test? I'm going to commit what I've got at this point to make sure I don't miss the RC. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- nosy: +Alexander.Belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 03:34:28 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 23 Aug 2012 01:34:28 +0000 Subject: [issue665194] datetime-RFC2822 roundtripping Message-ID: <3X2SpW4KN4zQKk@mail.python.org> Roundup Robot added the comment: New changeset 71b9cca81598 by R David Murray in branch 'default': #665194: Update email.utils.localtime to use astimezone, and fix bug. http://hg.python.org/cpython/rev/71b9cca81598 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 03:35:09 2012 From: report at bugs.python.org (Brian Turek) Date: Thu, 23 Aug 2012 01:35:09 +0000 Subject: [issue15769] urllib.request.urlopen with cafile or capath set overrides any previous Handlers Message-ID: <1345685709.12.0.30740709281.issue15769@psf.upfronthosting.co.za> New submission from Brian Turek: Using the code snippet below: cj = http.cookiejar.CookieJar() opener = urllib.request.build_opener(urllib.request.HTTPCookieProcessor()) urllib.request.install_opener(opener) request = urllib.request.Request(url, data, headers) # url is https://something sock = urllib.request.urlopen(request, cafile = 'cacert.pem') One would expect to establish a verified HTTPS connection to the host and the cookies stored in the cookie jar. Unfortunately urllib.request.urlopen, when called with cafile or capath set, calls urllib.request.build_opener without HTTPCookieProcessor included in the chain. This results in never being able to support cookies in a "verified" HTTPS connection. ---------- components: Library (Lib) messages: 168915 nosy: caligatio priority: normal severity: normal status: open title: urllib.request.urlopen with cafile or capath set overrides any previous Handlers type: behavior versions: Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 03:36:19 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 23 Aug 2012 01:36:19 +0000 Subject: [issue665194] datetime-RFC2822 roundtripping Message-ID: <1345685779.68.0.214815831247.issue665194@psf.upfronthosting.co.za> R. David Murray added the comment: Leaving open until the test is committed. ---------- assignee: r.david.murray -> resolution: accepted -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 03:37:10 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 23 Aug 2012 01:37:10 +0000 Subject: [issue665194] datetime-RFC2822 roundtripping Message-ID: <1345685830.0.0.491543337571.issue665194@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- assignee: -> belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 03:41:04 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 23 Aug 2012 01:41:04 +0000 Subject: [issue15769] urllib.request.urlopen with cafile or capath set overrides any previous Handlers In-Reply-To: <1345685709.12.0.30740709281.issue15769@psf.upfronthosting.co.za> Message-ID: <1345686064.4.0.908966660422.issue15769@psf.upfronthosting.co.za> R. David Murray added the comment: I thought that was an issue when I was looking at the code the other day, but I didn't get around to testing it. Thanks for the report. ---------- nosy: +orsenthil, pitrou, r.david.murray stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 03:47:32 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 23 Aug 2012 01:47:32 +0000 Subject: [issue15207] mimetypes.read_windows_registry() uses the wrong regkey, creates wrong mappings In-Reply-To: <1340813009.36.0.80214060404.issue15207@psf.upfronthosting.co.za> Message-ID: <1345686452.72.0.443926852184.issue15207@psf.upfronthosting.co.za> R. David Murray added the comment: Unfortunately I don't feel qualified to review the patch itself since I'm not a windows user and don't currently even have a windows box to test on. Hopefully one of the windows devs will take a look; the patch looks to be fairly straightforward to evaluate if one understands _winreg. ---------- nosy: +terry.reedy stage: needs patch -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 03:52:56 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 23 Aug 2012 01:52:56 +0000 Subject: [issue665194] datetime-RFC2822 roundtripping Message-ID: <3X2TCq00QwzQHf@mail.python.org> Roundup Robot added the comment: New changeset a2d83fba8fd8 by R David Murray in branch 'default': #665194: fix variable name in exception code path. http://hg.python.org/cpython/rev/a2d83fba8fd8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 04:06:07 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 23 Aug 2012 02:06:07 +0000 Subject: [issue665194] datetime-RFC2822 roundtripping Message-ID: <3X2TW22ZKpzQQP@mail.python.org> Roundup Robot added the comment: New changeset 604222c1f8a0 by Alexander Belopolsky in branch 'default': Added test for a bug fixed in issue #665194. http://hg.python.org/cpython/rev/604222c1f8a0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 04:12:18 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 23 Aug 2012 02:12:18 +0000 Subject: [issue15570] email.header.decode_header parses differently In-Reply-To: <1344316764.02.0.79283890102.issue15570@psf.upfronthosting.co.za> Message-ID: <1345687938.1.0.0455980184088.issue15570@psf.upfronthosting.co.za> R. David Murray added the comment: Absent an argument in favor of reversion, I'm closing this. ---------- stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 05:01:58 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 23 Aug 2012 03:01:58 +0000 Subject: [issue665194] datetime-RFC2822 roundtripping Message-ID: <3X2VlT4WYjzQDd@mail.python.org> Roundup Robot added the comment: New changeset 4c134e6ba0df by Alexander Belopolsky in branch 'default': Issue #665194: Added a small optimization http://hg.python.org/cpython/rev/4c134e6ba0df ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 06:10:12 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 23 Aug 2012 04:10:12 +0000 Subject: [issue665194] datetime-RFC2822 roundtripping Message-ID: <1345695012.47.0.523011569656.issue665194@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 06:19:35 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 23 Aug 2012 04:19:35 +0000 Subject: [issue1578643] various datetime methods fail in restricted mode Message-ID: <1345695575.83.0.254894286673.issue1578643@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 07:46:47 2012 From: report at bugs.python.org (Ned Deily) Date: Thu, 23 Aug 2012 05:46:47 +0000 Subject: [issue13370] test_ctypes fails when building python with clang In-Reply-To: <1320761474.93.0.268896325495.issue13370@psf.upfronthosting.co.za> Message-ID: <1345700807.88.0.633464985662.issue13370@psf.upfronthosting.co.za> Ned Deily added the comment: I just noticed another anomaly in the patch. In x86-ffi_darwin.c there appears to be some bogus code duplicating ffi_prep_args. Could you review and clean up the patch before we apply it? ---------- stage: needs patch -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 08:36:55 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 23 Aug 2012 06:36:55 +0000 Subject: [issue15645] 2to3 Grammar pickles not created when upgrading to 3.3.0b2 In-Reply-To: <1344932180.41.0.826216341416.issue15645@psf.upfronthosting.co.za> Message-ID: <3X2bWT46flzQDV@mail.python.org> Roundup Robot added the comment: New changeset 787ed9b03ef9 by Ned Deily in branch '2.7': Issue #15645: Ensure 2to3 grammar pickles are properly installed. http://hg.python.org/cpython/rev/787ed9b03ef9 New changeset a377a4298b4e by Ned Deily in branch '3.2': Issue #15645: Ensure 2to3 grammar pickles are properly installed. http://hg.python.org/cpython/rev/a377a4298b4e New changeset b48cd7045909 by Ned Deily in branch 'default': issue #15645: null merge http://hg.python.org/cpython/rev/b48cd7045909 New changeset 995e58439b59 by Ned Deily in branch 'default': Issue #15645: Ensure 2to3 grammar pickles are properly installed. http://hg.python.org/cpython/rev/995e58439b59 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 08:36:55 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 23 Aug 2012 06:36:55 +0000 Subject: [issue14292] OS X installer build script doesn't set $CXX, so it ends up as "c++" In-Reply-To: <1331671465.67.0.741908765122.issue14292@psf.upfronthosting.co.za> Message-ID: <3X2bWV2dLkzQDV@mail.python.org> Roundup Robot added the comment: New changeset 1f27572a10ce by Ned Deily in branch 'default': Issue #14292: Ensure that the OS X installer build configures the CXX http://hg.python.org/cpython/rev/1f27572a10ce ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 08:41:25 2012 From: report at bugs.python.org (Ned Deily) Date: Thu, 23 Aug 2012 06:41:25 +0000 Subject: [issue15645] 2to3 Grammar pickles not created when upgrading to 3.3.0b2 In-Reply-To: <1344932180.41.0.826216341416.issue15645@psf.upfronthosting.co.za> Message-ID: <1345704085.79.0.327026650088.issue15645@psf.upfronthosting.co.za> Ned Deily added the comment: Fixes applied for release in 2.7.4, 3.2.4, and 3.3.0. ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed type: compile error -> versions: +Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 08:44:25 2012 From: report at bugs.python.org (Ned Deily) Date: Thu, 23 Aug 2012 06:44:25 +0000 Subject: [issue14292] OS X installer build script doesn't set $CXX, so it ends up as "c++" In-Reply-To: <1331671465.67.0.741908765122.issue14292@psf.upfronthosting.co.za> Message-ID: <1345704265.44.0.367213773714.issue14292@psf.upfronthosting.co.za> Ned Deily added the comment: Fix applied for 3.3.0. All build-installer fixes will be backported for 2.7.4 and 3.2.4. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 10:07:37 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 23 Aug 2012 08:07:37 +0000 Subject: [issue15770] _testbuffer.get_contiguous() doesn't check input arguments Message-ID: <1345709257.81.0.874456644745.issue15770@psf.upfronthosting.co.za> New submission from STINNER Victor: _testbuffer.get_contiguous() abort with an assertion error if it gets invalid arguments. Attached patch adds tests for valid values. I found this bug using my fuzzer (fusil). ---------- components: Library (Lib) files: _testbuffer.patch keywords: patch messages: 168928 nosy: haypo, skrah priority: normal severity: normal status: open title: _testbuffer.get_contiguous() doesn't check input arguments versions: Python 3.3 Added file: http://bugs.python.org/file26968/_testbuffer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 10:27:22 2012 From: report at bugs.python.org (zhuojun) Date: Thu, 23 Aug 2012 08:27:22 +0000 Subject: [issue15771] Tunple Bug? Message-ID: <1345710442.93.0.654191105563.issue15771@psf.upfronthosting.co.za> New submission from zhuojun: >>> def f(*agrs): print(agrs) >>> f(1,2) (1, 2) >>> f(1) #Is the output wrong? It should be without ','. (1,) ---------- components: None messages: 168929 nosy: zhuojun priority: normal severity: normal status: open title: Tunple Bug? type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 10:30:37 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 23 Aug 2012 08:30:37 +0000 Subject: [issue15771] Tunple Bug? In-Reply-To: <1345710442.93.0.654191105563.issue15771@psf.upfronthosting.co.za> Message-ID: <1345710637.96.0.521010141504.issue15771@psf.upfronthosting.co.za> Ezio Melotti added the comment: Tuples with one element are defined as (x,), since the comma is what really makes the tuple. ---------- assignee: -> ezio.melotti nosy: +ezio.melotti resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 10:33:12 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 23 Aug 2012 08:33:12 +0000 Subject: [issue15771] Tunple Bug? In-Reply-To: <1345710442.93.0.654191105563.issue15771@psf.upfronthosting.co.za> Message-ID: <1345710792.35.0.279616656828.issue15771@psf.upfronthosting.co.za> Ezio Melotti added the comment: See the second code block here: http://docs.python.org/py3k/tutorial/datastructures.html#tuples-and-sequences ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 10:56:33 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 23 Aug 2012 08:56:33 +0000 Subject: [issue11776] Constructor signatures missing in types module documentation In-Reply-To: <1302036805.33.0.506634428921.issue11776@psf.upfronthosting.co.za> Message-ID: <1345712193.54.0.507193878924.issue11776@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 11:52:59 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Thu, 23 Aug 2012 09:52:59 +0000 Subject: [issue15769] urllib.request.urlopen with cafile or capath set overrides any previous Handlers In-Reply-To: <1345685709.12.0.30740709281.issue15769@psf.upfronthosting.co.za> Message-ID: <1345715579.7.0.0417575692103.issue15769@psf.upfronthosting.co.za> Senthil Kumaran added the comment: I could verify this bug and also looks like a tricky one. Because when we are sending the cacert (the second time), we create a new HTTPSHandler and then build the opener again using that handler. I thought, we can use the existing opener object itself like this - - opener = build_opener(https_handler) + if _opener is None: + opener = build_opener(https_handler) + else: + opener = _opener + opener.add_handler(https_handler) But even then the problem is, the existing default HTTPSHandler will be invoked before the newly added one, as add_handler does a bisect.insert to add new handlers. Thinking what's the best way to insert this new updated HTTPS handler in front of the existing ones (without resorting to any hacks). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 12:36:12 2012 From: report at bugs.python.org (Mike Hoy) Date: Thu, 23 Aug 2012 10:36:12 +0000 Subject: [issue11776] Constructor signatures missing in types module documentation In-Reply-To: <1302036805.33.0.506634428921.issue11776@psf.upfronthosting.co.za> Message-ID: <1345718172.18.0.538909995989.issue11776@psf.upfronthosting.co.za> Mike Hoy added the comment: I used the following for: >>CodeType >>FunctionType >>LambdaType >>SimpleNamespace >>MethodType -------------------- >>> print(CodeType.__doc__) code(argcount, kwonlyargcount, nlocals, stacksize, flags, codestring, constants, names, varnames, filename, name, firstlineno, lnotab[, freevars[, cellvars]]) Create a code object. Not for the faint of heart. >>> print(FunctionType.__doc__) function(code, globals[, name[, argdefs[, closure]]]) Create a function object from a code object and a dictionary. The optional name string overrides the name from the code object. The optional argdefs tuple specifies the default argument values. The optional closure tuple supplies the bindings for free variables. >>> print(LambdaType.__doc__) function(code, globals[, name[, argdefs[, closure]]]) Create a function object from a code object and a dictionary. The optional name string overrides the name from the code object. The optional argdefs tuple specifies the default argument values. The optional closure tuple supplies the bindings for free variables. >>> print(SimpleNamespace.__doc__) A simple attribute-based namespace. namespace(**kwargs) >>> print(MethodType.__doc__) method(function, instance) Create a bound instance method object. -------------------- I left out the [] arguments. I've stopped here and uploaded a patch for the >>'first easy part'. Despite that name I suspect I will have to change quite a few things. Once this part is done then I will move on the the >>'second easy part' ---------- keywords: +patch versions: -Python 2.7, Python 3.2 Added file: http://bugs.python.org/file26969/issue11776-sigs-docs-first.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 12:55:09 2012 From: report at bugs.python.org (Brian Turek) Date: Thu, 23 Aug 2012 10:55:09 +0000 Subject: [issue15769] urllib.request.urlopen with cafile or capath set overrides any previous Handlers In-Reply-To: <1345685709.12.0.30740709281.issue15769@psf.upfronthosting.co.za> Message-ID: <1345719309.5.0.196197516015.issue15769@psf.upfronthosting.co.za> Brian Turek added the comment: I was actually going to come up with a patch that does the same thing orsenthil mentioned until I too was stymied by the use of bisect.insort Does anyone know why bisect.insort was used instead of just list.append? I don't see an obvious reason so I think just having add_handler insert new handlers at the beginning of all the respective lists would be an easy fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 12:58:03 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Thu, 23 Aug 2012 10:58:03 +0000 Subject: [issue14674] Link to & explain deviations from RFC 4627 in json module docs In-Reply-To: <1335449712.62.0.988063979534.issue14674@psf.upfronthosting.co.za> Message-ID: <1345719483.29.0.954225510034.issue14674@psf.upfronthosting.co.za> Petri Lehtinen added the comment: Using the word "scalar" sounds wrong to me. Are strings really considered scalars in Python? At least RFC 4627 doesn't talk about scalars. +Since the RFC permits RFC-compliant parsers to accept input texts that are not +RFC-compliant, this module's deserializer is technically RFC-compliant under +default settings. This might scare users. Maybe it should note that there are parameters that can be used to turn off the most "harmful" extra features (namely the Inf and NaN support). Otherwise, the additions look very good and important. ---------- nosy: +petri.lehtinen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 14:03:39 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Thu, 23 Aug 2012 12:03:39 +0000 Subject: [issue15393] JSONDecoder.raw_decode breaks on leading whitespace In-Reply-To: <1342692596.02.0.962530841473.issue15393@psf.upfronthosting.co.za> Message-ID: <1345723419.21.0.593084781854.issue15393@psf.upfronthosting.co.za> Petri Lehtinen added the comment: I think skipping preceding whitespace in raw_decode() wouldn't hurt, but skipping following whitespace would be wrong. David: Any examples of how this could break backwards compatibility? ---------- nosy: +petri.lehtinen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 14:47:25 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 23 Aug 2012 12:47:25 +0000 Subject: [issue15769] urllib.request.urlopen with cafile or capath set overrides any previous Handlers In-Reply-To: <1345685709.12.0.30740709281.issue15769@psf.upfronthosting.co.za> Message-ID: <1345726045.85.0.0457670811095.issue15769@psf.upfronthosting.co.za> R. David Murray added the comment: It has been a while since I looked at the code, but if I remember correctly there is a (somewhat non-obvious) mechanism for assigning priority to handlers, so that you can control the order of application. If I'm right the insort is about that priority, and it also ought to be possible to use that priority to fix the problem. But I remember whatever it was I was looking at as being a bit hard to understand, so I could be way off base (or thinking of some other part of the code base). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 14:47:40 2012 From: report at bugs.python.org (Wichert Akkerman) Date: Thu, 23 Aug 2012 12:47:40 +0000 Subject: [issue10436] tarfile.extractfile in "r|" stream mode fails with filenames or members from getmembers() In-Reply-To: <1289931464.79.0.618120236196.issue10436@psf.upfronthosting.co.za> Message-ID: <1345726060.11.0.379586024454.issue10436@psf.upfronthosting.co.za> Wichert Akkerman added the comment: You could also look for the first matching file and extract that. That way you can at least implement something similar to what standard tar can do: [fog;/tmp]-10> tar tf x.tar docs/ docs/index.rst docs/glossary.rst docs/Makefile docs/conf.py docs/changes.rst [fog;/tmp]-12> cat x.tar| tar xf - docs/index.rst [fog;/tmp]-13> ls docs index.rst ---------- nosy: +wichert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 14:56:02 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 23 Aug 2012 12:56:02 +0000 Subject: [issue15393] JSONDecoder.raw_decode breaks on leading whitespace In-Reply-To: <1342692596.02.0.962530841473.issue15393@psf.upfronthosting.co.za> Message-ID: <1345726562.04.0.381712668073.issue15393@psf.upfronthosting.co.za> R. David Murray added the comment: I didn't have anything specific in mind, just making a general comment about the care that needs to be taken in crafting the fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 14:57:53 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 23 Aug 2012 12:57:53 +0000 Subject: [issue15769] urllib.request.urlopen with cafile or capath set overrides any previous Handlers In-Reply-To: <1345685709.12.0.30740709281.issue15769@psf.upfronthosting.co.za> Message-ID: <1345726673.39.0.883669624349.issue15769@psf.upfronthosting.co.za> Antoine Pitrou added the comment: - opener = build_opener(https_handler) + if _opener is None: + opener = build_opener(https_handler) + else: + opener = _opener + opener.add_handler(https_handler) Well, isn't it a bad idea to mutate the global opener? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 15:54:50 2012 From: report at bugs.python.org (Tomasz Buchert) Date: Thu, 23 Aug 2012 13:54:50 +0000 Subject: [issue13212] json library is decoding/encoding when it should not In-Reply-To: <1318960832.41.0.586770861075.issue13212@psf.upfronthosting.co.za> Message-ID: <1345730090.25.0.112570264117.issue13212@psf.upfronthosting.co.za> Tomasz Buchert added the comment: Take a look at http://bugs.python.org/issue14674. A proposed documentation patch specifically discusses this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 15:58:42 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 23 Aug 2012 13:58:42 +0000 Subject: [issue15770] _testbuffer.get_contiguous() doesn't check input arguments In-Reply-To: <1345709257.81.0.874456644745.issue15770@psf.upfronthosting.co.za> Message-ID: <3X2nKF2mLHzQJb@mail.python.org> Roundup Robot added the comment: New changeset fa745ed89b7a by Stefan Krah in branch 'default': Issue #15770: Check invalid arguments in test function. Patch by Victor Stinner. http://hg.python.org/cpython/rev/fa745ed89b7a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 15:59:48 2012 From: report at bugs.python.org (Stefan Krah) Date: Thu, 23 Aug 2012 13:59:48 +0000 Subject: [issue15770] _testbuffer.get_contiguous() doesn't check input arguments In-Reply-To: <1345709257.81.0.874456644745.issue15770@psf.upfronthosting.co.za> Message-ID: <1345730388.18.0.103151141415.issue15770@psf.upfronthosting.co.za> Stefan Krah added the comment: Thanks, fixed. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 16:01:44 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Thu, 23 Aug 2012 14:01:44 +0000 Subject: [issue15758] 500x speed up for Popen.communicate() on Windows In-Reply-To: <1345587910.43.0.919180045188.issue15758@psf.upfronthosting.co.za> Message-ID: <1345730504.41.0.633776858339.issue15758@psf.upfronthosting.co.za> Changes by Richard Oudkerk : Removed file: http://bugs.python.org/file26953/popen_communicate.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 16:01:53 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Thu, 23 Aug 2012 14:01:53 +0000 Subject: [issue15758] 500x speed up for Popen.communicate() on Windows In-Reply-To: <1345587910.43.0.919180045188.issue15758@psf.upfronthosting.co.za> Message-ID: <1345730513.74.0.44126637962.issue15758@psf.upfronthosting.co.za> Changes by Richard Oudkerk : Removed file: http://bugs.python.org/file26959/readall-resize.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 16:02:02 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Thu, 23 Aug 2012 14:02:02 +0000 Subject: [issue15758] 500x speed up for Popen.communicate() on Windows In-Reply-To: <1345587910.43.0.919180045188.issue15758@psf.upfronthosting.co.za> Message-ID: <1345730522.55.0.988543685429.issue15758@psf.upfronthosting.co.za> Changes by Richard Oudkerk : Removed file: http://bugs.python.org/file26960/readall-chunks.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 16:02:09 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Thu, 23 Aug 2012 14:02:09 +0000 Subject: [issue15758] 500x speed up for Popen.communicate() on Windows In-Reply-To: <1345587910.43.0.919180045188.issue15758@psf.upfronthosting.co.za> Message-ID: <1345730529.27.0.901368346106.issue15758@psf.upfronthosting.co.za> Changes by Richard Oudkerk : Removed file: http://bugs.python.org/file26963/readall-combined.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 16:08:02 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Thu, 23 Aug 2012 14:08:02 +0000 Subject: [issue15758] FileIO.readall() has worst case O(n^2) complexity In-Reply-To: <1345587910.43.0.919180045188.issue15758@psf.upfronthosting.co.za> Message-ID: <1345730882.55.0.606600957788.issue15758@psf.upfronthosting.co.za> Richard Oudkerk added the comment: Here is the patch (with the old ones removed). Note that the old code mishandled the case where _PyBytes_Resize() failed by assuming that the old bytes object would still be valid. I have assumed that stream psuedo-files will never claim to have a size greater than zero. The code will still work if this assumption is false. ---------- title: 500x speed up for Popen.communicate() on Windows -> FileIO.readall() has worst case O(n^2) complexity Added file: http://bugs.python.org/file26970/readall-combined.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 16:26:17 2012 From: report at bugs.python.org (moijes12) Date: Thu, 23 Aug 2012 14:26:17 +0000 Subject: [issue11698] Improve repr for structseq objects to show named, but unindexed fields In-Reply-To: <1301264097.04.0.982421975108.issue11698@psf.upfronthosting.co.za> Message-ID: <1345731977.21.0.222366730091.issue11698@psf.upfronthosting.co.za> Changes by moijes12 : ---------- nosy: +moijes12 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 16:27:49 2012 From: report at bugs.python.org (moijes12) Date: Thu, 23 Aug 2012 14:27:49 +0000 Subject: [issue626452] Support RFC 2111 in email package Message-ID: <1345732069.15.0.882672335235.issue626452@psf.upfronthosting.co.za> Changes by moijes12 : ---------- nosy: +moijes12 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 16:30:21 2012 From: report at bugs.python.org (moijes12) Date: Thu, 23 Aug 2012 14:30:21 +0000 Subject: [issue1660009] continuing problem with httplib multiple set-cookie headers Message-ID: <1345732221.87.0.317970571299.issue1660009@psf.upfronthosting.co.za> Changes by moijes12 : ---------- nosy: -moijes12 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 16:36:30 2012 From: report at bugs.python.org (moijes12) Date: Thu, 23 Aug 2012 14:36:30 +0000 Subject: [issue724459] Add documentation about line endings in email messages. Message-ID: <1345732590.6.0.805294728837.issue724459@psf.upfronthosting.co.za> Changes by moijes12 : ---------- nosy: +moijes12 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 16:36:58 2012 From: report at bugs.python.org (moijes12) Date: Thu, 23 Aug 2012 14:36:58 +0000 Subject: [issue11664] Add patch method to unittest.TestCase In-Reply-To: <1300999439.71.0.376555102459.issue11664@psf.upfronthosting.co.za> Message-ID: <1345732618.37.0.364069888366.issue11664@psf.upfronthosting.co.za> Changes by moijes12 : ---------- nosy: -moijes12 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 16:37:27 2012 From: report at bugs.python.org (moijes12) Date: Thu, 23 Aug 2012 14:37:27 +0000 Subject: [issue11698] Improve repr for structseq objects to show named, but unindexed fields In-Reply-To: <1301264097.04.0.982421975108.issue11698@psf.upfronthosting.co.za> Message-ID: <1345732647.69.0.931109676173.issue11698@psf.upfronthosting.co.za> Changes by moijes12 : ---------- nosy: -moijes12 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 16:39:07 2012 From: report at bugs.python.org (moijes12) Date: Thu, 23 Aug 2012 14:39:07 +0000 Subject: [issue2380] Raise a Py3K warning for catching nested tuples with non-BaseException exceptions In-Reply-To: <1205812263.49.0.840453912449.issue2380@psf.upfronthosting.co.za> Message-ID: <1345732747.61.0.341376641548.issue2380@psf.upfronthosting.co.za> Changes by moijes12 : ---------- nosy: +moijes12 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 16:42:55 2012 From: report at bugs.python.org (moijes12) Date: Thu, 23 Aug 2012 14:42:55 +0000 Subject: [issue15442] Expand the list of default dirs filecmp.dircmp ignores In-Reply-To: <1343147532.2.0.187379599839.issue15442@psf.upfronthosting.co.za> Message-ID: <1345732975.56.0.494402991895.issue15442@psf.upfronthosting.co.za> Changes by moijes12 : ---------- nosy: +moijes12 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 16:50:11 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 23 Aug 2012 14:50:11 +0000 Subject: [issue15758] FileIO.readall() has worst case O(n^2) complexity In-Reply-To: <1345730882.55.0.606600957788.issue15758@psf.upfronthosting.co.za> Message-ID: <1345733208.3429.10.camel@localhost.localdomain> Antoine Pitrou added the comment: > Here is the patch (with the old ones removed). > > Note that the old code mishandled the case where _PyBytes_Resize() > failed by assuming that the old bytes object would still be valid. > > I have assumed that stream psuedo-files will never claim to have a > size greater than zero. The code will still work if this assumption > is false. I haven't measured under Windows, but this looks ok to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 17:31:14 2012 From: report at bugs.python.org (Stefan Mihaila) Date: Thu, 23 Aug 2012 15:31:14 +0000 Subject: [issue15642] Integrate pickle protocol version 4 GSoC work by Stefan Mihaila In-Reply-To: <1345650598.98.0.0865781880473.issue15642@psf.upfronthosting.co.za> Message-ID: <50364CB4.8070401@gmail.com> Stefan Mihaila added the comment: Are there also some known techniques on tracking down memory leaks? I've played around with sys.gettotalrefcount to narrow down the place where the leaks occur, but they seem to only occur in v4, i.e. pickle.dumps(3.0+1j, 4) leaks but pickle.dumps(3.0+1j, 3) does not. However, there appears to be no difference in the code that gets executed in v3 to the one executed in v4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 18:14:53 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 23 Aug 2012 16:14:53 +0000 Subject: [issue11776] Constructor signatures missing in types module documentation In-Reply-To: <1302036805.33.0.506634428921.issue11776@psf.upfronthosting.co.za> Message-ID: <1345738493.64.0.00348800689468.issue11776@psf.upfronthosting.co.za> Terry J. Reedy added the comment: LambdaType is a synonym for FunctionType. There should be just one entry, as currently, but perhaps make that a bit clearer, as one could misread the current line as saying that FunctionType is the type of def statements and LambdaType is the type of lambda expressions. This misunderstanding appears in python-list discussions occasionally. So I think I would write types.FunctionType(sig....) types.LambdaType synonym for FunctionType Create a function .... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 18:20:39 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 23 Aug 2012 16:20:39 +0000 Subject: [issue15765] test_getcwd_long_pathnames (in test_posix) kills NetBSD In-Reply-To: <1345644735.97.0.561553846154.issue15765@psf.upfronthosting.co.za> Message-ID: <1345738839.62.0.484794156791.issue15765@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo, neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 18:54:35 2012 From: report at bugs.python.org (Daniel Holth) Date: Thu, 23 Aug 2012 16:54:35 +0000 Subject: [issue11880] add a {dist-info} category to distutils2 In-Reply-To: <1303231865.42.0.936595329467.issue11880@psf.upfronthosting.co.za> Message-ID: <1345740875.5.0.181549965874.issue11880@psf.upfronthosting.co.za> Daniel Holth added the comment: Sorry, I won't be able to get around to this any time soon. The patch to fix this bug (in the CPython3 source code) is too intertwined with the other distutils2 fixes. Anyone is welcome to fish for it in my bitbucket. ---------- status: open -> languishing _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 19:22:31 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 23 Aug 2012 17:22:31 +0000 Subject: [issue14674] Link to & explain deviations from RFC 4627 in json module docs In-Reply-To: <1335449712.62.0.988063979534.issue14674@psf.upfronthosting.co.za> Message-ID: <1345742551.47.0.916906324737.issue14674@psf.upfronthosting.co.za> ?ric Araujo added the comment: See also #13212. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 19:29:06 2012 From: report at bugs.python.org (moijes12) Date: Thu, 23 Aug 2012 17:29:06 +0000 Subject: [issue15442] Expand the list of default dirs filecmp.dircmp ignores In-Reply-To: <1343147532.2.0.187379599839.issue15442@psf.upfronthosting.co.za> Message-ID: <1345742946.45.0.677878331704.issue15442@psf.upfronthosting.co.za> Changes by moijes12 : ---------- keywords: +patch Added file: http://bugs.python.org/file26971/15442.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 19:51:12 2012 From: report at bugs.python.org (moijes12) Date: Thu, 23 Aug 2012 17:51:12 +0000 Subject: [issue2380] Raise a Py3K warning for catching nested tuples with non-BaseException exceptions In-Reply-To: <1205812263.49.0.840453912449.issue2380@psf.upfronthosting.co.za> Message-ID: <1345744272.7.0.864549464237.issue2380@psf.upfronthosting.co.za> Changes by moijes12 : ---------- nosy: -moijes12 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 19:56:08 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Thu, 23 Aug 2012 17:56:08 +0000 Subject: [issue13370] test_ctypes fails when building python with clang In-Reply-To: <1345700807.88.0.633464985662.issue13370@psf.upfronthosting.co.za> Message-ID: <1F85D4CD-B5B4-47F4-B4A9-03236697D92B@mac.com> Ronald Oussoren added the comment: I didn't have time to look into this today and will look into this tomorrow. ---------- Added file: http://bugs.python.org/file26972/smime.p7s _______________________________________ Python tracker _______________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4812 bytes Desc: not available URL: From report at bugs.python.org Thu Aug 23 19:58:51 2012 From: report at bugs.python.org (moijes12) Date: Thu, 23 Aug 2012 17:58:51 +0000 Subject: =?utf-8?q?=5Bissue13518=5D_configparser_can=E2=80=99t_read_file_objects_f?= =?utf-8?q?rom_urlopen?= In-Reply-To: <1322782976.1.0.275624635723.issue13518@psf.upfronthosting.co.za> Message-ID: <1345744731.15.0.730575112885.issue13518@psf.upfronthosting.co.za> Changes by moijes12 : ---------- nosy: +moijes12 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 19:59:58 2012 From: report at bugs.python.org (LittleQ) Date: Thu, 23 Aug 2012 17:59:58 +0000 Subject: [issue15249] email.generator.BytesGenerator doesn't mangle "From " lines when non-ASCII bytes are present In-Reply-To: <1341396786.66.0.201550976108.issue15249@psf.upfronthosting.co.za> Message-ID: <1345744798.4.0.0408677742508.issue15249@psf.upfronthosting.co.za> LittleQ added the comment: when ByteGenerator entered _has_surrogates() will write the payload directly by not-enter into the super class Generator, which has the replace action. my solution is just do it also in BytesGenerator. ---------- nosy: +littleq0903 Added file: http://bugs.python.org/file26973/issue15249.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 20:04:32 2012 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2012 18:04:32 +0000 Subject: [issue14674] Link to & explain deviations from RFC 4627 in json module docs In-Reply-To: <1335449712.62.0.988063979534.issue14674@psf.upfronthosting.co.za> Message-ID: <1345745072.68.0.0482552294022.issue14674@psf.upfronthosting.co.za> Georg Brandl added the comment: Neither json.org nor RFC 4627 mention "scalar". I don't think we should introduce that term, with the necessary ambiguity given the context, needlessly. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 20:09:07 2012 From: report at bugs.python.org (LittleQ) Date: Thu, 23 Aug 2012 18:09:07 +0000 Subject: [issue15249] email.generator.BytesGenerator doesn't mangle "From " lines when non-ASCII bytes are present In-Reply-To: <1341396786.66.0.201550976108.issue15249@psf.upfronthosting.co.za> Message-ID: <1345745347.4.0.272843528116.issue15249@psf.upfronthosting.co.za> LittleQ added the comment: Sorry, forgot removing the debugging __init__ method. the attachment is the patch without the __init__ changes. ---------- Added file: http://bugs.python.org/file26974/issue15249_fixed.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 20:12:00 2012 From: report at bugs.python.org (Zachary Ware) Date: Thu, 23 Aug 2012 18:12:00 +0000 Subject: [issue15136] Decimal accepting Fraction In-Reply-To: <1340365912.14.0.935631231431.issue15136@psf.upfronthosting.co.za> Message-ID: <1345745520.63.0.880371492256.issue15136@psf.upfronthosting.co.za> Zachary Ware added the comment: I came across this issue and thought it might be within my means to attempt a patch, so here's the first step towards one. I liked Terry's suggestion of implementing __format__ using .as_decimal, so that's what I'm working towards with this. The first part is (or seems to be, I am pretty new at this and may well have missed something obvious :-)) pretty easy. The attached patch is pretty self-explanatory, I think. I figure if the user wants something specific from their fraction-as-a-decimal, they're probably working with other decimals already and will be able to supply a context. Otherwise, if they just want to see a decimal representation, they'll probably be fine with the default context and don't have to worry about it. The __format__ part, though, seems kind of daunting. For one thing, Decimal's implementation looks pretty hairy and scary from my perspective; duplicating it for Fraction would be quite a feat. For another, the standard format spec doesn't seem to me to cleanly apply to fractional representations--what should be filled, how should alignment work, how would width be divided up, what exactly does precision mean? I've had a thought, though; what if Fraction.__format__ simply looks for a 'D' at the end of format_spec? If it's found, just return format(self.as_decimal(), format_spec[:-1]. Otherwise, format using to-be-determined rules specific to fractions, including rules for, say, mixed fractions or denominator of a certain size. Thoughts? ---------- keywords: +patch nosy: +zach.ware Added file: http://bugs.python.org/file26975/issue15136_as_decimal.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 20:39:33 2012 From: report at bugs.python.org (Christian Heimes) Date: Thu, 23 Aug 2012 18:39:33 +0000 Subject: [issue626452] Support RFC 2111 in email package Message-ID: <1345747173.08.0.848623170833.issue626452@psf.upfronthosting.co.za> Christian Heimes added the comment: Guess the feature didn't make it into Python 2.4 ... :) ---------- versions: +Python 3.4 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 20:49:37 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 23 Aug 2012 18:49:37 +0000 Subject: [issue626452] Support RFC 2392 in email package Message-ID: <1345747777.25.0.61553482073.issue626452@psf.upfronthosting.co.za> R. David Murray added the comment: And in the meantime that RFC has been obsoleted by rfc 2392. ---------- components: +email stage: test needed -> needs patch title: Support RFC 2111 in email package -> Support RFC 2392 in email package _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 20:53:09 2012 From: report at bugs.python.org (moijes12) Date: Thu, 23 Aug 2012 18:53:09 +0000 Subject: [issue626452] Support RFC 2392 in email package Message-ID: <1345747989.59.0.972976675095.issue626452@psf.upfronthosting.co.za> moijes12 added the comment: Whoa cool. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 21:00:16 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 23 Aug 2012 19:00:16 +0000 Subject: [issue626452] Support RFC 2392 in email package Message-ID: <1345748416.77.0.425991123994.issue626452@psf.upfronthosting.co.za> R. David Murray added the comment: moijes12: do you want to work on it? I haven't even read the RFC yet to find out what "support it" means; too many other issues on my plate first. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 21:13:46 2012 From: report at bugs.python.org (James) Date: Thu, 23 Aug 2012 19:13:46 +0000 Subject: [issue15753] No-argument super in method with variable arguments raises SystemError In-Reply-To: <1345549960.82.0.102703520127.issue15753@psf.upfronthosting.co.za> Message-ID: <1345749226.32.0.761414096333.issue15753@psf.upfronthosting.co.za> James added the comment: I've attached a patch that I think fixes the variable arguments problem, and changes the SystemErrors that can be obtained by misusing super() into RuntimeErrors (I assume that's more appropriate?). There are three more SystemErrors I'm not sure about: "super(): no code object", "super(): bad __class__ cell", and "super(): empty __class__ cell" - can they only be caused by internal bugs? ---------- keywords: +patch Added file: http://bugs.python.org/file26976/issue15753_varargsuper.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 21:20:20 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Thu, 23 Aug 2012 19:20:20 +0000 Subject: [issue13212] json library is decoding/encoding when it should not In-Reply-To: <1318960832.41.0.586770861075.issue13212@psf.upfronthosting.co.za> Message-ID: <1345749620.92.0.848953090427.issue13212@psf.upfronthosting.co.za> Petri Lehtinen added the comment: The strict flag sounds good to me, too. I don't think it should be called "strict" though, as that would imply that we comply with RFC 4627 strictly (which is not true without passing allow_nan=False for dump() or passing a parse_constant function for load()). How about "encode_any" and "decode_any" or "any_value"? Deprecation doesn't sound good to me. If the feature is already there, it probably has its users and use cases. ---------- nosy: +petri.lehtinen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 21:32:00 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Thu, 23 Aug 2012 19:32:00 +0000 Subject: [issue15249] email.generator.BytesGenerator doesn't mangle "From " lines when non-ASCII bytes are present In-Reply-To: <1341396786.66.0.201550976108.issue15249@psf.upfronthosting.co.za> Message-ID: <1345750320.01.0.390044020204.issue15249@psf.upfronthosting.co.za> Petri Lehtinen added the comment: The patch looks good to me and seems to fix my test case. I find the email code somewhat complicated, so I'll let David decide whether it's the correct fix :) ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 21:47:02 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 23 Aug 2012 19:47:02 +0000 Subject: [issue15442] Expand the list of default dirs filecmp.dircmp ignores In-Reply-To: <1343147532.2.0.187379599839.issue15442@psf.upfronthosting.co.za> Message-ID: <1345751222.03.0.386003388726.issue15442@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Hi moijes12, for instructions on compiling and submitting patches, etc., see the Python Developer's Guide (aka the devguide). You may also be interested in the Python Mentors Group: http://pythonmentors.com/ Lastly (a small point), in the future you can also type comments about your patch in the "Comment" text field in addition to the "File Description" text field. You can do this in the same "Submit Changes" operation that you use to choose and upload your file. ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 21:55:43 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 23 Aug 2012 19:55:43 +0000 Subject: [issue11664] Add patch method to unittest.TestCase In-Reply-To: <1300999439.71.0.376555102459.issue11664@psf.upfronthosting.co.za> Message-ID: <1345751743.57.0.328861759261.issue11664@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 22:02:44 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 23 Aug 2012 20:02:44 +0000 Subject: [issue15351] Add to unittest.TestCase support for using context managers In-Reply-To: <1342280032.27.0.345733068822.issue15351@psf.upfronthosting.co.za> Message-ID: <1345752164.52.0.986616290668.issue15351@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Adding ?ric because of the interest in test setup and tear down in issue 11664. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 22:38:59 2012 From: report at bugs.python.org (Saul Spatz) Date: Thu, 23 Aug 2012 20:38:59 +0000 Subject: [issue15772] Unresolved symbols in Windows 64-bit python Message-ID: <1345754338.96.0.805254982219.issue15772@psf.upfronthosting.co.za> New submission from Saul Spatz: In trying to build a SWING module on Windows with 64-bit python, I get the linker errors listed at the bottom of this message. I have this problem with both python 2.7 and 3.2. I have built the project without problems on Windows with 32-bit python, and a correspondent informs me that it cam be built on linux with 64-bit python. I have listed the exports from python32.lib with dumpbin, and in every case, the symbol after the __imp__ appears in the library without a leading underscore. For example, for the first unresolved symbol, __imp__PyBytes_AsStringAndSize, I find that PyBytes_AsStringAndSize appears in the library. Of 1074 exports in the library, 891 do not have leading underscores, and the remainder do. In the 32-bit library, every export starts with an underscore. This is obviously related to issues 15165 and 14286, but I hope this additional information will help locate the trouble. I am running windows 7 professional, and I installed python by downloading and running the installer with all the defaults. 1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyBytes_AsStringAndSize referenced in function _SWIG_Python_str_AsChar 1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyUnicodeUCS2_AsUTF8String referenced in function _SWIG_Python_str_AsChar 1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyUnicodeUCS2_FromString referenced in function _SWIG_Python_str_FromChar 1>example_wrap.obj : error LNK2001: unresolved external symbol __imp__PyExc_RuntimeError 1>example_wrap.obj : error LNK2001: unresolved external symbol __imp__PyExc_AttributeError 1>example_wrap.obj : error LNK2001: unresolved external symbol __imp__PyExc_SystemError 1>example_wrap.obj : error LNK2001: unresolved external symbol __imp__PyExc_ValueError 1>example_wrap.obj : error LNK2001: unresolved external symbol __imp__PyExc_SyntaxError 1>example_wrap.obj : error LNK2001: unresolved external symbol __imp__PyExc_OverflowError 1>example_wrap.obj : error LNK2001: unresolved external symbol __imp__PyExc_ZeroDivisionError 1>example_wrap.obj : error LNK2001: unresolved external symbol __imp__PyExc_TypeError 1>example_wrap.obj : error LNK2001: unresolved external symbol __imp__PyExc_IndexError 1>example_wrap.obj : error LNK2001: unresolved external symbol __imp__PyExc_IOError 1>example_wrap.obj : error LNK2001: unresolved external symbol __imp__PyExc_MemoryError 1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyInstanceMethod_New referenced in function _SWIG_PyInstanceMethod_New 1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyErr_SetString referenced in function _SWIG_Python_SetErrorMsg 1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__Py_BuildValue referenced in function __SWIG_Py_None 1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyLong_FromVoidPtr referenced in function _SwigPyObject_long 1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__Py_DecRef referenced in function _SwigPyObject_repr 1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyUnicodeUCS2_Concat referenced in function _SwigPyObject_repr 1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyUnicodeUCS2_FromFormat referenced in function _SwigPyObject_repr 1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyBool_FromLong referenced in function _SwigPyObject_richcompare 1>example_wrap.obj : error LNK2001: unresolved external symbol __imp___Py_NotImplementedStruct 1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyObject_Free referenced in function _SwigPyObject_dealloc 1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyObject_CallFunctionObjArgs referenced in function _SwigPyObject_dealloc 1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyObject_IsTrue referenced in function _SwigPyObject_own 1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyArg_UnpackTuple referenced in function _SwigPyObject_own 1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyType_Ready referenced in function _SwigPyObject_TypeOnce 1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyObject_GenericGetAttr referenced in function _SwigPyObject_TypeOnce 1>example_wrap.obj : error LNK2001: unresolved external symbol __imp__PyBaseObject_Type 1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyObject_SetAttr referenced in function _SWIG_Python_NewShadowInstance 1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyObject_Call referenced in function _SWIG_Python_NewShadowInstance 1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyErr_Clear referenced in function _SWIG_Python_GetModule 1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyErr_Occurred referenced in function _SWIG_Python_GetModule 1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyCapsule_Import referenced in function _SWIG_Python_GetModule 1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyCapsule_GetPointer referenced in function _SWIG_Python_DestroyModule 1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyModule_AddObject referenced in function _SWIG_Python_SetModule 1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyCapsule_New referenced in function _SWIG_Python_SetModule 1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyImport_AddModule referenced in function _SWIG_Python_SetModule 1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyFloat_AsDouble referenced in function _SWIG_AsVal_double 1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyLong_AsLong referenced in function _SWIG_AsVal_double 1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyType_IsSubtype referenced in function _SWIG_AsVal_double 1>example_wrap.obj : error LNK2001: unresolved external symbol __imp__PyFloat_Type 1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyLong_FromLong referenced in function _SWIG_From_int 1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyArg_ParseTuple referenced in function __wrap_gcd 1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyFloat_FromDouble referenced in function _Swig_var_Foo_get 1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyUnicode_InternFromString referenced in function _swig_varlink_repr 1>example_wrap.obj : error LNK2001: unresolved external symbol __imp__PyExc_NameError 1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyObject_Init referenced in function _SWIG_Python_newvarlink 1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyObject_Malloc referenced in function _SWIG_Python_newvarlink 1>example_wrap.obj : error LNK2019: unresolved external symbol __imp___PyObject_New referenced in function _SWIG_Python_NewPointerObj 1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyDict_SetItemString referenced in function _SWIG_Python_InstallConstants 1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyModule_GetDict referenced in function _PyInit__example 1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyModule_Create2 referenced in function _PyInit__example ---------- components: Windows messages: 168964 nosy: spatz123 priority: normal severity: normal status: open title: Unresolved symbols in Windows 64-bit python type: compile error versions: Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 23 22:59:23 2012 From: report at bugs.python.org (Brian Curtin) Date: Thu, 23 Aug 2012 20:59:23 +0000 Subject: [issue15772] Unresolved symbols in Windows 64-bit python In-Reply-To: <1345754338.96.0.805254982219.issue15772@psf.upfronthosting.co.za> Message-ID: <1345755563.2.0.116915769573.issue15772@psf.upfronthosting.co.za> Changes by Brian Curtin : ---------- components: +Build nosy: +brian.curtin, loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 01:08:26 2012 From: report at bugs.python.org (Brian Turek) Date: Thu, 23 Aug 2012 23:08:26 +0000 Subject: [issue15769] urllib.request.urlopen with cafile or capath set overrides any previous Handlers In-Reply-To: <1345685709.12.0.30740709281.issue15769@psf.upfronthosting.co.za> Message-ID: <1345763306.34.0.952397450354.issue15769@psf.upfronthosting.co.za> Brian Turek added the comment: So I'm not saying the attached patch is the *best* solution but it doesn't mangle the existing urllib.request._opener too much. ---------- keywords: +patch Added file: http://bugs.python.org/file26977/request.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 01:30:06 2012 From: report at bugs.python.org (Hugo Lopes Tavares) Date: Thu, 23 Aug 2012 23:30:06 +0000 Subject: [issue13592] repr(regex) doesn't include actual regex In-Reply-To: <1323772944.14.0.269599775604.issue13592@psf.upfronthosting.co.za> Message-ID: <1345764606.29.0.353971330233.issue13592@psf.upfronthosting.co.za> Hugo Lopes Tavares added the comment: Any news about this patch? Is it going to be merged? When is next CPython release? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 01:35:07 2012 From: report at bugs.python.org (Stefan Mihaila) Date: Thu, 23 Aug 2012 23:35:07 +0000 Subject: [issue15773] `is' operator returns False on classmethods Message-ID: <1345764907.85.0.74641370486.issue15773@psf.upfronthosting.co.za> New submission from Stefan Mihaila: Here are a few counter-intuitive outputs: >>> dict.fromkeys is dict.fromkeys False >>> id(dict.fromkeys) == id(dict.fromkeys) True >>> x=dict.fromkeys; id(x) == id(x) True >>> x=dict.fromkeys; id(x) == id(dict.fromkeys) False >>> x=dict.fromkeys; y=dict.fromkeys; id(x),id(y),id(dict.fromkeys) (39888824, 39064632, 39065144) >>> a=id(dict.fromkeys); x=dict.fromkeys; b=id(dict.fromkeys); a,b (39888824, 39480568) Attached is a failing test. ---------- files: is_on_classmethods.py messages: 168967 nosy: mstefanro priority: normal severity: normal status: open title: `is' operator returns False on classmethods versions: Python 3.3 Added file: http://bugs.python.org/file26978/is_on_classmethods.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 02:02:31 2012 From: report at bugs.python.org (Stefan Mihaila) Date: Fri, 24 Aug 2012 00:02:31 +0000 Subject: [issue15773] `is' operator returns False on classmethods In-Reply-To: <1345764907.85.0.74641370486.issue15773@psf.upfronthosting.co.za> Message-ID: <1345766551.94.0.679814868859.issue15773@psf.upfronthosting.co.za> Changes by Stefan Mihaila : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 02:50:13 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 24 Aug 2012 00:50:13 +0000 Subject: [issue15773] `is' operator returns False on classmethods In-Reply-To: <1345764907.85.0.74641370486.issue15773@psf.upfronthosting.co.za> Message-ID: <1345769413.84.0.607691130472.issue15773@psf.upfronthosting.co.za> Nick Coghlan added the comment: Bound methods are created dynamically on lookup, while object ids may be reused after the original object is destroyed. There's no bug here - just a combination of those two language behaviours that is frequently surprising to users that have just noticed it. There's not a lot we can do about that - it's a genuinely surprising moment in people's understanding of the way methods (and descriptors in general) work. ---------- nosy: +ncoghlan resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 02:51:53 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 24 Aug 2012 00:51:53 +0000 Subject: [issue2051] PYO file permission problem In-Reply-To: <1202498912.62.0.957005802385.issue2051@psf.upfronthosting.co.za> Message-ID: <1345769513.61.0.482721462761.issue2051@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- assignee: -> ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 02:52:19 2012 From: report at bugs.python.org (mesheb82) Date: Fri, 24 Aug 2012 00:52:19 +0000 Subject: [issue15774] String method title() produces incorrect resutls Message-ID: <1345769539.02.0.287191314572.issue15774@psf.upfronthosting.co.za> New submission from mesheb82: I got unexpected results when working with a string that has an apostrophe in it. "Joe's".title() >> "Joe'S" 'Joe"s'.title() >> 'Joe"S' ---------- components: Interpreter Core messages: 168969 nosy: mesheb82 priority: normal severity: normal status: open title: String method title() produces incorrect resutls versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 02:55:33 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 24 Aug 2012 00:55:33 +0000 Subject: [issue15774] String method title() produces incorrect resutls In-Reply-To: <1345769539.02.0.287191314572.issue15774@psf.upfronthosting.co.za> Message-ID: <1345769733.85.0.99765548743.issue15774@psf.upfronthosting.co.za> Ezio Melotti added the comment: This is a known "issue", see http://docs.python.org/library/stdtypes.html#str.title ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 03:12:22 2012 From: report at bugs.python.org (Trent Nelson) Date: Fri, 24 Aug 2012 01:12:22 +0000 Subject: [issue15748] Various symlink test failures in test_shutil on FreeBSD In-Reply-To: <1345516038.44.0.114148239105.issue15748@psf.upfronthosting.co.za> Message-ID: <1345770742.78.0.128472231054.issue15748@psf.upfronthosting.co.za> Trent Nelson added the comment: Reproduced behaviour with test_readlink.sh. Sending an e-mail to freebsd-fs to see what they think. ---------- Added file: http://bugs.python.org/file26979/test_readlink.sh _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 03:30:01 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 24 Aug 2012 01:30:01 +0000 Subject: [issue15774] String method title() produces incorrect resutls In-Reply-To: <1345769539.02.0.287191314572.issue15774@psf.upfronthosting.co.za> Message-ID: <1345771801.93.0.115977671733.issue15774@psf.upfronthosting.co.za> R. David Murray added the comment: This is a duplicate of issue 7008. See also issue 6412, which offers some small hope that some day there may be an algorithm that can fix this. ---------- nosy: +r.david.murray resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> str.title() misbehaves with apostrophes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 04:50:18 2012 From: report at bugs.python.org (Eric Snow) Date: Fri, 24 Aug 2012 02:50:18 +0000 Subject: [issue15352] importlib.h should be regenerated when the marshaling code changes In-Reply-To: <1342294865.71.0.8673703337.issue15352@psf.upfronthosting.co.za> Message-ID: <1345776618.76.0.707340360306.issue15352@psf.upfronthosting.co.za> Eric Snow added the comment: FWIW, the patch looks good to me. This is probably the last week to get this in for 3.3.0. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 05:13:08 2012 From: report at bugs.python.org (Mark Grandi) Date: Fri, 24 Aug 2012 03:13:08 +0000 Subject: [issue14455] plistlib unable to read json and binary plist files In-Reply-To: <1333144578.81.0.343123708942.issue14455@psf.upfronthosting.co.za> Message-ID: <1345777987.99.0.302582310364.issue14455@psf.upfronthosting.co.za> Mark Grandi added the comment: Where are you even seeing these json property lists? I just checked the most recent documentation for NSPropertyListSerialization, and they have not updated the enum for NSPropertyListFormat. It seems that if even Apple doesn't support writing json property lists with their own apis then we shouldn't worry about supporting it? see: https://developer.apple.com/library/ios/#documentation/Cocoa/Reference/Foundation/Classes/NSPropertyListSerialization_Class/Reference/Reference.html enum { NSPropertyListOpenStepFormat = kCFPropertyListOpenStepFormat, NSPropertyListXMLFormat_v1_0 = kCFPropertyListXMLFormat_v1_0, NSPropertyListBinaryFormat_v1_0 = kCFPropertyListBinaryFormat_v1_0 }; NSPropertyListFormat; typedef NSUInteger NSPropertyListFormat; ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 06:33:27 2012 From: report at bugs.python.org (Eric Snow) Date: Fri, 24 Aug 2012 04:33:27 +0000 Subject: [issue2051] PYO file permission problem In-Reply-To: <1202498912.62.0.957005802385.issue2051@psf.upfronthosting.co.za> Message-ID: <1345782807.55.0.0114679902231.issue2051@psf.upfronthosting.co.za> Eric Snow added the comment: here's a test. I'll work on a patch when I get a chance (and no one's beaten me to it :). ---------- keywords: +patch nosy: +eric.snow Added file: http://bugs.python.org/file26980/issue2051_test.eric.snow.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 09:34:55 2012 From: report at bugs.python.org (Chris Rebert) Date: Fri, 24 Aug 2012 07:34:55 +0000 Subject: [issue14674] Link to & explain deviations from RFC 4627 in json module docs In-Reply-To: <1335449712.62.0.988063979534.issue14674@psf.upfronthosting.co.za> Message-ID: <1345793695.77.0.414329921203.issue14674@psf.upfronthosting.co.za> Chris Rebert added the comment: Revised patch yet again to instead speak of "non-object, non-array" values and "JSON null, boolean, number, or string" values. Re: Petri, the patch already mentions the specific parameters one can use to get stricter behavior, albeit not in that particular short paragraph. Feel free to edit the patch. Any hope of getting this applied soon-ish? I began drafting this over 3 months ago, and yet this issue is tagged "easy"... ---------- Added file: http://bugs.python.org/file26981/json.rst.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 09:36:17 2012 From: report at bugs.python.org (Chris Rebert) Date: Fri, 24 Aug 2012 07:36:17 +0000 Subject: [issue13212] json library is decoding/encoding when it should not In-Reply-To: <1318960832.41.0.586770861075.issue13212@psf.upfronthosting.co.za> Message-ID: <1345793777.03.0.569112032327.issue13212@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 09:44:54 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 24 Aug 2012 07:44:54 +0000 Subject: [issue15037] curses.unget_wch and test_curses fail when linked with ncurses 5.7 and earlier In-Reply-To: <1339171712.6.0.747270716657.issue15037@psf.upfronthosting.co.za> Message-ID: <3X3DzT3bmbzQ83@mail.python.org> Roundup Robot added the comment: New changeset e587426d719f by Ned Deily in branch 'default': Issue #15037: Use correct path to system terminfo database. http://hg.python.org/cpython/rev/e587426d719f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 10:01:26 2012 From: report at bugs.python.org (Eric Snow) Date: Fri, 24 Aug 2012 08:01:26 +0000 Subject: [issue2051] PYO file permission problem In-Reply-To: <1202498912.62.0.957005802385.issue2051@psf.upfronthosting.co.za> Message-ID: <1345795286.74.0.0203475024966.issue2051@psf.upfronthosting.co.za> Eric Snow added the comment: So this boils down to set_data() not having a mode parameter, right? Alas, the obvious approach, adding it, breaks backward compatibility. The alternative is to use source_from_cache() in set_data() to get the source path, and then get the mode there. Of course, differentiating between the use cases for set_data() seems important there too. In short, "It may be rather hard to fix given the limitations of the set_data API". Regardless, we'll need to be careful to use the loader's cache to avoid extra stat calls. Also, we have to factor in issue6074 (basically do "mode | 0o600"). We'll need at least one more test to cover that (as Nick noted in that issue). I have a patch that is close, but my eyes are getting a little heavy. Hopefully I'll have that up tomorrow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 10:02:04 2012 From: report at bugs.python.org (Eric Snow) Date: Fri, 24 Aug 2012 08:02:04 +0000 Subject: [issue2051] PYO file permission problem In-Reply-To: <1202498912.62.0.957005802385.issue2051@psf.upfronthosting.co.za> Message-ID: <1345795324.62.0.228289201368.issue2051@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 10:13:42 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 24 Aug 2012 08:13:42 +0000 Subject: [issue2051] PYO file permission problem In-Reply-To: <1202498912.62.0.957005802385.issue2051@psf.upfronthosting.co.za> Message-ID: <1345796022.32.0.807750153979.issue2051@psf.upfronthosting.co.za> Nick Coghlan added the comment: I have a patch that works, and that I think may point the way to a replacement API for set_data in 3.4. Just running the full test suite before I check it in. The test you posted definitely saved me a lot of time. My version bypasses the cache, though. This isn't a disaster, since the main reason the cache is there is to speed up *failing* stat calls - this new one only incurs the hit when actually writing the bytecode file to disk, which should be lost in the noise of the actual IO write operation. However, suggestions for improvement always welcome :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 10:18:17 2012 From: report at bugs.python.org (=?utf-8?q?Nemeskey_D=C3=A1vid?=) Date: Fri, 24 Aug 2012 08:18:17 +0000 Subject: [issue15775] Add StopParser() to expat Message-ID: <1345796297.89.0.127411549702.issue15775@psf.upfronthosting.co.za> New submission from Nemeskey D?vid: The C expat library provides XML_StopParser() method that allows the parsing to be stopped from the handler functions. It would be nice to have this option in Python as well, maybe by adding StopParser() method to the XMLParser class. ---------- components: XML messages: 168980 nosy: nemeskeyd priority: normal severity: normal status: open title: Add StopParser() to expat type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 10:19:30 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 24 Aug 2012 08:19:30 +0000 Subject: [issue2051] PYO file permission problem In-Reply-To: <1202498912.62.0.957005802385.issue2051@psf.upfronthosting.co.za> Message-ID: <1345796370.28.0.1108454153.issue2051@psf.upfronthosting.co.za> Nick Coghlan added the comment: Also, my patch precisely recreates 3.2 behaviour, so it will mean #6074 may also affect 3.3. That isn't a regression, hence not a release blocker, but would still be good to get fixed for rc1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 10:21:06 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 24 Aug 2012 08:21:06 +0000 Subject: [issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite In-Reply-To: <1242857063.47.0.919073638283.issue6074@psf.upfronthosting.co.za> Message-ID: <1345796466.86.0.249716660551.issue6074@psf.upfronthosting.co.za> Nick Coghlan added the comment: Adding 3.3 to affected versions, since I'm about to check in a fix for #2051 that will reintroduce this problem. ---------- nosy: +eric.snow versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 10:23:22 2012 From: report at bugs.python.org (Chris Rebert) Date: Fri, 24 Aug 2012 08:23:22 +0000 Subject: [issue15136] Decimal accepting Fraction In-Reply-To: <1340365912.14.0.935631231431.issue15136@psf.upfronthosting.co.za> Message-ID: <1345796602.12.0.0252815214721.issue15136@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 10:30:38 2012 From: report at bugs.python.org (Chris Rebert) Date: Fri, 24 Aug 2012 08:30:38 +0000 Subject: [issue14965] super() and property inheritance behavior In-Reply-To: <1338433441.66.0.975494137492.issue14965@psf.upfronthosting.co.za> Message-ID: <1345797038.09.0.221656482615.issue14965@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 10:33:05 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 24 Aug 2012 08:33:05 +0000 Subject: [issue2501] xml.sax.parser() doesn't terminate when given a filename In-Reply-To: <1206699313.91.0.35803015757.issue2501@psf.upfronthosting.co.za> Message-ID: <3X3G340MnCzNmK@mail.python.org> Roundup Robot added the comment: New changeset 3a831a0a29c4 by Nick Coghlan in branch 'default': Close #2501: Permission bits are once again correctly copied from the source file to the cached bytecode file. Test by Eric Snow. http://hg.python.org/cpython/rev/3a831a0a29c4 ---------- nosy: +python-dev stage: -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 10:34:14 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 24 Aug 2012 08:34:14 +0000 Subject: [issue2501] xml.sax.parser() doesn't terminate when given a filename In-Reply-To: <1206699313.91.0.35803015757.issue2501@psf.upfronthosting.co.za> Message-ID: <1345797254.94.0.056783682471.issue2501@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- Removed message: http://bugs.python.org/msg168983 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 10:34:30 2012 From: report at bugs.python.org (Aaron Galea) Date: Fri, 24 Aug 2012 08:34:30 +0000 Subject: [issue15762] Windows 8 certification In-Reply-To: <1345625605.38.0.633732854192.issue15762@psf.upfronthosting.co.za> Message-ID: <1345797270.8.0.831149507396.issue15762@psf.upfronthosting.co.za> Aaron Galea added the comment: Its a distutils issue not py2exe. Not sure where I should post about this problem. The change I applied was in msvc9compiler.py in distutils. Once this change has been applied py2exe was rebuild to generate the correct runw.exe with the correct settings in the PE header of the executable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 10:35:49 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 24 Aug 2012 08:35:49 +0000 Subject: [issue2051] PYO file permission problem In-Reply-To: <1202498912.62.0.957005802385.issue2051@psf.upfronthosting.co.za> Message-ID: <1345797349.07.0.364315388586.issue2051@psf.upfronthosting.co.za> Nick Coghlan added the comment: (oops, transposed the digits in the checkin message) New changeset 3a831a0a29c4 by Nick Coghlan in branch 'default': Close #2051: Permission bits are once again correctly copied from the source file to the cached bytecode file. Test by Eric Snow. http://hg.python.org/cpython/rev/3a831a0a29c4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 10:36:47 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 24 Aug 2012 08:36:47 +0000 Subject: [issue2051] PYO file permission problem In-Reply-To: <1202498912.62.0.957005802385.issue2051@psf.upfronthosting.co.za> Message-ID: <3X3G7K5kbtzQ2t@mail.python.org> Roundup Robot added the comment: New changeset cfb11045fc8a by Nick Coghlan in branch 'default': Close #2051: Oops, transposed the digits in the issue number in the previous commit http://hg.python.org/cpython/rev/cfb11045fc8a ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 10:53:26 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 24 Aug 2012 08:53:26 +0000 Subject: [issue15136] Decimal accepting Fraction In-Reply-To: <1340365912.14.0.935631231431.issue15136@psf.upfronthosting.co.za> Message-ID: <1345798406.06.0.972462058511.issue15136@psf.upfronthosting.co.za> Mark Dickinson added the comment: > I think *both* proposals are sensible. Fraction already has .from_decimal > (using Decimal), so .to_decimal (also using Decimal) is sensible. Well, there's a difference: conversion from Decimal to Fraction is well-defined, with a unique, unambiguous result (excluding non-convertibles like infinities and nans); in particular, the value of any Decimal is exactly representable as a Fraction, so there's little information loss. (There *is* still some information loss, since Decimal('1.00') and Decimal('1.0') both covert to the same fraction, for example.) On the other hand, not every Fraction is exactly representable as a Decimal, so the result of conversion from Fraction to Decimal needs information about how many decimal places to produce, what rounding mode to use, what the ideal exponent should be in the case of exact results, etc. I think Zachary's idea of supporting a context argument, and using the current context if none is supplied, is the way to go here. The division should end up using an ideal exponent of 0, which doesn't seem unreasonable. To the patch: It looks fine, as far as it goes. It needs tests. To avoid the repetition of the division code, I'd suggest doing something like: if context is None: context = getcontext() Yes, supporting __format__ is going to be a bit more work. :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 11:00:25 2012 From: report at bugs.python.org (=?utf-8?b?0JDQvdGF0LHQsNGP0YAg0JvRhdCw0LPQstCw0LTQvtGA0LY=?=) Date: Fri, 24 Aug 2012 09:00:25 +0000 Subject: [issue10076] Regex objects became uncopyable in 2.5 In-Reply-To: <1286916324.24.0.772801528988.issue10076@psf.upfronthosting.co.za> Message-ID: <1345798825.47.0.135412899033.issue10076@psf.upfronthosting.co.za> ??????? ?????????? added the comment: Ding. ---------- nosy: +???????.?????????? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 11:01:41 2012 From: report at bugs.python.org (James) Date: Fri, 24 Aug 2012 09:01:41 +0000 Subject: [issue15753] No-argument super in method with variable arguments raises SystemError In-Reply-To: <1345549960.82.0.102703520127.issue15753@psf.upfronthosting.co.za> Message-ID: <1345798901.04.0.63129716943.issue15753@psf.upfronthosting.co.za> James added the comment: It turns out I don't really understand how frame objects work. My patch can crash python if you do this: >>> class A: ... def f(*args): ... args = 1 ... print(super()) ... >>> A().f() python: Objects/typeobject.c:6516: super_init: Assertion `((((((PyObject*)(obj))->ob_type))->tp_flags & ((1L<<26))) != 0)' failed. Aborted Is there a way of checking if the first argument has been overwritten, or do you just have to assume that if it is still a tuple, it hasn't been? Should the super documentation mention that assigning to self (or args in this case) can make the no-argument version work incorrectly? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 11:15:46 2012 From: report at bugs.python.org (Stefan Holek) Date: Fri, 24 Aug 2012 09:15:46 +0000 Subject: [issue15776] Allow pyvenv to work in existing directory Message-ID: <1345799746.88.0.728928529816.issue15776@psf.upfronthosting.co.za> New submission from Stefan Holek: With virtualenv I can do $ virtualenv . but with pyvenv I get $pyvenv . Error: Directory exists: /Users/stefan/sandbox/foo Please allow pyvenv to apply to existing directories. ---------- components: None messages: 168990 nosy: stefanholek priority: normal severity: normal status: open title: Allow pyvenv to work in existing directory type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 11:17:22 2012 From: report at bugs.python.org (Ned Deily) Date: Fri, 24 Aug 2012 09:17:22 +0000 Subject: [issue15776] Allow pyvenv to work in existing directory In-Reply-To: <1345799746.88.0.728928529816.issue15776@psf.upfronthosting.co.za> Message-ID: <1345799842.51.0.488123904496.issue15776@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 11:48:25 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Fri, 24 Aug 2012 09:48:25 +0000 Subject: [issue15723] Python breaks OS' append guarantee on file writes In-Reply-To: <1345321177.26.0.0602208919047.issue15723@psf.upfronthosting.co.za> Message-ID: <1345801705.76.0.642261493366.issue15723@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: I wouldn't rely on O_APPEND too much: - it won't work on NFS, and probably other non-local filesystems - it doesn't actually guarantee atomicity, because even though the the file offset and the write is done with locking, there is still the possibility of partial write ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 11:55:08 2012 From: report at bugs.python.org (Ralf Schmitt) Date: Fri, 24 Aug 2012 09:55:08 +0000 Subject: [issue15723] Python breaks OS' append guarantee on file writes In-Reply-To: <1345321177.26.0.0602208919047.issue15723@psf.upfronthosting.co.za> Message-ID: <1345802108.5.0.24103004293.issue15723@psf.upfronthosting.co.za> Changes by Ralf Schmitt : ---------- nosy: +schmir _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 12:02:28 2012 From: report at bugs.python.org (Mike Hoy) Date: Fri, 24 Aug 2012 10:02:28 +0000 Subject: [issue11776] Constructor signatures missing in types module documentation In-Reply-To: <1302036805.33.0.506634428921.issue11776@psf.upfronthosting.co.za> Message-ID: <1345802548.17.0.296988069606.issue11776@psf.upfronthosting.co.za> Mike Hoy added the comment: Lambda Changes patch. ---------- Added file: http://bugs.python.org/file26982/issue11776-first-easy-part-lambda-.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 12:13:15 2012 From: report at bugs.python.org (Ross Lagerwall) Date: Fri, 24 Aug 2012 10:13:15 +0000 Subject: [issue15777] test_capi refleak Message-ID: <1345803195.05.0.615891441008.issue15777@psf.upfronthosting.co.za> New submission from Ross Lagerwall: results for fa745ed89b7a on branch "default" -------------------------------------------- test_capi leaked [2, 2, 2] references, sum=6 Command line was: ['./python', '-m', 'test.regrtest', '-uall', '-R', '3:3:/home/antoine/cpython/refleaks/reflogEr4Oyp', '-x'] A fix is in progress... ---------- assignee: rosslagerwall messages: 168993 nosy: rosslagerwall priority: normal severity: normal stage: needs patch status: open title: test_capi refleak type: resource usage versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 12:13:18 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Fri, 24 Aug 2012 10:13:18 +0000 Subject: [issue15765] test_getcwd_long_pathnames (in test_posix) kills NetBSD In-Reply-To: <1345738839.66.0.851706440072.issue15765@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: This doesn't look thread-related: """ load: 0.50 cmd: python 10630 [runnable] 0.27u 13.07s 46% 10976k load: 0.87 cmd: python 10630 [runnable] 0.27u 94.24s 98% 10976k """ See the huge system time? This probably means that the kernel is struggling with path name resolution, although that's surprising because 4099 is a reasonable limit. Do you have something like strace or truss on NetBSD? The first thing to try could be to lower the limit, and see what happens, but it's really likely a FS scalibility limit you're hitting (altough, once again, that's really surprising given the reasonable limit). Are you running those under VMs? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 12:28:27 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 24 Aug 2012 10:28:27 +0000 Subject: [issue15753] No-argument super in method with variable arguments raises SystemError In-Reply-To: <1345549960.82.0.102703520127.issue15753@psf.upfronthosting.co.za> Message-ID: <1345804107.26.0.369954358658.issue15753@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: The failing assertion is the "assert(PyTuple_Check(obj))" added by your patch. At this point, "obj" is not the arguments tuple, but the first entry in "f->f_localsplus". Maybe this block should be moved a bit earlier? ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 12:43:34 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Fri, 24 Aug 2012 10:43:34 +0000 Subject: [issue15634] Add serialized decorator to the threading module In-Reply-To: <1344845068.87.0.536585589553.issue15634@psf.upfronthosting.co.za> Message-ID: <1345805014.1.0.573234401187.issue15634@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: "synchronized" has the merit of reusing Java's denomination, which this decorator intends to mimic, see http://docs.oracle.com/javase/tutorial/essential/concurrency/syncmeth.html Basically, synchronize works with the object/class (implicit) reentrant lock. ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 13:17:16 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 24 Aug 2012 11:17:16 +0000 Subject: [issue15753] No-argument super in method with variable arguments raises SystemError In-Reply-To: <1345549960.82.0.102703520127.issue15753@psf.upfronthosting.co.za> Message-ID: <1345807036.69.0.753833915028.issue15753@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 13:19:18 2012 From: report at bugs.python.org (James) Date: Fri, 24 Aug 2012 11:19:18 +0000 Subject: [issue15753] No-argument super in method with variable arguments raises SystemError In-Reply-To: <1345549960.82.0.102703520127.issue15753@psf.upfronthosting.co.za> Message-ID: <1345807158.4.0.172775075852.issue15753@psf.upfronthosting.co.za> James added the comment: Sorry, I wasn't very clear. super() currently works by assuming that self is the first entry in f_localsplus, which is defeated, for example, by doing: >>> class A: ... def f(self): ... del self ... super() ... >>> A().f() Traceback (most recent call last): File "", line 1, in File "", line 4, in f SystemError: super(): arg[0] deleted >>> class B: ... def f(self): ... self = 1 ... super() ... >>> B().f() Traceback (most recent call last): File "", line 1, in File "", line 4, in f TypeError: super(type, obj): obj must be an instance or subtype of type I don't know if this is the intended behaviour (in which case, my assertion that obj is a tuple should be replaced by just checking whether it is a tuple and raising an exception otherwise; and I suppose the super documentation should mention this caveat), or whether this should be fixed somehow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 13:31:41 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 24 Aug 2012 11:31:41 +0000 Subject: [issue15776] Allow pyvenv to work in existing directory In-Reply-To: <1345799746.88.0.728928529816.issue15776@psf.upfronthosting.co.za> Message-ID: <1345807901.45.0.108123400939.issue15776@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Does it mean implicit implying --upgrade option if venv dir is '.'? ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 13:37:28 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 24 Aug 2012 11:37:28 +0000 Subject: [issue15777] test_capi refleak In-Reply-To: <1345803195.05.0.615891441008.issue15777@psf.upfronthosting.co.za> Message-ID: <3X3L7q164VzQ8n@mail.python.org> Roundup Robot added the comment: New changeset 081507b4ae40 by Ross Lagerwall in branch '3.2': Issue 15777: Fix a refleak in _posixsubprocess. http://hg.python.org/cpython/rev/081507b4ae40 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 13:42:42 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 24 Aug 2012 11:42:42 +0000 Subject: [issue14455] plistlib unable to read json and binary plist files In-Reply-To: <1333144578.81.0.343123708942.issue14455@psf.upfronthosting.co.za> Message-ID: <1345808562.56.0.946824405369.issue14455@psf.upfronthosting.co.za> Ronald Oussoren added the comment: plutil(1) supports writing json format. That written, the opensource parts of CoreFoundation on opensource.apple.com don't support reading or writing json files. I'm therefore -1 w.r.t. adding support for json formatted plist files, support for json can be added when Apple actually supports that it the system libraries and hence the format is stable. ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 13:48:21 2012 From: report at bugs.python.org (moijes12) Date: Fri, 24 Aug 2012 11:48:21 +0000 Subject: [issue626452] Support RFC 2392 in email package Message-ID: <1345808901.84.0.729901345778.issue626452@psf.upfronthosting.co.za> moijes12 added the comment: r.david.murray: I'd love to work on this and that is why I'm following this and 634412. But I'm just getting started with contributing to Python and I've contributed to only to 15442 and thats not even accepted yet. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 14:02:01 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 24 Aug 2012 12:02:01 +0000 Subject: [issue15753] No-argument super in method with variable arguments raises SystemError In-Reply-To: <1345549960.82.0.102703520127.issue15753@psf.upfronthosting.co.za> Message-ID: <1345809721.08.0.593871424763.issue15753@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Changing exception type is not backward compatible and should be documented at least if that change is really required. Personally I slightly prefer to leave SystemError untouched ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 14:06:14 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 24 Aug 2012 12:06:14 +0000 Subject: [issue15751] Add PyGILState_SwitchInterpreter In-Reply-To: <1345526301.75.0.455071650321.issue15751@psf.upfronthosting.co.za> Message-ID: <1345809974.88.0.561443296725.issue15751@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 14:07:10 2012 From: report at bugs.python.org (=?utf-8?b?TWljaGFsIEJvxb5vxYg=?=) Date: Fri, 24 Aug 2012 12:07:10 +0000 Subject: [issue10606] Misspelling of Jamie Zawinski's surname in urllib.parse docstring In-Reply-To: <1291306622.05.0.84644269608.issue10606@psf.upfronthosting.co.za> Message-ID: <1345810030.62.0.636112294331.issue10606@psf.upfronthosting.co.za> Michal Bo?o? added the comment: this is still unfixed in Python 2.x ---------- nosy: +mykhal versions: +Python 2.6, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 14:17:44 2012 From: report at bugs.python.org (Vinay Sajip) Date: Fri, 24 Aug 2012 12:17:44 +0000 Subject: [issue15776] Allow pyvenv to work in existing directory In-Reply-To: <1345799746.88.0.728928529816.issue15776@psf.upfronthosting.co.za> Message-ID: <1345810664.74.0.331122168178.issue15776@psf.upfronthosting.co.za> Vinay Sajip added the comment: Running pyvenv --clear . should work, but doesn't because of the way the venv directory is initialised - a shutil.rmtree() call is used. This can cause problems on Windows (current directory is regarded as open and so cannot be deleted) and also on Posix, because the inode changes and you get "file not found" errors because e.g. the shell has pointers to the old inode and the venv files are added to the new inode. The attached patch should work, as it deletes the venv directory contents rather than the venv directory itself. I'll just check with Georg that it's OK to commit this - I don't see any problem, as it's a bug-fix rather than a new feature, but I think it best to run it past him. ---------- keywords: +patch nosy: +georg.brandl Added file: http://bugs.python.org/file26983/pyvenv.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 14:28:20 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 24 Aug 2012 12:28:20 +0000 Subject: [issue13370] test_ctypes fails when building python with clang In-Reply-To: <1320761474.93.0.268896325495.issue13370@psf.upfronthosting.co.za> Message-ID: <1345811300.61.0.755037572795.issue13370@psf.upfronthosting.co.za> Ronald Oussoren added the comment: What code duplication do you mean? The code in the switch statement at line 71 looks similar for the various case, but it isn't: there is variation in the types uses in the casts (and particularly in the cast used to read the input value). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 14:28:41 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 24 Aug 2012 12:28:41 +0000 Subject: [issue13370] test_ctypes fails when building python with clang In-Reply-To: <1320761474.93.0.268896325495.issue13370@psf.upfronthosting.co.za> Message-ID: <1345811321.94.0.256694844598.issue13370@psf.upfronthosting.co.za> Changes by Ronald Oussoren : Removed file: http://bugs.python.org/file26972/smime.p7s _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 14:31:44 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 24 Aug 2012 12:31:44 +0000 Subject: [issue13370] test_ctypes fails when building python with clang In-Reply-To: <1320761474.93.0.268896325495.issue13370@psf.upfronthosting.co.za> Message-ID: <1345811504.89.0.948263900653.issue13370@psf.upfronthosting.co.za> Ronald Oussoren added the comment: Attached version of the patch without the change to the powerpc specific code. I will commit this version later today (after another testing round). ---------- Added file: http://bugs.python.org/file26984/issue_13370-2.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 14:33:39 2012 From: report at bugs.python.org (Trent Nelson) Date: Fri, 24 Aug 2012 12:33:39 +0000 Subject: [issue15748] Various symlink test failures in test_shutil on FreeBSD In-Reply-To: <1345516038.44.0.114148239105.issue15748@psf.upfronthosting.co.za> Message-ID: <1345811619.79.0.19004865612.issue15748@psf.upfronthosting.co.za> Trent Nelson added the comment: Link to my freebsd-fs e-mail: http://lists.freebsd.org/pipermail/freebsd-fs/2012-August/014964.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 14:35:56 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 24 Aug 2012 12:35:56 +0000 Subject: [issue15751] Add PyGILState_SwitchInterpreter In-Reply-To: <1345526301.75.0.455071650321.issue15751@psf.upfronthosting.co.za> Message-ID: <1345811756.54.0.301559045079.issue15751@psf.upfronthosting.co.za> Nick Coghlan added the comment: I'm not sure it makes sense to call this new API "PyGILState_EnsureEx". My concern is that the behaviour is quite different in the presence of an existing thread state: Ensure: - if a thread state exists, use that interpreter - otherwise, use the default interpreter configured in the pystate.c globals New API: - if a thread state exists, and the interpreter doesn't match the requested one, fail with an error - otherwise, use the requested interpreter I guess it makes sense if we treat the NULL pointer as the degenerate case meaning "use the interpreter of this thread, or the default interpreter if no interpreter has been declared for this thread". PyGILState_Ensure would then simply call PyGILState_EnsureEx(NULL) internally. So, my question for Graham would be, given this ability, would mod_wsgi still need the ability to change the default interpreter? Or would it be enough for you to be able to register the threads *you* create with a specific interpreter? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 14:42:54 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 24 Aug 2012 12:42:54 +0000 Subject: [issue15776] Allow pyvenv to work in existing directory In-Reply-To: <1345799746.88.0.728928529816.issue15776@psf.upfronthosting.co.za> Message-ID: <1345812174.35.0.325267716661.issue15776@psf.upfronthosting.co.za> Andrew Svetlov added the comment: I don't like current --clear behavior, it's really useless because now venv just deletes everything from virtual environment. You lose not only virtual env but files from your project also. virtualenv cleans only /Lib directory, that's much better. I think venv --clear should cleanup everything which it creates (I mean bin/include/lib for Posix and Scripts/Include/Lib for Windows). Not sure about pyvenv.cfg ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 14:45:06 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 24 Aug 2012 12:45:06 +0000 Subject: [issue15751] Add PyGILState_SwitchInterpreter In-Reply-To: <1345811756.54.0.301559045079.issue15751@psf.upfronthosting.co.za> Message-ID: <1345812105.3368.5.camel@localhost.localdomain> Antoine Pitrou added the comment: > New API: > - if a thread state exists, and the interpreter doesn't match the > requested one, fail with an error > - otherwise, use the requested interpreter That's not what I'm proposing. What I'm proposing is that the new API uses a per-interpreter TLS key (so you can have several thread states per OS thread). So basically: Ensure: - look up global TLS key, which returns the thread state - if no thread state (TLS lookup failed), create a new one for the main interpreter and register it on the global TLS key New API: - look up the interpreter's TLS key, which returns the thread state - if no thread state (TLS lookup failed), create a new one for the interpreter and register it on the interpreter's TLS key Graham is merely suggesting for simplification that "global TLS key" == "main interpreter's TLS key", so Ensure(...) == EnsureEx(main_interpreter, ...). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 14:50:58 2012 From: report at bugs.python.org (Vinay Sajip) Date: Fri, 24 Aug 2012 12:50:58 +0000 Subject: [issue15776] Allow pyvenv to work in existing directory In-Reply-To: <1345799746.88.0.728928529816.issue15776@psf.upfronthosting.co.za> Message-ID: <1345812658.58.0.151575585015.issue15776@psf.upfronthosting.co.za> Vinay Sajip added the comment: Venvs should be regarded as throwaway; there is really no reason to add other files (e.g. project files) to venvs. Two common patterns are: 1. Use a single place for all venvs (virtualenvwrapper does this) 2. Use a venv in a subdirectory of a project directory The current implementation follows PEP 405, and the functionality was discussed on python-dev before being finalised. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 14:53:44 2012 From: report at bugs.python.org (Trent Nelson) Date: Fri, 24 Aug 2012 12:53:44 +0000 Subject: [issue15765] test_getcwd_long_pathnames (in test_posix) kills NetBSD In-Reply-To: <1345644735.97.0.561553846154.issue15765@psf.upfronthosting.co.za> Message-ID: <1345812824.79.0.649641320795.issue15765@psf.upfronthosting.co.za> Trent Nelson added the comment: Hacked the test to print out info each loop: test_getcwd_long_pathnames (test.test_posix.PosixTester) ... [0/0] getcwd-test-directory-0123456789abcdef-01234567890abcdef [1/57] getcwd-test-directory-0123456789abcdef-01234567890abcdef [2/114] getcwd-test-directory-0123456789abcdef-01234567890abcdef [3/171] getcwd-test-directory-0123456789abcdef-01234567890abcdef [4/228] getcwd-test-directory-0123456789abcdef-01234567890abcdef [5/285] getcwd-test-directory-0123456789abcdef-01234567890abcdef [6/342] getcwd-test-directory-0123456789abcdef-01234567890abcdef [7/399] getcwd-test-directory-0123456789abcdef-01234567890abcdef [8/456] getcwd-test-directory-0123456789abcdef-01234567890abcdef [9/513] getcwd-test-directory-0123456789abcdef-01234567890abcdef [10/570] getcwd-test-directory-0123456789abcdef-01234567890abcdef [11/627] getcwd-test-directory-0123456789abcdef-01234567890abcdef [12/684] getcwd-test-directory-0123456789abcdef-01234567890abcdef [13/741] getcwd-test-directory-0123456789abcdef-01234567890abcdef [14/798] getcwd-test-directory-0123456789abcdef-01234567890abcdef [15/855] getcwd-test-directory-0123456789abcdef-01234567890abcdef [16/912] getcwd-test-directory-0123456789abcdef-01234567890abcdef [17/969] getcwd-test-directory-0123456789abcdef-01234567890abcdef [18/1026] getcwd-test-directory-0123456789abcdef-01234567890abcdef [19/1083] getcwd-test-directory-0123456789abcdef-01234567890abcdef [20/1140] getcwd-test-directory-0123456789abcdef-01234567890abcdef [21/1197] getcwd-test-directory-0123456789abcdef-01234567890abcdef [22/1254] getcwd-test-directory-0123456789abcdef-01234567890abcdef [23/1311] getcwd-test-directory-0123456789abcdef-01234567890abcdef [24/1368] getcwd-test-directory-0123456789abcdef-01234567890abcdef [25/1425] getcwd-test-directory-0123456789abcdef-01234567890abcdef [26/1482] getcwd-test-directory-0123456789abcdef-01234567890abcdef [27/1539] getcwd-test-directory-0123456789abcdef-01234567890abcdef [28/1596] getcwd-test-directory-0123456789abcdef-01234567890abcdef [29/1653] getcwd-test-directory-0123456789abcdef-01234567890abcdef [30/1710] getcwd-test-directory-0123456789abcdef-01234567890abcdef [31/1767] getcwd-test-directory-0123456789abcdef-01234567890abcdef [32/1824] getcwd-test-directory-0123456789abcdef-01234567890abcdef [33/1881] getcwd-test-directory-0123456789abcdef-01234567890abcdef [34/1938] getcwd-test-directory-0123456789abcdef-01234567890abcdef [35/1995] getcwd-test-directory-0123456789abcdef-01234567890abcdef [36/2052] getcwd-test-directory-0123456789abcdef-01234567890abcdef [37/2109] getcwd-test-directory-0123456789abcdef-01234567890abcdef [38/2166] getcwd-test-directory-0123456789abcdef-01234567890abcdef [39/2223] getcwd-test-directory-0123456789abcdef-01234567890abcdef [40/2280] getcwd-test-directory-0123456789abcdef-01234567890abcdef [41/2337] getcwd-test-directory-0123456789abcdef-01234567890abcdef [42/2394] getcwd-test-directory-0123456789abcdef-01234567890abcdef [43/2451] getcwd-test-directory-0123456789abcdef-01234567890abcdef [44/2508] getcwd-test-directory-0123456789abcdef-01234567890abcdef [45/2565] getcwd-test-directory-0123456789abcdef-01234567890abcdef [46/2622] getcwd-test-directory-0123456789abcdef-01234567890abcdef [47/2679] getcwd-test-directory-0123456789abcdef-01234567890abcdef [48/2736] getcwd-test-directory-0123456789abcdef-01234567890abcdef [49/2793] getcwd-test-directory-0123456789abcdef-01234567890abcdef [50/2850] getcwd-test-directory-0123456789abcdef-01234567890abcdef [51/2907] getcwd-test-directory-0123456789abcdef-01234567890abcdef [52/2964] getcwd-test-directory-0123456789abcdef-01234567890abcdef [53/3021] getcwd-test-directory-0123456789abcdef-01234567890abcdef [54/3078] getcwd-test-directory-0123456789abcdef-01234567890abcdef [55/3135] getcwd-test-directory-0123456789abcdef-01234567890abcdef [56/3192] getcwd-test-directory-0123456789abcdef-01234567890abcdef [57/3249] getcwd-test-directory-0123456789abcdef-01234567890abcdef [58/3306] getcwd-test-directory-0123456789abcdef-01234567890abcdef [59/3363] getcwd-test-directory-0123456789abcdef-01234567890abcdef [60/3420] getcwd-test-directory-0123456789abcdef-01234567890abcdef [61/3477] getcwd-test-directory-0123456789abcdef-01234567890abcdef [62/3534] getcwd-test-directory-0123456789abcdef-01234567890abcdef [63/3591] getcwd-test-directory-0123456789abcdef-01234567890abcdef [64/3648] getcwd-test-directory-0123456789abcdef-01234567890abcdef [65/3705] getcwd-test-directory-0123456789abcdef-01234567890abcdef [66/3762] getcwd-test-directory-0123456789abcdef-01234567890abcdef [67/3819] getcwd-test-directory-0123456789abcdef-01234567890abcdef [68/3876] getcwd-test-directory-0123456789abcdef-01234567890abcdef [69/3933] getcwd-test-directory-0123456789abcdef-01234567890abcdef [70/3990] getcwd-test-directory-0123456789abcdef-01234567890abcdef ^C^C load: 1.08 cmd: python 4486 [runnable] 0.07u 14.38s 40% 10012k load: 1.08 cmd: python 4486 [runnable] 0.07u 14.91s 40% 10012k load: 1.08 cmd: python 4486 [runnable] 0.07u 15.24s 42% 10012k load: 1.08 cmd: python 4486 [runnable] 0.07u 15.40s 42% 10012k Terminated (Had to kill it from a different process, mind you; the ctrl-Cs never get caught.) Yeah, it's a VM. Also, it looks like 3.x uses 1027 instead of 4099. It's definitely odd that it ends up spinning in the kernel at ~3990. I'll do some more digging. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 14:55:43 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 24 Aug 2012 12:55:43 +0000 Subject: [issue15751] Support subinterpreters in the GIL state API In-Reply-To: <1345526301.75.0.455071650321.issue15751@psf.upfronthosting.co.za> Message-ID: <1345812943.18.0.909603149957.issue15751@psf.upfronthosting.co.za> Nick Coghlan added the comment: And the current "autoTLSkey" could move into the interpreter state object? I like it - that's a lot more flexible than the approach I was thinking of. ---------- title: Add PyGILState_SwitchInterpreter -> Support subinterpreters in the GIL state API _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 15:00:29 2012 From: report at bugs.python.org (Graham Dumpleton) Date: Fri, 24 Aug 2012 13:00:29 +0000 Subject: [issue15751] Support subinterpreters in the GIL state API In-Reply-To: <1345526301.75.0.455071650321.issue15751@psf.upfronthosting.co.za> Message-ID: <1345813229.28.0.205213121837.issue15751@psf.upfronthosting.co.za> Graham Dumpleton added the comment: It is past my bed time and not thinking straight, but I believe Antoine is aligned with what I had in mind, as need multiple thread states per OS thread where each is associated with separate interpreter. My main reason for allowing NULL to EnsureEX rather than requiring main_interpreter to be explicitly passed, is that way way back in time, my recollection is that getting access to the main interpreter pointer was a pain as you had to iterate over the list of interpreters and assume it was the last one due to it being created first. I don't remember there being a special global variable or function for getting a pointer to the main interpreter. This may well have changed since and there is an easier way do let me know. So saw it as a convenience. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 15:03:03 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 24 Aug 2012 13:03:03 +0000 Subject: [issue15776] Allow pyvenv to work in existing directory In-Reply-To: <1345799746.88.0.728928529816.issue15776@psf.upfronthosting.co.za> Message-ID: <1345813383.52.0.0517088357582.issue15776@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Well, I see. Agree with your patch then, it is correct. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 15:22:04 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 24 Aug 2012 13:22:04 +0000 Subject: [issue15511] _decimal does not build in PGUpdate mode In-Reply-To: <1343720342.96.0.267944398489.issue15511@psf.upfronthosting.co.za> Message-ID: <3X3NSW2X45zPrb@mail.python.org> Roundup Robot added the comment: New changeset cbd4fbb90e95 by Martin v. L?wis in branch 'default': Issue #15511: Drop explicit dependency on pythonxy.lib from amd64 configuration. http://hg.python.org/cpython/rev/cbd4fbb90e95 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 15:24:37 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 24 Aug 2012 13:24:37 +0000 Subject: [issue15511] _decimal does not build in PGUpdate mode In-Reply-To: <1343720342.96.0.267944398489.issue15511@psf.upfronthosting.co.za> Message-ID: <1345814677.71.0.409178082062.issue15511@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I now recall that I worked around this issue, by just copying python33.lib in the place where it's expected. The right solution is not to configure a dependency on the .lib, as it will automatically be added by the pragma in the include file. The search path comes from the property files. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 15:56:11 2012 From: report at bugs.python.org (Vinay Sajip) Date: Fri, 24 Aug 2012 13:56:11 +0000 Subject: [issue15710] logging module crashes in Python 2.7.3 for handler.setLevel(long) In-Reply-To: <1345152839.48.0.661799461902.issue15710@psf.upfronthosting.co.za> Message-ID: <1345816571.21.0.373880661567.issue15710@psf.upfronthosting.co.za> Vinay Sajip added the comment: I don't feel it would be correct to allow long for log levels, since a log level is not intended to have that range. It would be more sensible to get the ESAPI developers to use a more appropriate boundary value; in general, negative log values are not used (they are not necessary). ---------- resolution: -> invalid status: open -> pending type: crash -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 15:59:19 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 24 Aug 2012 13:59:19 +0000 Subject: [issue15710] logging module crashes in Python 2.7.3 for handler.setLevel(long) In-Reply-To: <1345152839.48.0.661799461902.issue15710@psf.upfronthosting.co.za> Message-ID: <1345816759.76.0.146426360449.issue15710@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This seems to miss the point that it's a regression. int and long are supposed to be interchangeable for most purposes. ---------- nosy: +pitrou status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 16:00:36 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 24 Aug 2012 14:00:36 +0000 Subject: [issue15758] FileIO.readall() has worst case O(n^2) complexity In-Reply-To: <1345587910.43.0.919180045188.issue15758@psf.upfronthosting.co.za> Message-ID: <1345816836.91.0.721990909934.issue15758@psf.upfronthosting.co.za> Richard Oudkerk added the comment: After playing with the patch on Linux it seems that Linux much prefers the realloc() scheme to the list-of-chunks scheme. This new patch only does list-of-chunks on Windows. ---------- Added file: http://bugs.python.org/file26985/readall-combined.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 16:02:16 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 24 Aug 2012 14:02:16 +0000 Subject: [issue15758] FileIO.readall() has worst case O(n^2) complexity In-Reply-To: <1345587910.43.0.919180045188.issue15758@psf.upfronthosting.co.za> Message-ID: <1345816936.88.0.585556084773.issue15758@psf.upfronthosting.co.za> Richard Oudkerk added the comment: Attached is an alternative benchmark program which does not use subprocess. ---------- Added file: http://bugs.python.org/file26986/readall-benchmark.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 16:02:30 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 24 Aug 2012 14:02:30 +0000 Subject: [issue15758] FileIO.readall() has worst case O(n^2) complexity In-Reply-To: <1345587910.43.0.919180045188.issue15758@psf.upfronthosting.co.za> Message-ID: <1345816950.06.0.852587386123.issue15758@psf.upfronthosting.co.za> Changes by Richard Oudkerk : Removed file: http://bugs.python.org/file26952/push-thru-cat.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 16:02:38 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 24 Aug 2012 14:02:38 +0000 Subject: [issue15758] FileIO.readall() has worst case O(n^2) complexity In-Reply-To: <1345587910.43.0.919180045188.issue15758@psf.upfronthosting.co.za> Message-ID: <1345816958.49.0.596729657258.issue15758@psf.upfronthosting.co.za> Changes by Richard Oudkerk : Removed file: http://bugs.python.org/file26970/readall-combined.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 16:11:50 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 24 Aug 2012 14:11:50 +0000 Subject: [issue15758] FileIO.readall() has worst case O(n^2) complexity In-Reply-To: <1345816836.91.0.721990909934.issue15758@psf.upfronthosting.co.za> Message-ID: <1345817304.3368.7.camel@localhost.localdomain> Antoine Pitrou added the comment: > After playing with the patch on Linux it seems that Linux much prefers > the realloc() scheme to the list-of-chunks scheme. What about the method call overhead in RawIO.readall(), and the different progression of buffer sizes? (the realloc scheme uses larger and larger read() sizes, while RawIO.readall() uses a constant read() size). By the way, not every non-Windows OS is Linux, so the patch is wrong. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 16:22:47 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 24 Aug 2012 14:22:47 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1345818167.6.0.98018352197.issue15573@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Is this still blocking the release? If so, it should be resolved within the next twelve hours, or else it may block the release until September. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 16:34:22 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 24 Aug 2012 14:34:22 +0000 Subject: [issue15442] Expand the list of default dirs filecmp.dircmp ignores In-Reply-To: <1343147532.2.0.187379599839.issue15442@psf.upfronthosting.co.za> Message-ID: <1345818862.98.0.521286165867.issue15442@psf.upfronthosting.co.za> R. David Murray added the comment: moijes12, thanks for the patch. Since this is a new feature we'll need to wait until the 3.3 RC1 repo is branched before applying it. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 16:43:10 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 24 Aug 2012 14:43:10 +0000 Subject: [issue15037] curses.unget_wch and test_curses fail when linked with ncurses 5.7 and earlier In-Reply-To: <1339171712.6.0.747270716657.issue15037@psf.upfronthosting.co.za> Message-ID: <1345819390.96.0.712336174682.issue15037@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Why is this blocking the release? It looks like a problem that can be solved in a bug fix release, or else by requiring that Python 3.3 users use a recent ncurses release. ---------- nosy: +loewis priority: release blocker -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 16:48:48 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 24 Aug 2012 14:48:48 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1317341390.65.0.255779328054.issue13072@psf.upfronthosting.co.za> Message-ID: <1345819728.46.0.0905116644917.issue13072@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Stefan, your patch array_deprecate_u.diff is fine. If you get to it, please also rephrase the clause "Python's unicode type"; not sure what the convention is to refer to Py_UNICODE now (perhaps "historical unicode type"). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 17:25:44 2012 From: report at bugs.python.org (Trent Nelson) Date: Fri, 24 Aug 2012 15:25:44 +0000 Subject: [issue15765] test_getcwd_long_pathnames (in test_posix) kills NetBSD In-Reply-To: <1345644735.97.0.561553846154.issue15765@psf.upfronthosting.co.za> Message-ID: <1345821944.67.0.134377703806.issue15765@psf.upfronthosting.co.za> Trent Nelson added the comment: Looks like this is a duplicate of issue 9185. The fix used for that just needs to be extended to cover NetBSD as well. See proposed patch. I'll commit this to 2.7 in a day or two if there are no objections. Antoine: added you as nosy as you were involved with the original patch. ---------- keywords: +patch resolution: -> duplicate Added file: http://bugs.python.org/file26987/getcwd_netbsd.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 17:31:41 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 24 Aug 2012 15:31:41 +0000 Subject: [issue15249] email.generator.BytesGenerator doesn't mangle "From " lines when non-ASCII bytes are present In-Reply-To: <1341396786.66.0.201550976108.issue15249@psf.upfronthosting.co.za> Message-ID: <3X3RL404MBzQBy@mail.python.org> Roundup Robot added the comment: New changeset 119c645f310e by R David Murray in branch '3.2': #15249: Mangle From lines correctly when body contains invalid bytes. http://hg.python.org/cpython/rev/119c645f310e New changeset b6ee4e8c7a77 by R David Murray in branch 'default': Merge #15249: Mangle From lines correctly when body contains invalid bytes. http://hg.python.org/cpython/rev/b6ee4e8c7a77 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 17:33:15 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 24 Aug 2012 15:33:15 +0000 Subject: [issue15249] email.generator.BytesGenerator doesn't mangle "From " lines when non-ASCII bytes are present In-Reply-To: <1341396786.66.0.201550976108.issue15249@psf.upfronthosting.co.za> Message-ID: <1345822395.88.0.896479731971.issue15249@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, LittleQ. And Petri. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 17:54:33 2012 From: report at bugs.python.org (Georg Brandl) Date: Fri, 24 Aug 2012 15:54:33 +0000 Subject: [issue15776] Allow pyvenv to work in existing directory In-Reply-To: <1345799746.88.0.728928529816.issue15776@psf.upfronthosting.co.za> Message-ID: <1345823673.7.0.0407919510722.issue15776@psf.upfronthosting.co.za> Georg Brandl added the comment: LGTM, please apply. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 17:57:55 2012 From: report at bugs.python.org (Georg Brandl) Date: Fri, 24 Aug 2012 15:57:55 +0000 Subject: [issue15316] runpy swallows ImportError information with relative imports In-Reply-To: <1341898758.4.0.623810416258.issue15316@psf.upfronthosting.co.za> Message-ID: <1345823875.74.0.36870648596.issue15316@psf.upfronthosting.co.za> Georg Brandl added the comment: I don't agree that this is a blocker; would be nice to fix it, of course. ---------- priority: release blocker -> critical _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 17:58:19 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 24 Aug 2012 15:58:19 +0000 Subject: [issue15776] Allow pyvenv to work in existing directory In-Reply-To: <1345799746.88.0.728928529816.issue15776@psf.upfronthosting.co.za> Message-ID: <1345823899.82.0.194995657882.issue15776@psf.upfronthosting.co.za> Antoine Pitrou added the comment: os.path.isdir("foo") will return True if "foo" is a symlink to a directory, and then shutil.rmtree("foo") will fail: >>> os.path.isdir("foo") True >>> os.path.islink("foo") True >>> shutil.rmtree("foo") Traceback (most recent call last): File "", line 1, in File "/home/antoine/opt/lib/python3.3/shutil.py", line 456, in rmtree "Not a directory: '{}'".format(path)) NotADirectoryError: [Errno 20] Not a directory: 'foo' ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 18:00:28 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 24 Aug 2012 16:00:28 +0000 Subject: [issue15776] Allow pyvenv to work in existing directory In-Reply-To: <1345799746.88.0.728928529816.issue15776@psf.upfronthosting.co.za> Message-ID: <3X3RzH3sbVzQ8G@mail.python.org> Roundup Robot added the comment: New changeset 0668fc196ce5 by Andrew Svetlov in branch 'default': Issue #15776: Allow pyvenv to work in existing directory with --clean. http://hg.python.org/cpython/rev/0668fc196ce5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 18:03:52 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 24 Aug 2012 16:03:52 +0000 Subject: [issue15776] Allow pyvenv to work in existing directory In-Reply-To: <1345799746.88.0.728928529816.issue15776@psf.upfronthosting.co.za> Message-ID: <1345824232.59.0.913618748669.issue15776@psf.upfronthosting.co.za> Andrew Svetlov added the comment: It is bug in shutil.rmtree, right? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 18:04:42 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 24 Aug 2012 16:04:42 +0000 Subject: [issue15136] Decimal accepting Fraction In-Reply-To: <1340365912.14.0.935631231431.issue15136@psf.upfronthosting.co.za> Message-ID: <1345824282.58.0.211758782405.issue15136@psf.upfronthosting.co.za> Stefan Krah added the comment: I agree with Mark's arguments. Yesterday I tried to use as_decimal() in a small program and it did not feel natural to me. I'll probably continue to use Decimal(f.numerator) / f.denominator. If this goes in, I'd prefer that as_decimal() always uses a localcontext(). As the patch stands, using as_decimal() pollutes the global context flags, which can be quite unexpected: >>> from fractions import Fraction as F >>> F(1, 3).as_decimal() Decimal('0.3333333333333333333333333333') >>> >>> import decimal >>> decimal.getcontext() Context(prec=28, rounding=ROUND_HALF_EVEN, Emin=-999999, Emax=999999, capitals=1, clamp=0, flags=[Inexact, Rounded], traps=[InvalidOperation, DivisionByZero, Overflow]) >>> If the function takes a context argument, it might be better to move it into the decimal module as Decimal.from_fraction(context). So I'm -1/7 on as_decimal(), but +1 for the __format__() method. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 18:07:32 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 24 Aug 2012 16:07:32 +0000 Subject: [issue15316] runpy swallows ImportError information with relative imports In-Reply-To: <1341898758.4.0.623810416258.issue15316@psf.upfronthosting.co.za> Message-ID: <1345824452.0.0.951062532838.issue15316@psf.upfronthosting.co.za> Brett Cannon added the comment: It will get fixed today. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 18:08:45 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 24 Aug 2012 16:08:45 +0000 Subject: [issue15776] Allow pyvenv to work in existing directory In-Reply-To: <1345824232.59.0.913618748669.issue15776@psf.upfronthosting.co.za> Message-ID: <1345824323.3368.8.camel@localhost.localdomain> Antoine Pitrou added the comment: > It is bug in shutil.rmtree, right? Read the documentation: shutil.rmtree(path, ignore_errors=False, onerror=None) Delete an entire directory tree; path must point to a directory (but not a symbolic link to a directory) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 18:10:56 2012 From: report at bugs.python.org (Georg Brandl) Date: Fri, 24 Aug 2012 16:10:56 +0000 Subject: [issue15776] Allow pyvenv to work in existing directory In-Reply-To: <1345799746.88.0.728928529816.issue15776@psf.upfronthosting.co.za> Message-ID: <1345824656.94.0.0968235688683.issue15776@psf.upfronthosting.co.za> Georg Brandl added the comment: Another *perfect* example how even the most innocuous-seeming patch can be wrong. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 18:13:00 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 24 Aug 2012 16:13:00 +0000 Subject: [issue9374] urlparse should parse query and fragment for arbitrary schemes In-Reply-To: <1280012321.31.0.791086727515.issue9374@psf.upfronthosting.co.za> Message-ID: <1345824780.0.0.679120760249.issue9374@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Senthil, either the module globals should be re-added for compatibility, or the commits should be reverted, IMO. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 18:17:37 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 24 Aug 2012 16:17:37 +0000 Subject: [issue9374] urlparse should parse query and fragment for arbitrary schemes In-Reply-To: <1280012321.31.0.791086727515.issue9374@psf.upfronthosting.co.za> Message-ID: <3X3SM42p0PzQKf@mail.python.org> Roundup Robot added the comment: New changeset a0b3cb52816e by Georg Brandl in branch '3.2': Closes #9374: add back now-unused module attributes; removing them is a backward compatibility issue, since they have a public-seeming name. http://hg.python.org/cpython/rev/a0b3cb52816e New changeset c93fbc2caba5 by Georg Brandl in branch 'default': Closes #9374: merge with 3.2 http://hg.python.org/cpython/rev/c93fbc2caba5 New changeset a43481210964 by Georg Brandl in branch '2.7': Closes #9374: add back now-unused module attributes; removing them is a backward compatibility issue, since they have a public-seeming name. http://hg.python.org/cpython/rev/a43481210964 ---------- resolution: remind -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 18:19:32 2012 From: report at bugs.python.org (Georg Brandl) Date: Fri, 24 Aug 2012 16:19:32 +0000 Subject: [issue15776] Allow pyvenv to work in existing directory In-Reply-To: <1345799746.88.0.728928529816.issue15776@psf.upfronthosting.co.za> Message-ID: <1345825172.7.0.648900964283.issue15776@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 18:20:01 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 24 Aug 2012 16:20:01 +0000 Subject: [issue15776] Allow pyvenv to work in existing directory In-Reply-To: <1345799746.88.0.728928529816.issue15776@psf.upfronthosting.co.za> Message-ID: <1345825201.73.0.644269700871.issue15776@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Good point. I will prepare the patch to fix this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 18:38:45 2012 From: report at bugs.python.org (Dave Malcolm) Date: Fri, 24 Aug 2012 16:38:45 +0000 Subject: [issue15778] str(ImportError(b'foo')) fails Message-ID: <1345826325.41.0.0972765515738.issue15778@psf.upfronthosting.co.za> New submission from Dave Malcolm: In Python 3.2 and earlier: >>> str(ImportError(b'foo')) "b'foo'" In Python 3.3: >>> str(ImportError(b'foo')) Traceback (most recent call last): File "", line 1, in TypeError: __str__ returned non-string (type bytes) This appears to be due to commit 76272. I'm attaching a patch which fixes it, though perhaps ImportError should type-check the arguments Motivation: This leads to a failure of the test suite for "docutils" when run under Python 3.3 betas, specifically: ====================================================================== ERROR: test_unicode (test_error_reporting.ErrorStringTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/david/coding/python3.3/docutils/trunk/docutils/test3/test_error_reporting.py", line 154, in test_unicode str(ErrorString(ImportError(self.bs)))) File "/home/david/coding/python3.3/docutils/trunk/docutils/build/lib/docutils/utils/error_reporting.py", line 124, in __str__ super(ErrorString, self).__str__()) File "/home/david/coding/python3.3/docutils/trunk/docutils/build/lib/docutils/utils/error_reporting.py", line 74, in __str__ return str(self.data) TypeError: __str__ returned non-string (type bytes) See http://docutils.svn.sourceforge.net/viewvc/docutils/trunk/docutils/test/test_error_reporting.py?revision=7464&view=markup for the test code. Arguably docutils could just pick a different exception subclass. ---------- messages: 169042 nosy: brett.cannon, dmalcolm priority: normal severity: normal status: open title: str(ImportError(b'foo')) fails type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 18:41:54 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 24 Aug 2012 16:41:54 +0000 Subject: [issue15778] str(ImportError(b'foo')) fails In-Reply-To: <1345826325.41.0.0972765515738.issue15778@psf.upfronthosting.co.za> Message-ID: <1345826514.21.0.883212573888.issue15778@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > This appears to be due to commit 76272. Could you give the changeset id? Revision numbers are not portable from one repository clone to another. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 18:42:37 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 24 Aug 2012 16:42:37 +0000 Subject: [issue15758] FileIO.readall() has worst case O(n^2) complexity In-Reply-To: <1345587910.43.0.919180045188.issue15758@psf.upfronthosting.co.za> Message-ID: <1345826557.52.0.241028642575.issue15758@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > What about the method call overhead in RawIO.readall(), and the > different progression of buffer sizes? (the realloc scheme uses larger > and larger read() sizes, while RawIO.readall() uses a constant read() > size). For this benchmark the call overhead does not seem to be noticeable, and using larger or adaptive read buffers does not seem to help either. (I have tried both on Linux.) > By the way, not every non-Windows OS is Linux, so the patch is wrong. Wrong in the sense of not necessarily optimal for unknown platforms? Well, the patch retains the old (intended) behaviour on other platforms, so I would call that conservative rather than wrong. Are you suggesting switching behaviour depending on whether some macro is defined? 64-bit Linux with current patch (and using new benchmark): amount = 1 MB; time taken = 0.003 secs; rate = 317.22 MB/s amount = 2 MB; time taken = 0.007 secs; rate = 283.74 MB/s amount = 4 MB; time taken = 0.011 secs; rate = 359.58 MB/s amount = 8 MB; time taken = 0.020 secs; rate = 395.58 MB/s amount = 16 MB; time taken = 0.030 secs; rate = 528.18 MB/s amount = 32 MB; time taken = 0.051 secs; rate = 627.72 MB/s amount = 64 MB; time taken = 0.088 secs; rate = 726.36 MB/s amount = 128 MB; time taken = 0.133 secs; rate = 960.23 MB/s amount = 256 MB; time taken = 0.258 secs; rate = 992.32 MB/s amount = 512 MB; time taken = 0.482 secs; rate = 1062.30 MB/s On 64-bit Linux with previous patch: amount = 1 MB; time taken = 0.006 secs; rate = 158.07 MB/s amount = 2 MB; time taken = 0.011 secs; rate = 177.23 MB/s amount = 4 MB; time taken = 0.024 secs; rate = 169.32 MB/s amount = 8 MB; time taken = 0.047 secs; rate = 170.39 MB/s amount = 16 MB; time taken = 0.098 secs; rate = 163.65 MB/s amount = 32 MB; time taken = 0.220 secs; rate = 145.19 MB/s amount = 64 MB; time taken = 0.253 secs; rate = 253.32 MB/s amount = 128 MB; time taken = 0.724 secs; rate = 176.80 MB/s amount = 256 MB; time taken = 0.874 secs; rate = 293.02 MB/s amount = 512 MB; time taken = 2.292 secs; rate = 223.38 MB/s ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 18:46:20 2012 From: report at bugs.python.org (Dave Malcolm) Date: Fri, 24 Aug 2012 16:46:20 +0000 Subject: [issue15778] str(ImportError(b'foo')) fails In-Reply-To: <1345826514.21.0.883212573888.issue15778@psf.upfronthosting.co.za> Message-ID: <1865076839.36641162.1345826778087.JavaMail.root@redhat.com> Dave Malcolm added the comment: Sorry, it's 6825fd9b00ed ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 18:46:55 2012 From: report at bugs.python.org (Dave Malcolm) Date: Fri, 24 Aug 2012 16:46:55 +0000 Subject: [issue15778] str(ImportError(b'foo')) fails In-Reply-To: <1345826325.41.0.0972765515738.issue15778@psf.upfronthosting.co.za> Message-ID: <1345826815.21.0.566543084177.issue15778@psf.upfronthosting.co.za> Changes by Dave Malcolm : ---------- keywords: +patch Added file: http://bugs.python.org/file26988/fix-str-of-bogus-ImportError.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 18:47:44 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 24 Aug 2012 16:47:44 +0000 Subject: [issue12623] "universal newlines" subprocess support broken with select- and poll-based communicate() In-Reply-To: <1311451893.22.0.0169745025507.issue12623@psf.upfronthosting.co.za> Message-ID: <1345826864.57.0.352131809362.issue12623@psf.upfronthosting.co.za> Andrew Svetlov added the comment: I like to leave fixes to 3.4. Any change can produce side-effects, which can be nightmare for upcoming release candidate. Sure, Georg will share my opinion. Though absence '\n' -> '\r\n' for input if OS is Windows and universal_newlines=True is not good. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 18:49:10 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 24 Aug 2012 16:49:10 +0000 Subject: [issue15758] FileIO.readall() has worst case O(n^2) complexity In-Reply-To: <1345826557.52.0.241028642575.issue15758@psf.upfronthosting.co.za> Message-ID: <1345826749.3368.12.camel@localhost.localdomain> Antoine Pitrou added the comment: > For this benchmark the call overhead does not seem to be noticeable, > and using larger or adaptive read buffers does not seem to help > either. (I have tried both on Linux.) Ok, thank you. > > By the way, not every non-Windows OS is Linux, so the patch is wrong. > > Wrong in the sense of not necessarily optimal for unknown platforms? > Well, the patch retains the old (intended) behaviour on other > platforms, so I would call that conservative rather than wrong. Hmm, you are right, there is no regression indeed. I guess I don't like very much the idea of switching code paths based on the platform for pure optimization reasons, but in this case it seems useful (and simple enough). > Are you suggesting switching behaviour depending on whether some macro > is defined? No, that would definitely be overkill. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 18:52:01 2012 From: report at bugs.python.org (Dave Malcolm) Date: Fri, 24 Aug 2012 16:52:01 +0000 Subject: [issue15778] str(ImportError(b'foo')) fails In-Reply-To: <1345826325.41.0.0972765515738.issue15778@psf.upfronthosting.co.za> Message-ID: <1345827121.63.0.726414908042.issue15778@psf.upfronthosting.co.za> Dave Malcolm added the comment: (patch added) ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 18:59:35 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 24 Aug 2012 16:59:35 +0000 Subject: [issue15778] str(ImportError(b'foo')) fails In-Reply-To: <1345826325.41.0.0972765515738.issue15778@psf.upfronthosting.co.za> Message-ID: <1345827574.94.0.142914698839.issue15778@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 19:00:04 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 24 Aug 2012 17:00:04 +0000 Subject: [issue15776] Allow pyvenv to work in existing directory In-Reply-To: <1345799746.88.0.728928529816.issue15776@psf.upfronthosting.co.za> Message-ID: <1345827604.11.0.851498685682.issue15776@psf.upfronthosting.co.za> ?ric Araujo added the comment: > Two common patterns are: > > 1. Use a single place for all venvs (virtualenvwrapper does this) > 2. Use a venv in a subdirectory of a project directory I?m a recent virtualenv user, but before I became a virtualenvwrapper fan I used to create venvs in the project top-level directory (typically a Mercurial clone root), using ?virtualenv .?. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 19:00:57 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 24 Aug 2012 17:00:57 +0000 Subject: [issue15778] str(ImportError(b'foo')) fails In-Reply-To: <1345826325.41.0.0972765515738.issue15778@psf.upfronthosting.co.za> Message-ID: <1345827657.56.0.622486341608.issue15778@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 19:03:17 2012 From: report at bugs.python.org (Eric Snow) Date: Fri, 24 Aug 2012 17:03:17 +0000 Subject: [issue2051] PYO file permission problem In-Reply-To: <1202498912.62.0.957005802385.issue2051@psf.upfronthosting.co.za> Message-ID: <1345827797.5.0.815979361234.issue2051@psf.upfronthosting.co.za> Eric Snow added the comment: My patch was very similar. _cache_bytecode() is a good addition. Good point about the cache, too. I'm not convinced that source_path is the right thing to add to the API (even just for SourceFileLoader). I would have thought mode would have been more appropriate: def set_data(self, path, data, *, mode=0o666): Then the "mode = _os.stat(source_path).st_mode" bit would get moved to _cache_bytecode(). My reasoning is that set_data() is useful to write any data relative to the Loader. The concrete use case in the stdlib is for writing the .pyc files. Otherwise I'm not certain why the idea of "source_path" should be associated with set_data(). On the other hand, the idea of "mode" likewise may not be univeral enough to enshrine in the API, but I'd think it's more so than source_path. I was going to ask about backward compatability, but then I realized that SourceFileLoader is new in 3.3 (SourceLoader is new in 3.2). I'm also wondering why set_data() is not a part of the FileLoader API, but that's a question for another time (and version). :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 19:08:35 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 24 Aug 2012 17:08:35 +0000 Subject: [issue15778] str(ImportError(b'foo')) fails In-Reply-To: <1345826325.41.0.0972765515738.issue15778@psf.upfronthosting.co.za> Message-ID: <3X3TTs6ptXzQHf@mail.python.org> Roundup Robot added the comment: New changeset 91909962d7f5 by Brett Cannon in branch 'default': Issue #15778: Coerce ImportError.args to a string when it isn't http://hg.python.org/cpython/rev/91909962d7f5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 19:08:51 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 24 Aug 2012 17:08:51 +0000 Subject: [issue15778] str(ImportError(b'foo')) fails In-Reply-To: <1345826325.41.0.0972765515738.issue15778@psf.upfronthosting.co.za> Message-ID: <1345828131.59.0.917495286718.issue15778@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 19:23:21 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Fri, 24 Aug 2012 17:23:21 +0000 Subject: [issue9374] urlparse should parse query and fragment for arbitrary schemes In-Reply-To: <3X3SM42p0PzQKf@mail.python.org> Message-ID: Senthil Kumaran added the comment: Oops. I had not seen Eric and Mattiahs comment to this issue, which pointed out to the problem. Sorry for not acting on this. Thanks Georg for adding those module attributes back. On Fri, Aug 24, 2012 at 9:17 AM, Roundup Robot wrote: > > Roundup Robot added the comment: > > New changeset a0b3cb52816e by Georg Brandl in branch '3.2': > Closes #9374: add back now-unused module attributes; removing them is a backward compatibility issue, since they have a public-seeming name. > http://hg.python.org/cpython/rev/a0b3cb52816e > > New changeset c93fbc2caba5 by Georg Brandl in branch 'default': > Closes #9374: merge with 3.2 > http://hg.python.org/cpython/rev/c93fbc2caba5 > > New changeset a43481210964 by Georg Brandl in branch '2.7': > Closes #9374: add back now-unused module attributes; removing them is a backward compatibility issue, since they have a public-seeming name. > http://hg.python.org/cpython/rev/a43481210964 > > ---------- > resolution: remind -> fixed > status: open -> closed > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 19:29:43 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 24 Aug 2012 17:29:43 +0000 Subject: [issue14674] Link to & explain deviations from RFC 4627 in json module docs In-Reply-To: <1335449712.62.0.988063979534.issue14674@psf.upfronthosting.co.za> Message-ID: <1345829383.09.0.35167336997.issue14674@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Chris, I'm gonna take a look if nobody beats me to it. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 19:34:20 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 24 Aug 2012 17:34:20 +0000 Subject: [issue2051] PYO file permission problem In-Reply-To: <1202498912.62.0.957005802385.issue2051@psf.upfronthosting.co.za> Message-ID: <1345829660.66.0.356982579649.issue2051@psf.upfronthosting.co.za> Brett Cannon added the comment: I agree with Eric: set_data() is meant to be generic so as to allow writing arbitrary data, not just bytecode files. So while accepting a mode argument makes sense and I'm fine with in terms of possible API change (in the future), having a source_path argument I'm not comfortable with. So I'm going to just take Eric's idea and commit the change. I'm also making the argument _mode just to make sure no one relies on it until we can discuss API changes in the context of Python 3.4 sine we will need to clean up the loader APIs to have abstract source/bytecode stuff that can play nicely with file-based APIs to allow for reading generic file assets once we have all of these little bugs worked out. And as for why set_data() is not part of FileLoader, that's because it isn't necessary to load files. =) It's in SourceFileLoader purely to facilitate writing bytecode files, but set_data() is not used at all in terms of the actual loading of source code (or bytecode files for that matter). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 19:42:16 2012 From: report at bugs.python.org (James Hutchison) Date: Fri, 24 Aug 2012 17:42:16 +0000 Subject: [issue15779] socket error [Errno 10013] when creating SMTP object Message-ID: <1345830136.59.0.644251371515.issue15779@psf.upfronthosting.co.za> New submission from James Hutchison: Windows 7 64-bit, Python 3.2.3 This is a very odd issue and I haven't figured out what caused it. I have a python script that runs continuously. When it receives a request to do a task, it creates a new thread (not a new process), does the task, then sends out an e-mail to indicate it was done. It doesn't do this a lot (maybe 10 - 30 times a day). This is all the script does. Well today, it randomly broke. It was working fine, then suddenly I was getting the following error when it would create an SMTP object: socket.error: [Errno 10013] An attempt was made to access a socket in a way forbidden by its access permissions What I found was, even after trying a different script that did nothing but create a simple SMTP connection to localhost, running with admin privileges, and even after rebooting the machine, I was getting this error. I checked my firewall and didn't see any changes (I share a group policy so I do not have full control). I also tried the script on a different machine and found no issue. The issue also persisted between IDLE and simply running python.exe When I tried to debug the issue, I discovered the following piece of code made the issue go away: s = socket.socket() s.bind(('',50007)) s.listen(1); s.close(); And it hasn't come back since. I've tried to reproduce the circumstances that my script was running by creating SMTP instances in a loop but haven't been able to recreate the error. Checking my log, there isn't anything abnormal that occurred just before this issue (like attempting to do the task several times at once or something). ---------- components: Library (Lib) messages: 169055 nosy: Jimbofbx priority: normal severity: normal status: open title: socket error [Errno 10013] when creating SMTP object type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 19:48:47 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 24 Aug 2012 17:48:47 +0000 Subject: [issue2051] PYO file permission problem In-Reply-To: <1202498912.62.0.957005802385.issue2051@psf.upfronthosting.co.za> Message-ID: <3X3VNG0sc2zQBV@mail.python.org> Roundup Robot added the comment: New changeset 0c661c5632e0 by Brett Cannon in branch 'default': Issue #2051: Tweak last commit for this issue to pass in mode instead http://hg.python.org/cpython/rev/0c661c5632e0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 19:49:17 2012 From: report at bugs.python.org (Stefan Holek) Date: Fri, 24 Aug 2012 17:49:17 +0000 Subject: [issue15776] Allow pyvenv to work in existing directory In-Reply-To: <1345799746.88.0.728928529816.issue15776@psf.upfronthosting.co.za> Message-ID: <1345830557.37.0.073312492702.issue15776@psf.upfronthosting.co.za> Stefan Holek added the comment: Hm. What I am actually after is to "bless" an existing directory ? source files and all ? with a virtualenv (or pyvenv). I am not interested in the command deleting anything from anywhere, why thank you. Workflow: $ git clone git at github.com:stefanholek/foo $ cd foo $ virtualenv . $ ./bin/python setup.py develop $ ./bin/python setup.py -q test This is how I use virtualenv at the moment and I'd rather not lose that ability. Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 19:50:33 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 24 Aug 2012 17:50:33 +0000 Subject: [issue14674] Link to & explain deviations from RFC 4627 in json module docs In-Reply-To: <1335449712.62.0.988063979534.issue14674@psf.upfronthosting.co.za> Message-ID: <3X3VQJ5vfBzQJp@mail.python.org> Roundup Robot added the comment: New changeset 132886ef135d by Antoine Pitrou in branch '3.2': Issue #14674: Add a discussion of the json module's standard compliance. http://hg.python.org/cpython/rev/132886ef135d New changeset 16c0e26fc9cd by Antoine Pitrou in branch 'default': Issue #14674: Add a discussion of the json module's standard compliance. http://hg.python.org/cpython/rev/16c0e26fc9cd New changeset d413b36dbee5 by Antoine Pitrou in branch '2.7': Issue #14674: Add a discussion of the json module's standard compliance. http://hg.python.org/cpython/rev/d413b36dbee5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 19:53:25 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 24 Aug 2012 17:53:25 +0000 Subject: [issue15544] math.isnan fails with some Decimal NaNs In-Reply-To: <1343962443.78.0.878505736017.issue15544@psf.upfronthosting.co.za> Message-ID: <3X3VTc0fBCzQN9@mail.python.org> Roundup Robot added the comment: New changeset 49014c59b31f by Mark Dickinson in branch 'default': Issue #15544: Fix Decimal.__float__ to work with payload-carrying NaNs. http://hg.python.org/cpython/rev/49014c59b31f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 19:55:10 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 24 Aug 2012 17:55:10 +0000 Subject: [issue14674] Link to & explain deviations from RFC 4627 in json module docs In-Reply-To: <1335449712.62.0.988063979534.issue14674@psf.upfronthosting.co.za> Message-ID: <1345830910.22.0.0847963984853.issue14674@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, thank you Chris! ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 19:58:51 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 24 Aug 2012 17:58:51 +0000 Subject: [issue15779] socket error [Errno 10013] when creating SMTP object In-Reply-To: <1345830136.59.0.644251371515.issue15779@psf.upfronthosting.co.za> Message-ID: <1345831131.63.0.0212733292198.issue15779@psf.upfronthosting.co.za> Martin v. L?wis added the comment: As this is an error reported by Windows, it *very* unlikely is an issue with Python. Instead, it's a reaction that Windows produced to some sequence of events. My guess is that another process had the address in use, apparently, Windows then reports WSAEACCESS in certain cases instead of the expected WSAEADDRINUSE. What specific socket operation was the one that failed? ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 20:07:15 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Fri, 24 Aug 2012 18:07:15 +0000 Subject: [issue11225] getcwd fix for NetBSD to handle ERANGE errno In-Reply-To: <1297894688.76.0.163416819421.issue11225@psf.upfronthosting.co.za> Message-ID: <1345831635.57.0.93827197345.issue11225@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : ---------- resolution: -> duplicate status: open -> closed superseder: -> test_getcwd_long_pathnames (in test_posix) kills NetBSD _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 20:17:39 2012 From: report at bugs.python.org (Vinay Sajip) Date: Fri, 24 Aug 2012 18:17:39 +0000 Subject: [issue15776] Allow pyvenv to work in existing directory In-Reply-To: <1345799746.88.0.728928529816.issue15776@psf.upfronthosting.co.za> Message-ID: <1345832259.82.0.836267749916.issue15776@psf.upfronthosting.co.za> Vinay Sajip added the comment: > This is how I use virtualenv at the moment and I'd rather not lose that ability. Thanks. Well, changing it to do that means changing functionality, which is disallowed at this point in the release process. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 20:18:35 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 24 Aug 2012 18:18:35 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1317341390.65.0.255779328054.issue13072@psf.upfronthosting.co.za> Message-ID: <3X3W2f25frzQ0h@mail.python.org> Roundup Robot added the comment: New changeset 9c7515e29219 by Stefan Krah in branch 'default': Issue #13072: The array module's 'u' format code is now deprecated and http://hg.python.org/cpython/rev/9c7515e29219 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 20:20:34 2012 From: report at bugs.python.org (Vinay Sajip) Date: Fri, 24 Aug 2012 18:20:34 +0000 Subject: [issue15776] Allow pyvenv to work in existing directory In-Reply-To: <1345799746.88.0.728928529816.issue15776@psf.upfronthosting.co.za> Message-ID: <1345832434.33.0.690976415708.issue15776@psf.upfronthosting.co.za> Vinay Sajip added the comment: > I used to create venvs in the project top-level directory (typically a Mercurial clone root), using ?virtualenv .? I've used option 2 for this, using e.g. "virtualenv env" in the project directory. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 20:22:37 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 24 Aug 2012 18:22:37 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1317341390.65.0.255779328054.issue13072@psf.upfronthosting.co.za> Message-ID: <1345832557.88.0.624502108781.issue13072@psf.upfronthosting.co.za> Stefan Krah added the comment: Good, I think this can be closed then. ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 20:26:13 2012 From: report at bugs.python.org (Stefan Holek) Date: Fri, 24 Aug 2012 18:26:13 +0000 Subject: [issue15776] Allow pyvenv to work in existing directory In-Reply-To: <1345799746.88.0.728928529816.issue15776@psf.upfronthosting.co.za> Message-ID: <1345832773.07.0.548006967478.issue15776@psf.upfronthosting.co.za> Stefan Holek added the comment: Sorry for being late. I'll make a feature request for 3.4 then. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 20:40:52 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 24 Aug 2012 18:40:52 +0000 Subject: [issue15544] math.isnan fails with some Decimal NaNs In-Reply-To: <1343962443.78.0.878505736017.issue15544@psf.upfronthosting.co.za> Message-ID: <3X3WXM2l5jzQNV@mail.python.org> Roundup Robot added the comment: New changeset a931e44ffbe1 by Mark Dickinson in branch '3.2': Issue #15544: Fix Decimal.__float__ to work with payload-carrying NaNs. http://hg.python.org/cpython/rev/a931e44ffbe1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 20:47:07 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 24 Aug 2012 18:47:07 +0000 Subject: [issue15776] Allow pyvenv to work in existing directory In-Reply-To: <1345799746.88.0.728928529816.issue15776@psf.upfronthosting.co.za> Message-ID: <1345834027.05.0.0431802979866.issue15776@psf.upfronthosting.co.za> ?ric Araujo added the comment: > Well, changing it to do that means changing functionality, which is disallowed at this point in the release process. I think people used to ?virtualenv .? can see this as a regression between virtualenv and pyvenv, but if the PEP did not list that use case then it?s too late. I?d suggest we even back out the ?pyvenv --clear .? commit, which did not address the needs of the ?virtualenv .? users. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 20:53:49 2012 From: report at bugs.python.org (Vinay Sajip) Date: Fri, 24 Aug 2012 18:53:49 +0000 Subject: [issue15710] logging module crashes in Python 2.7.3 for handler.setLevel(long) In-Reply-To: <1345152839.48.0.661799461902.issue15710@psf.upfronthosting.co.za> Message-ID: <1345834429.15.0.961890546176.issue15710@psf.upfronthosting.co.za> Vinay Sajip added the comment: type(-2**31) is long for 2.5 and 2.6 as well as 2.7. The check was added as a response to #6314, to catch incorrect values being passed as levels. It could be argued that -2**31 is not a sensible log level. While int and long are supposed to be interchangeable for most purposes, isn't this a reasonable case where you shouldn't need to support long? If you feel not, what scenarios do you believe lie outside the "most purposes"? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 20:54:02 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 24 Aug 2012 18:54:02 +0000 Subject: [issue15776] Allow pyvenv to work in existing directory In-Reply-To: <1345834027.05.0.0431802979866.issue15776@psf.upfronthosting.co.za> Message-ID: <1345834240.3368.13.camel@localhost.localdomain> Antoine Pitrou added the comment: Le vendredi 24 ao?t 2012 ? 18:47 +0000, ?ric Araujo a ?crit : > ?ric Araujo added the comment: > > > Well, changing it to do that means changing functionality, which is > disallowed at this point in the release process. > I think people used to ?virtualenv .? can see this as a regression > between virtualenv and pyvenv, but if the PEP did not list that use > case then it?s too late. I?d suggest we even back out the ?pyvenv > --clear .? commit, which did not address the needs of the > ?virtualenv .? users. Agreed with Eric. The feature could be added correctly in 3.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 20:59:21 2012 From: report at bugs.python.org (Ned Deily) Date: Fri, 24 Aug 2012 18:59:21 +0000 Subject: [issue13370] test_ctypes fails when building python with clang In-Reply-To: <1320761474.93.0.268896325495.issue13370@psf.upfronthosting.co.za> Message-ID: <1345834761.36.0.217605248849.issue13370@psf.upfronthosting.co.za> Ned Deily added the comment: Sorry, I meant this part of the patch: diff --git a/Modules/_ctypes/libffi_osx/x86/x86-ffi_darwin.c b/Modules/_ctypes/libffi_osx/ --- a/Modules/_ctypes/libffi_osx/x86/x86-ffi_darwin.c +++ b/Modules/_ctypes/libffi_osx/x86/x86-ffi_darwin.c @@ -35,6 +35,8 @@ /* ffi_prep_args is called by the assembly routine once stack space has been allocated for the function's arguments */ +void ffi_prep_args(char *stack, extended_cif *ecif); + void ffi_prep_args(char *stack, extended_cif *ecif) { register unsigned int i; ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 21:06:51 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 24 Aug 2012 19:06:51 +0000 Subject: [issue15544] math.isnan fails with some Decimal NaNs In-Reply-To: <1343962443.78.0.878505736017.issue15544@psf.upfronthosting.co.za> Message-ID: <3X3X6K6hjhzQMM@mail.python.org> Roundup Robot added the comment: New changeset 5dd5f824428c by Mark Dickinson in branch '2.7': Issue #15544: Fix Decimal.__float__ to work with payload-carrying NaNs. http://hg.python.org/cpython/rev/5dd5f824428c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 21:09:21 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 24 Aug 2012 19:09:21 +0000 Subject: [issue15710] logging module crashes in Python 2.7.3 for handler.setLevel(long) In-Reply-To: <1345834429.15.0.961890546176.issue15710@psf.upfronthosting.co.za> Message-ID: <1345835159.3368.15.camel@localhost.localdomain> Antoine Pitrou added the comment: > type(-2**31) is long for 2.5 and 2.6 as well as 2.7. The check was > added as a response to #6314, to catch incorrect values being passed > as levels. Well, what is an incorrect value and why would you bother refusing long? And how about small long values (e.g. long(0))? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 21:12:10 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 24 Aug 2012 19:12:10 +0000 Subject: [issue15544] math.isnan fails with some Decimal NaNs In-Reply-To: <1343962443.78.0.878505736017.issue15544@psf.upfronthosting.co.za> Message-ID: <1345835530.27.0.0336116276197.issue15544@psf.upfronthosting.co.za> Mark Dickinson added the comment: Fixed. (I managed to mess up the commit to 3.2 and break all the buildbots :-(. I think it's okay now.) Thanks Steven for the report and patch! (And thanks Stefan for reviewing.) ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 21:14:09 2012 From: report at bugs.python.org (Vinay Sajip) Date: Fri, 24 Aug 2012 19:14:09 +0000 Subject: [issue15776] Allow pyvenv to work in existing directory In-Reply-To: <1345799746.88.0.728928529816.issue15776@psf.upfronthosting.co.za> Message-ID: <1345835649.19.0.430884232567.issue15776@psf.upfronthosting.co.za> Vinay Sajip added the comment: Reverted. ---------- assignee: -> vinay.sajip components: +Library (Lib) -None type: behavior -> enhancement versions: -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 21:26:39 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 24 Aug 2012 19:26:39 +0000 Subject: [issue14521] math.copysign(1., float('nan')) returns -1. In-Reply-To: <1333824186.8.0.672108286036.issue14521@psf.upfronthosting.co.za> Message-ID: <3X3XY96P1szQCb@mail.python.org> Roundup Robot added the comment: New changeset 31a7ff299698 by Mark Dickinson in branch '2.7': Remove overeager test (don't depend on the sign of a nan; cf. issue #14521) http://hg.python.org/cpython/rev/31a7ff299698 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 21:27:06 2012 From: report at bugs.python.org (Vinay Sajip) Date: Fri, 24 Aug 2012 19:27:06 +0000 Subject: [issue15710] logging module crashes in Python 2.7.3 for handler.setLevel(long) In-Reply-To: <1345152839.48.0.661799461902.issue15710@psf.upfronthosting.co.za> Message-ID: <1345836426.66.0.170126710807.issue15710@psf.upfronthosting.co.za> Vinay Sajip added the comment: It's not that big a deal, and doesn't matter for 3.x anyway. It just doesn't seem quite right, so I'll make the change soon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 21:32:44 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 24 Aug 2012 19:32:44 +0000 Subject: [issue14521] math.copysign(1., float('nan')) returns -1. In-Reply-To: <1333824186.8.0.672108286036.issue14521@psf.upfronthosting.co.za> Message-ID: <3X3XhC0W6jzQNW@mail.python.org> Roundup Robot added the comment: New changeset 121cb9596e7d by Mark Dickinson in branch '3.2': Remove overeager test (don't depend on the sign of a nan; cf. issue #14521) http://hg.python.org/cpython/rev/121cb9596e7d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 21:46:31 2012 From: report at bugs.python.org (James Hutchison) Date: Fri, 24 Aug 2012 19:46:31 +0000 Subject: [issue15779] socket error [Errno 10013] when creating SMTP object In-Reply-To: <1345830136.59.0.644251371515.issue15779@psf.upfronthosting.co.za> Message-ID: <1345837591.08.0.606623769694.issue15779@psf.upfronthosting.co.za> James Hutchison added the comment: This is the traceback I was getting where it was just a script that simply made an SMTP connection then closed it. This fails before it attempts to connect to the server. Traceback (most recent call last): File "C:\tmp\manysmtptest.py", line 8, in main(); File "C:\tmp\manysmtptest.py", line 4, in main a = SMTP(myserver); File "C:\Python32\lib\smtplib.py", line 259, in __init__ (code, msg) = self.connect(host, port) File "C:\Python32\lib\smtplib.py", line 319, in connect self.sock = self._get_socket(host, port, self.timeout) File "C:\Python32\lib\smtplib.py", line 294, in _get_socket return socket.create_connection((host, port), timeout) File "C:\Python32\lib\socket.py", line 404, in create_connection raise err File "C:\Python32\lib\socket.py", line 395, in create_connection sock.connect(sa) socket.error: [Errno 10013] An attempt was made to access a socket in a way forbidden by its access permissions What I don't get is why rebooting didn't fix the problem. You'd think Python or Windows issue, things would resolve themselves after a reboot. All the other programs I was using seemed to work fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 22:18:07 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 24 Aug 2012 20:18:07 +0000 Subject: [issue15779] socket error [Errno 10013] when creating SMTP object In-Reply-To: <1345830136.59.0.644251371515.issue15779@psf.upfronthosting.co.za> Message-ID: <1345839487.45.0.360681766445.issue15779@psf.upfronthosting.co.za> Martin v. L?wis added the comment: It's very easy to see why it survives a reboot. If there is a collision with some other process, that process restarts, recreating the collision. Things may depend on timing, so it may happen on some reboots and not on others (e.g. if the colliding process has picked some other port). Closing this as "works for me". ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 22:36:17 2012 From: report at bugs.python.org (James Hutchison) Date: Fri, 24 Aug 2012 20:36:17 +0000 Subject: [issue15779] socket error [Errno 10013] when creating SMTP object In-Reply-To: <1345830136.59.0.644251371515.issue15779@psf.upfronthosting.co.za> Message-ID: <1345840577.19.0.266880110172.issue15779@psf.upfronthosting.co.za> James Hutchison added the comment: That makes no sense. Why does: s = socket.socket() s.bind(('',50007)) s.listen(1); s.close(); fix the issue then? Re-opening, this issue should be understood because having such an operation randomly fail is unacceptable for a production system. How does python choose a port to open a connection on? If windows reports the wrong error then shouldn't python try a different port number anyways (considering I have no control over what port Python chooses to open a connection on)? ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 22:44:45 2012 From: report at bugs.python.org (James Hutchison) Date: Fri, 24 Aug 2012 20:44:45 +0000 Subject: [issue15780] IDLE (windows) with PYTHONPATH and multiple python versions Message-ID: <1345841085.37.0.939660475067.issue15780@psf.upfronthosting.co.za> New submission from James Hutchison: One issue I've encountered is someone else's software setting PYTHONPATH to their install directory of python. We have some old software that installs and uses python 2.3 scripts and unfortunately this prevents the IDLE shortcuts for newer versions of python from working correctly on the system. This could be remedied with -E being added to the shortcut, but windows doesn't allow me to directly edit the IDLE shortcut, and it hides how IDLE is being launched via Python in the first place, making it a challenge to create my own. I'd remove PYTHONPATH from the system environment variables except I don't know why it's set in the first place. Suggestion: IDLE safe-mode which runs with -E OR include a batch file for IDLE so that I can easily append my own command line arguments and create my own shortcuts. ---------- components: IDLE messages: 169082 nosy: Jimbofbx priority: normal severity: normal status: open title: IDLE (windows) with PYTHONPATH and multiple python versions type: enhancement versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 22:51:33 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 24 Aug 2012 20:51:33 +0000 Subject: [issue15780] IDLE (windows) with PYTHONPATH and multiple python versions In-Reply-To: <1345841085.37.0.939660475067.issue15780@psf.upfronthosting.co.za> Message-ID: <1345841493.63.0.22171160842.issue15780@psf.upfronthosting.co.za> R. David Murray added the comment: I'm guessing that 'batch file' version of this request is answered by the new 'py' launcher command in Python3, which can also be used with other versions of Python. The obscurity of configuring things on Windows isn't directly a Python problem, but perhaps there are docs we could add somewhere? ---------- nosy: +r.david.murray, terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 23:03:20 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 24 Aug 2012 21:03:20 +0000 Subject: [issue15779] socket error [Errno 10013] when creating SMTP object In-Reply-To: <1345830136.59.0.644251371515.issue15779@psf.upfronthosting.co.za> Message-ID: <1345842200.93.0.42828547715.issue15779@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > s.bind(('',50007)) How did you find out 50007? Is it just a random number you chose? ---------- nosy: +brian.curtin, pitrou, tim.golden _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 23:05:36 2012 From: report at bugs.python.org (Georg Brandl) Date: Fri, 24 Aug 2012 21:05:36 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1345842336.81.0.136590522339.issue15573@psf.upfronthosting.co.za> Georg Brandl added the comment: I'm not very keen to hold up the release for long times again, especially for a patch of this size and lots of potential breakage. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 23:06:07 2012 From: report at bugs.python.org (James Hutchison) Date: Fri, 24 Aug 2012 21:06:07 +0000 Subject: [issue15779] socket error [Errno 10013] when creating SMTP object In-Reply-To: <1345830136.59.0.644251371515.issue15779@psf.upfronthosting.co.za> Message-ID: <1345842367.68.0.506483147408.issue15779@psf.upfronthosting.co.za> James Hutchison added the comment: It's from the example. http://docs.python.org/library/socket.html#example ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 23:09:25 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 24 Aug 2012 21:09:25 +0000 Subject: [issue15779] socket error [Errno 10013] when creating SMTP object In-Reply-To: <1345830136.59.0.644251371515.issue15779@psf.upfronthosting.co.za> Message-ID: <1345842565.9.0.922834506343.issue15779@psf.upfronthosting.co.za> Antoine Pitrou added the comment: According to the MSDN doc for connect(): WSAEACCES: An attempt to connect a datagram socket to broadcast address failed because setsockopt option SO_BROADCAST is not enabled. However, this implies that `getaddrinfo(host, port, 0, SOCK_STREAM)` (in socket.create_connection) returned parameters for a datagram socket... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 23:13:35 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 24 Aug 2012 21:13:35 +0000 Subject: [issue15779] socket error [Errno 10013] when creating SMTP object In-Reply-To: <1345830136.59.0.644251371515.issue15779@psf.upfronthosting.co.za> Message-ID: <1345842815.06.0.15043194449.issue15779@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Oh, a random Google search brought the following comment from the chromium source code (it seems): ?connect fails with WSAEACCES when Windows Firewall blocks the connection?. This sounds like a likelier explanation than the previous one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 23:15:59 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 24 Aug 2012 21:15:59 +0000 Subject: [issue13370] test_ctypes fails when building python with clang In-Reply-To: <1320761474.93.0.268896325495.issue13370@psf.upfronthosting.co.za> Message-ID: <1345842959.64.0.729640308587.issue13370@psf.upfronthosting.co.za> Ronald Oussoren added the comment: That's not code duplication, but a way to silence a compiler warning. I added it while trying to get pyobjc to compile without any warnings. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 23:17:40 2012 From: report at bugs.python.org (Zachary Ware) Date: Fri, 24 Aug 2012 21:17:40 +0000 Subject: [issue15136] Decimal accepting Fraction In-Reply-To: <1340365912.14.0.935631231431.issue15136@psf.upfronthosting.co.za> Message-ID: <1345843060.06.0.644730903819.issue15136@psf.upfronthosting.co.za> Zachary Ware added the comment: (Mark:) >To the patch: It looks fine, as far as it goes. It needs tests. I remembered tests about 5 minutes after I submitted the initial patch :P. Here's a patch with some tests. Note that I've never really done tests, so please let me know if there need to be more/less/different tests. >To avoid the repetition of the division code, I'd suggest doing something like: > > if context is None: > context = getcontext() (Stefan:) >If this goes in, I'd prefer that as_decimal() always uses a localcontext(). >As the patch stands, using as_decimal() pollutes the global context flags, >which can be quite unexpected My first attempt was simply: def as_decimal(self, context=None): with localcontext(context): return Decimal(self.numerator) / Decimal(self.denominator) Looking through decimal.py, it looks like that should work (and in fact it does in 3.2.3), but it seems that _decimal will only accept a context as the argument to localcontext(), not None. Is that expected, or does that need an issue? I didn't catch that the patch pollutes the global context flags, that is indeed ugly and unacceptable. >If the function takes a context argument, it might be better to move it >into the decimal module as Decimal.from_fraction(context). Perhaps both? Implement Decimal.from_fraction(f, context) to do the real work, and then Fraction.to_decimal() as: def to_decimal(self): return Decimal.from_fraction(self, None) Those who really care about the context (Decimal users working with a Fraction) can get what they want, and those who don't (Fraction users who want to see a Decimal representation) don't have to bother, and fractions.py isn't polluted with stuff about contexts. ---------- Added file: http://bugs.python.org/file26989/issue15136_with_tests.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 23:35:06 2012 From: report at bugs.python.org (James Hutchison) Date: Fri, 24 Aug 2012 21:35:06 +0000 Subject: [issue15779] socket error [Errno 10013] when creating SMTP object In-Reply-To: <1345830136.59.0.644251371515.issue15779@psf.upfronthosting.co.za> Message-ID: <1345844106.42.0.452448758273.issue15779@psf.upfronthosting.co.za> James Hutchison added the comment: The firewall is disabled for my machine. So the options are: 1. Port was in-use: possible except that is normally a different error 2. Port was firewalled: firewall was disabled 3. Port mis-use: not likely because this wouldn't be random 4. Port was in restricted port range for some reason: admin privileges did not resolve #1 seems the most plausible so far ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 23:42:41 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 24 Aug 2012 21:42:41 +0000 Subject: [issue15779] socket error [Errno 10013] when creating SMTP object In-Reply-To: <1345830136.59.0.644251371515.issue15779@psf.upfronthosting.co.za> Message-ID: <1345844561.73.0.999944316024.issue15779@psf.upfronthosting.co.za> Antoine Pitrou added the comment: By the way, please check the return value of getaddrinfo() for your SMTP server: >>> socket.getaddrinfo("www.gmail.com", 25, 0, socket.SOCK_STREAM) [(2, 1, 6, '', ('74.125.230.213', 25)), (2, 1, 6, '', ('74.125.230.214', 25)), (10, 1, 6, '', ('2a00:1450:4007:802::1016', 25, 0, 0))] and then try to connect() to each of the addresses. If one of the addresses gives WSAEACCES when connecting, you've got the explanation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 23:44:57 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 24 Aug 2012 21:44:57 +0000 Subject: [issue15316] runpy swallows ImportError information with relative imports In-Reply-To: <1341898758.4.0.623810416258.issue15316@psf.upfronthosting.co.za> Message-ID: <1345844697.15.0.749589022199.issue15316@psf.upfronthosting.co.za> Brett Cannon added the comment: I am running the test suite now using the "secret" attribute on ImportError. I tried to pass a flag, but locking became a bit messy/complicated. And I also realized that if I didn't do this then using different implementation of import_ in importlib wouldn't work because I would be hard-coding in what import implementation was used which would bypass the accelerated code in import.c. Plus with the compatibility issues I have had in the passed, I didn't want to skip a step of import that someone was probably relying on. Once Python 3.4 comes out I will create a new exception that is raised when no module is found and catch that class specifically to avoid this hack. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 23:49:12 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 24 Aug 2012 21:49:12 +0000 Subject: [issue13370] test_ctypes fails when building python with clang In-Reply-To: <1320761474.93.0.268896325495.issue13370@psf.upfronthosting.co.za> Message-ID: <1345844952.71.0.746178056352.issue13370@psf.upfronthosting.co.za> Ronald Oussoren added the comment: I noticed earlier today that test_ctypes passes for Python 3.3 both with and without my patch. This is on OSX 10.8.1 with an up-to-date Xcode. Configure arguments: '--enable-framework' '--with-pydebug' '--enable-universalsdk=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk' '--with-universal-archs=intel' '--with-framework-name=PythonDev' 'MACOSX_DEPLOYMENT_TARGET=10.8' 'CC=clang' 'CXX=clang++' That's why I haven't commited the patch yet. I'm installing Xcode in a OSX 10.7 VM to check if the patch is necessary on that platform. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 24 23:55:41 2012 From: report at bugs.python.org (James Hutchison) Date: Fri, 24 Aug 2012 21:55:41 +0000 Subject: [issue15779] socket error [Errno 10013] when creating SMTP object In-Reply-To: <1345830136.59.0.644251371515.issue15779@psf.upfronthosting.co.za> Message-ID: <1345845341.0.0.427204585192.issue15779@psf.upfronthosting.co.za> James Hutchison added the comment: I can connect to all of the IPs for my server without issue. Found this: Another possible reason for the WSAEACCES error is that when the bind function is called (on Windows NT 4.0 with SP4 and later), another application, service, or kernel mode driver is bound to the same address with exclusive access. Such exclusive access is a new feature of Windows NT 4.0 with SP4 and later, and is implemented by using the SO_EXCLUSIVEADDRUSE option. So that explains why you may see either WSAEADDRINUSE or WSAEACCESS So at this point, I think the question is - how does python choose an outgoing port? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 00:26:06 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 24 Aug 2012 22:26:06 +0000 Subject: [issue15316] runpy swallows ImportError information with relative imports In-Reply-To: <1341898758.4.0.623810416258.issue15316@psf.upfronthosting.co.za> Message-ID: <3X3cXF2kW6zQ3j@mail.python.org> Roundup Robot added the comment: New changeset ca4bf8e10bc0 by Brett Cannon in branch 'default': Issue #15316: Let exceptions raised during imports triggered by the http://hg.python.org/cpython/rev/ca4bf8e10bc0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 00:27:06 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 24 Aug 2012 22:27:06 +0000 Subject: [issue15316] runpy swallows ImportError information with relative imports In-Reply-To: <1341898758.4.0.623810416258.issue15316@psf.upfronthosting.co.za> Message-ID: <1345847226.09.0.632219321683.issue15316@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> fixed stage: test needed -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 01:12:16 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 24 Aug 2012 23:12:16 +0000 Subject: [issue14649] doctest.DocTestSuite error misleading when module has no docstrings In-Reply-To: <1335192861.9.0.305748973415.issue14649@psf.upfronthosting.co.za> Message-ID: <1345849936.15.0.412610204606.issue14649@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Here is an updated patch for review (just for the default branch for now). The main change from the previous patch is that the ValueError exception is now documented. A few additional comments/questions: Is there a better way to signify in the documentation that certain behavior is an unfixable bug as opposed to desired behavior? Would that be appropriate here? I created a new folder inside Lib/test for supporting test files specific to doctest. In addition to the two new files this patch adds, I would also like to move the eight existing support files into this new directory: doctest_aliases.py test_doctest.txt test_doctest3.txt sample_doctest.py test_doctest2.py test_doctest4.txt test_doctest.py test_doctest2.txt Can that be done as a separate change after the patch for this issue, or should it be done before? Assuming people are okay with keeping this ValueError behavior the same in the maintenance releases (i.e. not handling this as a bug fix), would people be open to changing the behavior in future versions, or should we keep the behavior the same in future versions as well? ---------- Added file: http://bugs.python.org/file26990/issue-14649-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 01:29:08 2012 From: report at bugs.python.org (Ned Deily) Date: Fri, 24 Aug 2012 23:29:08 +0000 Subject: [issue13370] test_ctypes fails when building python with clang In-Reply-To: <1320761474.93.0.268896325495.issue13370@psf.upfronthosting.co.za> Message-ID: <1345850948.05.0.78412507067.issue13370@psf.upfronthosting.co.za> Ned Deily added the comment: Bah, I just noticed that you built --with-pydebug enabled. That hides the problem. I was fooled myself there. But I've since verified that the failure still exists when built on 10.7 with Xcode 4.4.1 so the patch should go in. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 01:39:32 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 24 Aug 2012 23:39:32 +0000 Subject: [issue15779] socket error [Errno 10013] when creating SMTP object In-Reply-To: <1345830136.59.0.644251371515.issue15779@psf.upfronthosting.co.za> Message-ID: <1345851572.84.0.0675431096148.issue15779@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The Python API maps nearly 1:1 to the winsock API. So the Python code literally translates to the equivalent C code (with *very* minor deviations e.g. involving the conversion of string addresses in numeric addresses). Please leave the issue closed unless you can provide substantial evidence that there is a bug in Python. I disagree that the issue needs to be understood. This is only an acceptable request if you can provide a reproducible test cases, which you (currently) cannot. Anybody wanting to understand the issue might need physical access to your system, which is not feasible. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 01:48:56 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 24 Aug 2012 23:48:56 +0000 Subject: [issue14649] doctest.DocTestSuite error misleading when module has no docstrings In-Reply-To: <1335192861.9.0.305748973415.issue14649@psf.upfronthosting.co.za> Message-ID: <1345852136.78.0.622424361645.issue14649@psf.upfronthosting.co.za> Changes by Chris Jerdonek : Added file: http://bugs.python.org/file26991/issue-14649-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 01:51:56 2012 From: report at bugs.python.org (Mark Grandi) Date: Fri, 24 Aug 2012 23:51:56 +0000 Subject: [issue14455] plistlib unable to read json and binary plist files In-Reply-To: <1333144578.81.0.343123708942.issue14455@psf.upfronthosting.co.za> Message-ID: <1345852316.86.0.278023835564.issue14455@psf.upfronthosting.co.za> Mark Grandi added the comment: are any more changes needed to the code that is already posted as a patch in this bug report? or are the changes you wanted to see happen in msg157669 not happen yet? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 01:58:42 2012 From: report at bugs.python.org (James Hutchison) Date: Fri, 24 Aug 2012 23:58:42 +0000 Subject: [issue15779] socket error [Errno 10013] when creating SMTP object In-Reply-To: <1345830136.59.0.644251371515.issue15779@psf.upfronthosting.co.za> Message-ID: <1345852722.44.0.0316793203623.issue15779@psf.upfronthosting.co.za> Changes by James Hutchison : ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 01:59:58 2012 From: report at bugs.python.org (Brian Curtin) Date: Fri, 24 Aug 2012 23:59:58 +0000 Subject: [issue15779] socket error [Errno 10013] when creating SMTP object In-Reply-To: <1345830136.59.0.644251371515.issue15779@psf.upfronthosting.co.za> Message-ID: <1345852798.45.0.245077548812.issue15779@psf.upfronthosting.co.za> Changes by Brian Curtin : ---------- nosy: -brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 02:12:51 2012 From: report at bugs.python.org (James Hutchison) Date: Sat, 25 Aug 2012 00:12:51 +0000 Subject: [issue15779] socket error [Errno 10013] when creating SMTP object In-Reply-To: <1345830136.59.0.644251371515.issue15779@psf.upfronthosting.co.za> Message-ID: <1345853571.85.0.794955631798.issue15779@psf.upfronthosting.co.za> James Hutchison added the comment: Looks to me like python grabs an outgoing port number via unrandom means and if it happens to map to a port taken by a service that demands exclusive access, then it returns the WSAEACCESS error instead of WSAEADDRINUSE. Because this is a fairly new "feature" in windows (NT 4.0 w/ SP3), Python does not properly account for it by simply trying another port like it would if it got WSAEADDRINUSE Arguably this would affect all aspects of Python that uses sockets. The function in question seems to be: getaddrinfo(host, port, 0, SOCK_STREAM) Which, if I'm understanding the code correctly, returns the source address used to make the connection in this instance. Unfortunately, that function is in a compiled binary so I don't know how it works. If windows is responsible for giving the bad port number, I would argue that Python still needs to account for the problem since this is obviously a major issue if it happens to someone. The fact that you mentioned that the cause is the fact WSAEADDRINUSE isn't the error, then that seems to imply Python is doing the selection. If python is using a windows library to get outgoing port, it is also possible that maybe that library is outdated and it needs to use a newer one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 02:21:44 2012 From: report at bugs.python.org (James Hutchison) Date: Sat, 25 Aug 2012 00:21:44 +0000 Subject: [issue15779] socket error [Errno 10013] when creating SMTP object In-Reply-To: <1345830136.59.0.644251371515.issue15779@psf.upfronthosting.co.za> Message-ID: <1345854104.42.0.89673900377.issue15779@psf.upfronthosting.co.za> Changes by James Hutchison : ---------- components: +Windows _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 02:22:39 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 25 Aug 2012 00:22:39 +0000 Subject: [issue15779] socket error [Errno 10013] when creating SMTP object In-Reply-To: <1345830136.59.0.644251371515.issue15779@psf.upfronthosting.co.za> Message-ID: <1345854159.08.0.82526605625.issue15779@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Looks to me like python grabs an outgoing port number via unrandom means Python does not grab an outgoing port number, its lets the OS choose one (via connect()). The only thing to watch out for would be whether you let many connections open (perhaps there's a per-process limit that is reached). > Which, if I'm understanding the code correctly, returns the source > address used to make the connection in this instance. getaddrinfo() does not do that. It is simply a wrapper around the C runtime library's getaddrinfo(), for which you can find information on the Web (for both the Windows and POSIX versions of it). > If windows is responsible for giving the bad port number, I would argue > that Python still needs to account for the problem since this is obviously > a major issue if it happens to someone. It might be a major issue for whoever encounters the issue but, as Martin said, Python cannot do anything else than bubble up the exception for you to handle. Since this seems to be a fairly involved Windows issue (rather than a Python bug), I suggest you ask for help on a help forum with Windows experts. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 02:54:59 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 25 Aug 2012 00:54:59 +0000 Subject: [issue14649] doctest.DocTestSuite error misleading when module has no docstrings In-Reply-To: <1335192861.9.0.305748973415.issue14649@psf.upfronthosting.co.za> Message-ID: <1345856099.31.0.469527722962.issue14649@psf.upfronthosting.co.za> R. David Murray added the comment: Personally I prefer to have the test case create the file(s) used in the test dynamically, writing them to the temporary working directory. Since these are Python modules, you could use the helpers from script_helpers for this. Otherwise I think your patch is OK. I don't think we have a doc convention for "unfortunate implementation detail" :( We have in the past put notes in the doc that say "this may change in the future", though that is usually about desired enhancements. But perhaps it could apply here as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 03:21:06 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 25 Aug 2012 01:21:06 +0000 Subject: [issue634412] RFC 2387 in email package Message-ID: <1345857666.34.0.076556287261.issue634412@psf.upfronthosting.co.za> R. David Murray added the comment: http://tools.ietf.org/html/rfc2387 has obsoleted 2112. ---------- title: RFC 2112 in email package -> RFC 2387 in email package versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 04:01:00 2012 From: report at bugs.python.org (Chris Rebert) Date: Sat, 25 Aug 2012 02:01:00 +0000 Subject: [issue15731] Mechanism for inheriting docstrings and signatures In-Reply-To: <1345437452.28.0.514901819881.issue15731@psf.upfronthosting.co.za> Message-ID: <1345860060.35.0.501946441844.issue15731@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 06:50:26 2012 From: report at bugs.python.org (Ross Lagerwall) Date: Sat, 25 Aug 2012 04:50:26 +0000 Subject: [issue15777] test_capi refleak In-Reply-To: <1345803195.05.0.615891441008.issue15777@psf.upfronthosting.co.za> Message-ID: <1345870226.43.0.768940693805.issue15777@psf.upfronthosting.co.za> Changes by Ross Lagerwall : ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 09:09:45 2012 From: report at bugs.python.org (STINNER Victor) Date: Sat, 25 Aug 2012 07:09:45 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1345842336.81.0.136590522339.issue15573@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Even if I would prefer to see a fully working new implementation of the buffer interface, I agree with Georg: it's too late for such huge change in Python 3.3. Can' we wait Python 3.4 to change the equality operator? It also took me three major releases to fix all Unicode issues (and it's probably not finished :-)). Le 24 ao?t 2012 23:05, "Georg Brandl" a ?crit : > > Georg Brandl added the comment: > > I'm not very keen to hold up the release for long times again, especially > for a patch of this size and lots of potential breakage. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 09:29:28 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 25 Aug 2012 07:29:28 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1345879768.53.0.213581010812.issue15573@psf.upfronthosting.co.za> Stefan Krah added the comment: The effect of the change is pretty minimal though: Previously "not equal" was returned for unknown formats, now the struct module figures it out. memoryobject.c has 100% coverage except for a couple of lines that are either impossible to reach or very hard to reach. The new code is among the most heavily exercised lines, since in test_buffer.py the verify() function always asserts equality. You can look at the attached memoryobject.c.gcov: *All* failure paths are taken since Python API functions are wrapped in macros that set PyExc_FailAPIError and return failure at predefined points the test suite. ---------- Added file: http://bugs.python.org/file26992/memoryobject.c.gcov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 09:39:42 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Aug 2012 07:39:42 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1345880382.7.0.105532052289.issue15573@psf.upfronthosting.co.za> Nick Coghlan added the comment: With Stefan's major improvements to the test suite for 3.3, the risk is low and I *really* don't want to spend the life of the 3.3 series excusing the current comparison behaviour. By contrast, explaining the shift in definition as moving from raw memory comparisons to by value comparisons is relatively easy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 09:41:50 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 25 Aug 2012 07:41:50 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1345880510.12.0.541488550037.issue15573@psf.upfronthosting.co.za> Georg Brandl added the comment: Well, I'm not against you committing it as long as you commit it *right now*. I'm about to cut the tag. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 09:44:15 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 25 Aug 2012 07:44:15 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1345879768.53.0.213581010812.issue15573@psf.upfronthosting.co.za> Message-ID: <20120825074416.GA17685@sleipnir.bytereef.org> Stefan Krah added the comment: > You can look at the attached memoryobject.c.gcov: *All* failure paths > are taken since Python API functions are wrapped in macros that > set PyExc_FailAPIError and return failure at predefined points > the test suite. That should read: With a patch that wraps Python API functions ... Obviously the macros aren't in by default. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 09:45:39 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 25 Aug 2012 07:45:39 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1345880510.12.0.541488550037.issue15573@psf.upfronthosting.co.za> Message-ID: <20120825074540.GB17685@sleipnir.bytereef.org> Stefan Krah added the comment: Great, give me 20 minutes or so. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 09:47:22 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Aug 2012 07:47:22 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1345880842.51.0.979445210246.issue15573@psf.upfronthosting.co.za> Nick Coghlan added the comment: I'm currently on IRC and double checking the patch locally. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 09:49:18 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Aug 2012 07:49:18 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1345880958.13.0.289065343532.issue15573@psf.upfronthosting.co.za> Nick Coghlan added the comment: Stefan, was there something specific you wanted to do before committing? Otherwise I can commit it as soon as this full test run finishes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 09:52:33 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Aug 2012 07:52:33 +0000 Subject: [issue7475] codecs missing: base64 bz2 hex zlib hex_codec ... In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za> Message-ID: <1345881153.14.0.484578671157.issue7475@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- priority: release blocker -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 09:56:30 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 25 Aug 2012 07:56:30 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1345881390.14.0.271521654354.issue15573@psf.upfronthosting.co.za> Stefan Krah added the comment: Except for Misc/NEWS the patch can be committed unchanged. Please go ahead! [The remaining doc changes are tracked elsewhere.] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 10:00:02 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 25 Aug 2012 08:00:02 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <3X3sGS6rYCzQPC@mail.python.org> Roundup Robot added the comment: New changeset afa3dedfee18 by Nick Coghlan in branch 'default': Close #15573: use value-based memoryview comparisons (patch by Stefan Krah) http://hg.python.org/cpython/rev/afa3dedfee18 ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 10:33:40 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 25 Aug 2012 08:33:40 +0000 Subject: [issue15781] test_threaded_import fails on Windows Message-ID: <1345883620.41.0.296577026972.issue15781@psf.upfronthosting.co.za> New submission from Stefan Krah: test_parallel_module_init() fails on Windows-64: http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/553/steps/test/logs/stdio ====================================================================== FAIL: test_parallel_module_init (test.test_threaded_import.ThreadedImportTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_threaded_import.py", line 125, in test_parallel_module_init self.check_parallel_module_init() File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_threaded_import.py", line 120, in check_parallel_module_init self.assertFalse(errors) AssertionError: [AttributeError("'module' object has no attribute 'randrange'",)] is not false ---------------------------------------------------------------------- ---------- components: Tests messages: 169116 nosy: brett.cannon, haypo, jkloth, pitrou, skrah priority: normal severity: normal status: open title: test_threaded_import fails on Windows type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 10:35:43 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Sat, 25 Aug 2012 08:35:43 +0000 Subject: [issue13370] test_ctypes fails when building python with clang In-Reply-To: <1320761474.93.0.268896325495.issue13370@psf.upfronthosting.co.za> Message-ID: <1345883743.22.0.721385729588.issue13370@psf.upfronthosting.co.za> Ronald Oussoren added the comment: Duh... 3.3 without patch fails when I leave out '--with-pydebug'. I'm now running the testsuite for 2.7 and 3.2 with patch and will commit once those are ready, which should be within an hour from now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 10:49:05 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Sat, 25 Aug 2012 08:49:05 +0000 Subject: [issue15756] subprocess.poll() does not handle errno.ECHILD "No child processes" In-Reply-To: <1345576517.75.0.906463701582.issue15756@psf.upfronthosting.co.za> Message-ID: <1345884545.32.0.266442583809.issue15756@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 10:53:34 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Aug 2012 08:53:34 +0000 Subject: [issue15781] test_threaded_import fails on Windows In-Reply-To: <1345883620.41.0.296577026972.issue15781@psf.upfronthosting.co.za> Message-ID: <1345884814.88.0.365957935291.issue15781@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 11:07:59 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 25 Aug 2012 09:07:59 +0000 Subject: [issue15781] test_threaded_import fails with -j4 In-Reply-To: <1345883620.41.0.296577026972.issue15781@psf.upfronthosting.co.za> Message-ID: <1345885679.56.0.291776968294.issue15781@psf.upfronthosting.co.za> Stefan Krah added the comment: The buildbot in question uses -j4, and I can reproduce this on Linux with: ./python -m test -uall -F -j4 -v test_threaded_import ====================================================================== FAIL: test_parallel_meta_path (test.test_threaded_import.ThreadedImportTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/stefan/hg/cpython/Lib/test/test_threaded_import.py", line 131, in test_parallel_meta_path self.check_parallel_module_init() File "/home/stefan/hg/cpython/Lib/test/test_threaded_import.py", line 120, in check_parallel_module_init self.assertFalse(errors) AssertionError: [AttributeError("'module' object has no attribute 'randrange'",), AttributeError("'module' object has no attribute 'randrange'",)] is not false ---------------------------------------------------------------------- Ran 6 tests in 4.221s ---------- title: test_threaded_import fails on Windows -> test_threaded_import fails with -j4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 11:11:09 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 25 Aug 2012 09:11:09 +0000 Subject: =?utf-8?q?=5Bissue13518=5D_configparser_can=E2=80=99t_read_file_objects_f?= =?utf-8?q?rom_urlopen?= In-Reply-To: <1322782976.1.0.275624635723.issue13518@psf.upfronthosting.co.za> Message-ID: <1345885869.79.0.251133308038.issue13518@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 11:21:01 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 25 Aug 2012 09:21:01 +0000 Subject: [issue15765] test_getcwd_long_pathnames (in test_posix) kills NetBSD In-Reply-To: <1345644735.97.0.561553846154.issue15765@psf.upfronthosting.co.za> Message-ID: <1345886461.0.0.12926605343.issue15765@psf.upfronthosting.co.za> Stefan Krah added the comment: I completely forgot about that issue. The patch looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 11:24:32 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 25 Aug 2012 09:24:32 +0000 Subject: [issue13370] test_ctypes fails when building python with clang In-Reply-To: <1320761474.93.0.268896325495.issue13370@psf.upfronthosting.co.za> Message-ID: <3X3v7z3C5kzQKH@mail.python.org> Roundup Robot added the comment: New changeset 58a87c02692c by Ronald Oussoren in branch '2.7': Fix issue 13370: Ensure that ctypes works on Mac OS X when Python is compiled using the clang compiler http://hg.python.org/cpython/rev/58a87c02692c New changeset a425f2697273 by Ronald Oussoren in branch '3.2': Fix issue 13370: Ensure that ctypes works on Mac OS X when Python is compiled using the clang compiler http://hg.python.org/cpython/rev/a425f2697273 New changeset bed8dd30309d by Ronald Oussoren in branch 'default': Fix issue 13370: Ensure that ctypes works on Mac OS X when Python is http://hg.python.org/cpython/rev/bed8dd30309d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 11:25:50 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Sat, 25 Aug 2012 09:25:50 +0000 Subject: [issue13370] test_ctypes fails when building python with clang In-Reply-To: <1320761474.93.0.268896325495.issue13370@psf.upfronthosting.co.za> Message-ID: <1345886750.11.0.165475766746.issue13370@psf.upfronthosting.co.za> Ronald Oussoren added the comment: The issue should be gone in the upcoming 3.3rc1 release and the next stable releases of 3.2 and 2.7. ---------- resolution: -> fixed status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 12:01:06 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 25 Aug 2012 10:01:06 +0000 Subject: [issue15781] test_threaded_import fails with -j4 In-Reply-To: <1345883620.41.0.296577026972.issue15781@psf.upfronthosting.co.za> Message-ID: <1345888866.35.0.495476635788.issue15781@psf.upfronthosting.co.za> Antoine Pitrou added the comment: With $ ./python -m test -uall -F -j16 -v test_threaded_import I couldn't reproduce after 1000 test passes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 12:05:30 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Sat, 25 Aug 2012 10:05:30 +0000 Subject: [issue15782] Compile error for a number of Mac modules with recent Xcode Message-ID: <1345889130.68.0.165099119682.issue15782@psf.upfronthosting.co.za> New submission from Ronald Oussoren: Recent versions of Xcode on OSX 10.7 and 10.8 fail to compile 3 of the extension modules in Mac/Modules: the modules for fm, qd and qdoffs. That's because those extensions wrap APIs that are long deprecated and are no longer present. The attached patch "fixes" the miscompilation by making most of the body of the extension empty when compiling with the 10.7 (or later) SDK. This changes the API of these extension modules, but that cannot be helped because the platform APIs that are wrapped by these extensions are no longer present. (Patch is not relevant for python 3.x because these extensions have been removed in python 3.0) ---------- assignee: ronaldoussoren components: Build, Macintosh files: miscompile-mac-modules.txt keywords: needs review messages: 169123 nosy: ned.deily, ronaldoussoren priority: normal severity: normal stage: patch review status: open title: Compile error for a number of Mac modules with recent Xcode type: compile error versions: Python 2.7 Added file: http://bugs.python.org/file26993/miscompile-mac-modules.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 12:22:44 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Aug 2012 10:22:44 +0000 Subject: [issue15781] test_threaded_import fails with -j4 In-Reply-To: <1345883620.41.0.296577026972.issue15781@psf.upfronthosting.co.za> Message-ID: <1345890164.89.0.363676566387.issue15781@psf.upfronthosting.co.za> Nick Coghlan added the comment: No joy here either - currently at 704 successful runs and counting with Stefan's command line. $ uname -a Linux lancre 3.5.1-1.fc17.x86_64 #1 SMP Thu Aug 9 17:50:43 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux $ cat /proc/cpuinfo | grep "model name" model name : Intel(R) Core(TM) i7-2677M CPU @ 1.80GHz model name : Intel(R) Core(TM) i7-2677M CPU @ 1.80GHz model name : Intel(R) Core(TM) i7-2677M CPU @ 1.80GHz model name : Intel(R) Core(TM) i7-2677M CPU @ 1.80GHz ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 12:23:19 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 25 Aug 2012 10:23:19 +0000 Subject: [issue12834] memoryview.to_bytes() and PyBuffer_ToContiguous() incorrect for non-contiguous arrays In-Reply-To: <1314211505.01.0.756597830367.issue12834@psf.upfronthosting.co.za> Message-ID: <1345890199.45.0.77592651044.issue12834@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The last bugfix release of 3.2 will happen "shortly" after the release of 3.3, so in a not-too-far future (compared to the age of this issue, which just had its first birthday yesterday). So if this issue should really block 3.2 (which I still think it should not), I'd urge possible contributors to start working on it now - especially if this is going to be a large patch. If such patch introduces new bugs, it won't be possible to ever fix them (unless they are security-critical). Also note that this is almost the only release blocker for the 3.2 release, next to a easy-to-implement request to update the expat code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 12:29:14 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Aug 2012 10:29:14 +0000 Subject: [issue12834] memoryview.to_bytes() and PyBuffer_ToContiguous() incorrect for non-contiguous arrays In-Reply-To: <1314211505.01.0.756597830367.issue12834@psf.upfronthosting.co.za> Message-ID: <1345890554.75.0.667170274486.issue12834@psf.upfronthosting.co.za> Nick Coghlan added the comment: Despite my earlier comments, I'm now inclined to agree with Martin here - upgrading to 3.3 fixes so many other problems with memoryview, that's a more compelling solution. And, of course, using NumPy instead always remains an option for more robust buffer API support in older versions. ---------- priority: release blocker -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 12:30:04 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Aug 2012 10:30:04 +0000 Subject: [issue12834] memoryview.to_bytes() and PyBuffer_ToContiguous() incorrect for non-contiguous arrays In-Reply-To: <1314211505.01.0.756597830367.issue12834@psf.upfronthosting.co.za> Message-ID: <1345890604.6.0.672659997756.issue12834@psf.upfronthosting.co.za> Nick Coghlan added the comment: (Not saying this shouldn't be fixed, just saying it's not a disaster if it isn't) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 12:38:17 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 25 Aug 2012 10:38:17 +0000 Subject: [issue12834] memoryview.to_bytes() and PyBuffer_ToContiguous() incorrect for non-contiguous arrays In-Reply-To: <1314211505.01.0.756597830367.issue12834@psf.upfronthosting.co.za> Message-ID: <1345891097.0.0.555082092815.issue12834@psf.upfronthosting.co.za> Stefan Krah added the comment: I agree that for 3.2 this isn't so important given that non-contiguous arrays have multiple issues there. Christian, does a fix for 3.2 benefit FreeImage? Don't you run into other problems with memoryview? If it helps, I can try to write a patch for 3.2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 12:51:12 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 25 Aug 2012 10:51:12 +0000 Subject: [issue15781] test_threaded_import fails with -j4 In-Reply-To: <1345883620.41.0.296577026972.issue15781@psf.upfronthosting.co.za> Message-ID: <1345891872.52.0.571205407736.issue15781@psf.upfronthosting.co.za> Stefan Krah added the comment: I can only reproduce this on a Core i7. Native OS is Debian Wheezy, also reproduced earlier on a FreeBSD VM hosted on that machine (see msg167989). The machine has 4 physical cores, perhaps we can blame hyper-threading. ;) $ cat /proc/cpuinfo | grep "model name" model name : Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz model name : Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz model name : Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz model name : Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz model name : Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz model name : Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz model name : Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz model name : Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz I can't reproduce it on a Core 2 Duo running Ubuntu natively. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 13:20:22 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Sat, 25 Aug 2012 11:20:22 +0000 Subject: [issue15776] Allow pyvenv to work in existing directory In-Reply-To: <1345799746.88.0.728928529816.issue15776@psf.upfronthosting.co.za> Message-ID: <1345893622.41.0.498516087885.issue15776@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- priority: release blocker -> critical stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 13:22:22 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 25 Aug 2012 11:22:22 +0000 Subject: [issue15776] Allow pyvenv to work in existing directory In-Reply-To: <1345799746.88.0.728928529816.issue15776@psf.upfronthosting.co.za> Message-ID: <3X3xlx3235zQQw@mail.python.org> Roundup Robot added the comment: New changeset b200acb6bed4 by Andrew Svetlov in branch 'default': Delete Misc/NEWS record for reverted #15776. http://hg.python.org/cpython/rev/b200acb6bed4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 14:32:21 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 25 Aug 2012 12:32:21 +0000 Subject: [issue15724] Add "versionchanged" to memoryview docs In-Reply-To: <1345377223.09.0.176185074566.issue15724@psf.upfronthosting.co.za> Message-ID: <1345897941.64.0.819201243097.issue15724@psf.upfronthosting.co.za> Stefan Krah added the comment: This was less work than expected. I suppose docs can always go in even after rc1 is out, so I'll wait for that. ---------- keywords: +patch Added file: http://bugs.python.org/file26994/issue15724.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 14:55:40 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Aug 2012 12:55:40 +0000 Subject: [issue15781] test_threaded_import fails with -j4 In-Reply-To: <1345883620.41.0.296577026972.issue15781@psf.upfronthosting.co.za> Message-ID: <1345899340.16.0.621292255868.issue15781@psf.upfronthosting.co.za> Nick Coghlan added the comment: Up to 2279 runs without a failure here - yay for elusive hardware specific threading bugs :P I'll leave it running overnight and see what happens. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 15:17:14 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 25 Aug 2012 13:17:14 +0000 Subject: [issue15781] test_threaded_import fails with -j4 In-Reply-To: <1345883620.41.0.296577026972.issue15781@psf.upfronthosting.co.za> Message-ID: <1345900634.24.0.207106697691.issue15781@psf.upfronthosting.co.za> Stefan Krah added the comment: I can also reproduce it on the Core 2 machine with a ridiculuously low switch interval: diff --git a/Lib/test/regrtest.py b/Lib/test/regrtest.py --- a/Lib/test/regrtest.py +++ b/Lib/test/regrtest.py @@ -198,6 +198,8 @@ except ImportError: multiprocessing = None +sys.setswitchinterval(0.00000001) + # Some times __path__ and __file__ are not absolute (e.g. while running from # Lib/) and, if we change the CWD to run the tests in a temporary dir, some ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 15:19:50 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 25 Aug 2012 13:19:50 +0000 Subject: [issue15781] test_threaded_import fails with -j4 In-Reply-To: <1345883620.41.0.296577026972.issue15781@psf.upfronthosting.co.za> Message-ID: <1345900790.15.0.951091784322.issue15781@psf.upfronthosting.co.za> Stefan Krah added the comment: Oh, and as usual, my machines have all CPUs at 100% load. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 16:24:43 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Aug 2012 14:24:43 +0000 Subject: [issue15783] decimal.localcontext(None) fails when using the C accelerator module Message-ID: <1345904683.65.0.863127291798.issue15783@psf.upfronthosting.co.za> New submission from Nick Coghlan: decimal.localcontext() works correctly with both the pure Python decimal module and the C accelerator. decimal.localcontext(None) only works with the pure Python version. The C accelerator throws an exception instead of treating it as equivalent to omitting the argument. ---------- keywords: 3.3regression messages: 169135 nosy: ncoghlan, skrah priority: normal severity: normal stage: test needed status: open title: decimal.localcontext(None) fails when using the C accelerator module type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 16:27:58 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Aug 2012 14:27:58 +0000 Subject: [issue15783] decimal.localcontext(None) fails when using the C accelerator module In-Reply-To: <1345904683.65.0.863127291798.issue15783@psf.upfronthosting.co.za> Message-ID: <1345904878.76.0.948373169556.issue15783@psf.upfronthosting.co.za> Nick Coghlan added the comment: Georg, a regression in the decimal API relative to 3.2 got picked up by #15136. Are you OK with cherrypicking a fix for this into rc2? ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 16:33:43 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Aug 2012 14:33:43 +0000 Subject: [issue15136] Decimal accepting Fraction In-Reply-To: <1340365912.14.0.935631231431.issue15136@psf.upfronthosting.co.za> Message-ID: <1345905223.11.0.280630122197.issue15136@psf.upfronthosting.co.za> Nick Coghlan added the comment: There is indeed a regression in decimal.localcontext with the C accelerator: omitting the argument entirely still works, but passing None explicitly now fails. I created #15783 for that. On the topic of this thread, I'm also -1 on conversion methods, but +1 on string formatting support. There's an obvious benefit in providing the latter in order to get a better "feel" for the value of a rational number by displaying a Decimal approximation, but questionable benefit in providing the former. Explicit conversion is sufficiently rare that I'm OK with the idea of either going via a string (as used to be necessary for binary floats) or by explicitly casting the numerator to Decimal, then dividing by the denominator (no need to cast them both). ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 16:44:10 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 25 Aug 2012 14:44:10 +0000 Subject: [issue15783] decimal.localcontext(None) fails when using the C accelerator module In-Reply-To: <1345904683.65.0.863127291798.issue15783@psf.upfronthosting.co.za> Message-ID: <20120825144411.GA9531@sleipnir.bytereef.org> Stefan Krah added the comment: The feature is undocumented though. Is it a regression? There are other places as well. The topic was raised in msg153447 and msg153506, with no further comments. So I concluded that None argument support wasn't important. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 17:01:10 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Aug 2012 15:01:10 +0000 Subject: [issue15783] decimal.localcontext(None) fails when using the C accelerator module In-Reply-To: <1345904683.65.0.863127291798.issue15783@psf.upfronthosting.co.za> Message-ID: <1345906870.97.0.227338932494.issue15783@psf.upfronthosting.co.za> Nick Coghlan added the comment: While it's undocumented in the main docs [1], help(decimal.localcontext) in 3.2 starts with: localcontext(ctx=None) Return a context manager for a copy of the supplied context We essentially have two votes in favour of "it should work" (the pure Python impl and the docstring), and two in favour of "meh" (the prose docs and the lack of a test case) I think we should fix it, but I don't mind if Georg wants it to wait until 3.3.1 [1] http://docs.python.org/py3k/library/decimal#decimal.localcontext ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 17:04:17 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 25 Aug 2012 15:04:17 +0000 Subject: [issue15783] decimal.localcontext(None) fails when using the C accelerator module In-Reply-To: <1345904683.65.0.863127291798.issue15783@psf.upfronthosting.co.za> Message-ID: <1345907057.21.0.50289806125.issue15783@psf.upfronthosting.co.za> Ezio Melotti added the comment: Can't this be fixed in the CONTEXT_CHECK_VA macro? With the attached patch decimal.localcontext(None) works and there aren't any failures, however I don't think there are tests that pass None explicitly, so this approach might not work. ---------- keywords: +patch nosy: +ezio.melotti Added file: http://bugs.python.org/file26995/issue15783.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 17:14:56 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 25 Aug 2012 15:14:56 +0000 Subject: [issue10650] decimal.py: quantize(): excess digits with watchexp=0 In-Reply-To: <1291816575.32.0.784106881295.issue10650@psf.upfronthosting.co.za> Message-ID: <1345907696.81.0.245034198689.issue10650@psf.upfronthosting.co.za> Stefan Krah added the comment: Here's a patch deprecating watchexp. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 17:15:34 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 25 Aug 2012 15:15:34 +0000 Subject: [issue10650] decimal.py: quantize(): excess digits with watchexp=0 In-Reply-To: <1291816575.32.0.784106881295.issue10650@psf.upfronthosting.co.za> Message-ID: <1345907734.28.0.943277766174.issue10650@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- keywords: +patch Added file: http://bugs.python.org/file26996/issue10650.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 17:56:38 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 25 Aug 2012 15:56:38 +0000 Subject: [issue15783] decimal.localcontext(None) fails when using the C accelerator module In-Reply-To: <1345906870.97.0.227338932494.issue15783@psf.upfronthosting.co.za> Message-ID: <20120825155638.GA9765@sleipnir.bytereef.org> Stefan Krah added the comment: OK, but for example: Help on function __truediv__ in module decimal: __truediv__(self, other, context=None) Return self / other. Here I think it's undisputed that a C version should not cram a context argument into a number method. There are many functions in decimal where some arguments are just implementation details, or worse, leftovers (see #10650). So I simply don't know if localcontext(None) was intended or (once) an implementation detail. localcontext(None) by itself looks kind of awkward to me. The only valid use case I can see is indeed the one from #15136. I don't particularly mind either way for localcontext(), but in more speed sensitive areas I would care. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 18:10:03 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 25 Aug 2012 16:10:03 +0000 Subject: [issue15783] decimal.localcontext(None) fails when using the C accelerator module In-Reply-To: <1345907057.21.0.50289806125.issue15783@psf.upfronthosting.co.za> Message-ID: <20120825161004.GA9946@sleipnir.bytereef.org> Stefan Krah added the comment: > Can't this be fixed in the CONTEXT_CHECK_VA macro? No, the macro should only allow contexts. E.g. in the case of localcontext(None) context_copy(local, NULL) would be called on local=Py_None, which is undefined. What would perhaps be needed for a nice C-API is a function like PyArg_ParseTupleSkipNone() that treats None arguments in the same way as optional args that are not given. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 18:30:07 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 25 Aug 2012 16:30:07 +0000 Subject: [issue15783] decimal.localcontext(None) fails when using the C accelerator module In-Reply-To: <1345904683.65.0.863127291798.issue15783@psf.upfronthosting.co.za> Message-ID: <1345912207.49.0.861875265926.issue15783@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 19:25:07 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 25 Aug 2012 17:25:07 +0000 Subject: [issue15783] decimal.localcontext(None) fails when using the C accelerator module In-Reply-To: <1345904683.65.0.863127291798.issue15783@psf.upfronthosting.co.za> Message-ID: <1345915507.82.0.73631328778.issue15783@psf.upfronthosting.co.za> Stefan Krah added the comment: This is the complete list of context=None divergences. It would be possible to change that, since most of the functions are generated by macro wrappers. # This is the only place where 'ctx' is used localcontext(ctx=None) canonical(self, context=None) compare(self, other, context=None) compare_signal(self, other, context=None) exp(self, context=None) fma(self, other, third, context=None) is_normal(self, context=None) is_subnormal(self, context=None) ln(self, context=None) log10(self, context=None) logb(self, context=None) logical_and(self, other, context=None) logical_invert(self, context=None) logical_or(self, other, context=None) logical_xor(self, other, context=None) max(self, other, context=None) max_mag(self, other, context=None) min(self, other, context=None) min_mag(self, other, context=None) next_minus(self, context=None) next_plus(self, context=None) normalize(self, context=None) number_class(self, context=None) quantize(self, exp, rounding=None, context=None, watchexp=True) remainder_near(self, other, context=None) rotate(self, other, context=None) scaleb(self, other, context=None) shift(self, other, context=None) sqrt(self, context=None) to_eng_string(self, context=None) to_integral(self, rounding=None, context=None) to_integral_value(self, rounding=None, context=None) to_integral_exact(self, rounding=None, context=None) context.power(self, a, b, modulo=None) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 19:30:49 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 25 Aug 2012 17:30:49 +0000 Subject: [issue15783] decimal.localcontext(None) fails when using the C accelerator module In-Reply-To: <1345904683.65.0.863127291798.issue15783@psf.upfronthosting.co.za> Message-ID: <1345915849.28.0.795940579853.issue15783@psf.upfronthosting.co.za> Mark Dickinson added the comment: This doesn't strike me as something it's essential to resolve before 3.3.1. And I agree that decimal.localcontext(None) looks peculiar. I noticed this yesterday when looking at #15136 and dismissed it as an artifact of the implementation---I didn't think to check what the docs said. I think it's a bit unfortunate that the docs specify "ctx=None". I doubt that too much thought went into that; without knowing the history, I suspect that at the time it was just a way to indicate that the context was an optional argument. IOW, my vote would be not to require that None is accepted, and to treat this as an minor error in the documentation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 19:31:57 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 25 Aug 2012 17:31:57 +0000 Subject: [issue15783] decimal.localcontext(None) fails when using the C accelerator module In-Reply-To: <1345904683.65.0.863127291798.issue15783@psf.upfronthosting.co.za> Message-ID: <1345915917.03.0.0376229806729.issue15783@psf.upfronthosting.co.za> Mark Dickinson added the comment: Adding Raymond to the nosy, since he may know more about what was intended. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 19:54:55 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 25 Aug 2012 17:54:55 +0000 Subject: [issue14649] doctest.DocTestSuite error misleading when module has no docstrings In-Reply-To: <1335192861.9.0.305748973415.issue14649@psf.upfronthosting.co.za> Message-ID: <1345917295.37.0.59000621262.issue14649@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > Personally I prefer to have the test case create the file(s) used in the test dynamically, writing them to the temporary working directory. I prefer that too, but when I approached this issue, I found that test_doctest doesn't use unittest. It uses only doctest tests to test itself, and it uses checked-in files to test things like DocTestSuite and DocFileSuite. For example, test_DocFileSuite has this: >>> suite = doctest.DocFileSuite('test_doctest.txt', ... 'test_doctest2.txt', ... 'test_doctest4.txt') (Hence the eight supporting files I mentioned in my previous comment, of which these are three.) Should I break the current way of doing things for this module and introduce unittest and the first dynamically created files? > We have in the past put notes in the doc that say "this may change in the future", though that is usually about desired enhancements. That's interesting. It's like a "Will change in version ..." counterpart to "Changed in version ...." Come to think of it, that could be a useful practice in general because it would let people future-proof their code more easily and give them incentives to upgrade. To simplify things for the purposes of this issue, we can discuss adding such wording to earlier versions only if and when we actually change the future behavior. I can create a separate issue to discuss changing future behavior once this issue is complete. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 20:24:20 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 25 Aug 2012 18:24:20 +0000 Subject: [issue15136] Decimal accepting Fraction In-Reply-To: <1340365912.14.0.935631231431.issue15136@psf.upfronthosting.co.za> Message-ID: <1345919060.66.0.49012796807.issue15136@psf.upfronthosting.co.za> Terry J. Reedy added the comment: After reading the comments, I am ambivalent about a conversion function, and given the lack of consensus or even a clear majority, -1. (Which implies a change in issue title.) I am +1 on using the new .format() machinery to have fractions format themselves. (Unless Python already does so for other purposes, it should do so without importing decimal.) The uploaded function passes the included test cases. I guess the rounding should be whatever we do for floats. I fudged that in the example. ---------- Added file: http://bugs.python.org/file26997/fracdec.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 20:27:59 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Sat, 25 Aug 2012 18:27:59 +0000 Subject: [issue15222] mailbox.mbox writes without empty line after each message In-Reply-To: <1340948825.65.0.977158180544.issue15222@psf.upfronthosting.co.za> Message-ID: <1345919279.67.0.665936308929.issue15222@psf.upfronthosting.co.za> Petri Lehtinen added the comment: Attaching two patches. Patch 1 changes the common message template in mailbox tests to end in a newline. If this wasn't done, more or less all common mailbox tests would have to be special cased for mbox. Patch 2 adds a single blank line after each message in mbox. A single blank line is added if the added message doesn't end in a newline or ends in a single newline. When read back, a single newline is added to the end o the message if it wasn't there (and this is the reason why patch 1 is needed). ---------- keywords: +patch Added file: http://bugs.python.org/file26998/issue15222_v1_0001_end_test_msg_template_in_newline.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 20:28:24 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Sat, 25 Aug 2012 18:28:24 +0000 Subject: [issue15222] mailbox.mbox writes without empty line after each message In-Reply-To: <1340948825.65.0.977158180544.issue15222@psf.upfronthosting.co.za> Message-ID: <1345919304.87.0.226602805565.issue15222@psf.upfronthosting.co.za> Changes by Petri Lehtinen : ---------- keywords: +needs review stage: -> patch review Added file: http://bugs.python.org/file26999/issue15222_v1_0002_insert_blank_after_each_message_in_mbox.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 20:31:50 2012 From: report at bugs.python.org (Eric Snow) Date: Sat, 25 Aug 2012 18:31:50 +0000 Subject: [issue15781] test_threaded_import fails with -j4 In-Reply-To: <1345883620.41.0.296577026972.issue15781@psf.upfronthosting.co.za> Message-ID: <1345919510.8.0.928394071568.issue15781@psf.upfronthosting.co.za> Eric Snow added the comment: So this was a random one-off (hardly even intermittent) failed test that passed on the retry. Ah, threads. Is there an easy way to find all other failures in test_threaded_import in the past, for this and for all buildbots? Do we have information about load during tests? Is there an easy way to run the test suite under load on a build bot? With a large enough sample size we can make more sense of this. For instance, do failures predate the addition of per-module import locks or the importlib migration in 3.3? Are failures limited to particular platforms? Is the problem load related? BTW, test_threaded_import had another (different) failure a week ago on FreeBSD: issue15599. ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 20:34:09 2012 From: report at bugs.python.org (Eric Snow) Date: Sat, 25 Aug 2012 18:34:09 +0000 Subject: [issue15781] test_threaded_import fails with -j4 In-Reply-To: <1345883620.41.0.296577026972.issue15781@psf.upfronthosting.co.za> Message-ID: <1345919649.8.0.916122578794.issue15781@psf.upfronthosting.co.za> Eric Snow added the comment: (sorry, only saw the first couple messages) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 20:37:31 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 25 Aug 2012 18:37:31 +0000 Subject: [issue14649] doctest.DocTestSuite error misleading when module has no docstrings In-Reply-To: <1335192861.9.0.305748973415.issue14649@psf.upfronthosting.co.za> Message-ID: <1345919851.88.0.669465300668.issue14649@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Small tweak to a code comment in the patch (`tests` is not itself a unittest.TestSuite instance). ---------- Added file: http://bugs.python.org/file27000/issue-14649-4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 20:44:37 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Sat, 25 Aug 2012 18:44:37 +0000 Subject: [issue15784] OSError.__str__() should distinguish between errno and winerror Message-ID: <1345920277.5.0.279969365859.issue15784@psf.upfronthosting.co.za> New submission from Richard Oudkerk: Since WindowsError became an alias of OSError, the error number shown in the stringification of an OSError err can either be a windows error code (err.winerror) or a posix style error number (err.errno), with no way to tell which. For instance in >>> os.read(999, 0) Traceback (most recent call last): File "", line 1, in OSError: [Errno 9] Bad file descriptor err.errno == EBADF == 9 and err.winerror == None, but in >>> _winapi.ReadFile(999, 0) Traceback (most recent call last): File "", line 1, in OSError: [Error 6] The handle is invalid err.errno == EBADF == 9 and err.winerror == ERROR_INVALID_HANDLE == 6. (winerror gets priority over errno if it exists.) With the attached patch the second will be shown as >>> _winapi.ReadFile(999, 0) Traceback (most recent call last): File "", line 1, in OSError: [WinError 6] The handle is invalid ^^^ Since this issue only applies to 3.3 and the patch is trivial, it would be nice to get this in before 3.3 is released. ---------- files: winerror.patch keywords: patch messages: 169153 nosy: pitrou, sbt priority: normal severity: normal status: open title: OSError.__str__() should distinguish between errno and winerror Added file: http://bugs.python.org/file27001/winerror.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 21:06:26 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Sat, 25 Aug 2012 19:06:26 +0000 Subject: [issue15784] OSError.__str__() should distinguish between errno and winerror In-Reply-To: <1345920277.5.0.279969365859.issue15784@psf.upfronthosting.co.za> Message-ID: <1345921586.14.0.439482187331.issue15784@psf.upfronthosting.co.za> Changes by Richard Oudkerk : Added file: http://bugs.python.org/file27002/winerror.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 25 21:06:30 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Sat, 25 Aug 2012 19:06:30 +0000 Subject: [issue15784] OSError.__str__() should distinguish between errno and winerror In-Reply-To: <1345920277.5.0.279969365859.issue15784@psf.upfronthosting.co.za> Message-ID: <1345921590.87.0.911073354891.issue15784@psf.upfronthosting.co.za> Changes by Richard Oudkerk : Removed file: http://bugs.python.org/file27001/winerror.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 26 00:02:08 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 25 Aug 2012 22:02:08 +0000 Subject: [issue15781] test_threaded_import fails with -j4 In-Reply-To: <1345883620.41.0.296577026972.issue15781@psf.upfronthosting.co.za> Message-ID: <1345932128.66.0.766236843943.issue15781@psf.upfronthosting.co.za> Stefan Krah added the comment: On the i7 machine with hyper-threading the issue occurs since edb9ce3a6c2e. The tests also got slower: 3430d7329a3b: $ time ./python -m test -uall -v test_threaded_import real 0m3.195s user 0m0.656s sys 0m0.284s edb9ce3a6c2e: $ time ./python -m test -uall -v test_threaded_import real 0m24.032s user 0m0.880s sys 0m0.744s Here most of the time is spent in test_parallel_meta_path. DISCLAIMER: This machine runs Debian Wheezy, which is not stable yet! On the other hand the Windows bot also reproduced the issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 26 04:31:53 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 26 Aug 2012 02:31:53 +0000 Subject: [issue15720] move __import__() out of the default lookup chain In-Reply-To: <1345261089.07.0.0712105087978.issue15720@psf.upfronthosting.co.za> Message-ID: <1345948313.85.0.976807806734.issue15720@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 26 04:32:32 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 26 Aug 2012 02:32:32 +0000 Subject: [issue15753] No-argument super in method with variable arguments raises SystemError In-Reply-To: <1345549960.82.0.102703520127.issue15753@psf.upfronthosting.co.za> Message-ID: <1345948352.75.0.190428207487.issue15753@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 26 04:33:33 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 26 Aug 2012 02:33:33 +0000 Subject: [issue15749] cgitb prints html for text when display disabled. In-Reply-To: <1345523795.76.0.397222969623.issue15749@psf.upfronthosting.co.za> Message-ID: <1345948413.64.0.833961834725.issue15749@psf.upfronthosting.co.za> ?ric Araujo added the comment: Thanks for the report and patch. Is this a duplicate of #12890? ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 26 06:01:54 2012 From: report at bugs.python.org (Mike Hoy) Date: Sun, 26 Aug 2012 04:01:54 +0000 Subject: [issue11776] Constructor signatures missing in types module documentation In-Reply-To: <1302036805.33.0.506634428921.issue11776@psf.upfronthosting.co.za> Message-ID: <1345953714.2.0.446558429612.issue11776@psf.upfronthosting.co.za> Mike Hoy added the comment: I've added a completed patch for review. There was some talk on IRC that the wording for MappingProxyType should be changed to: "Return a read-only view of the given mapping." We decided to leave it to the review process to determine the exact wording. ---------- Added file: http://bugs.python.org/file27003/signatures-full-patch.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 26 06:03:41 2012 From: report at bugs.python.org (aliles) Date: Sun, 26 Aug 2012 04:03:41 +0000 Subject: [issue15749] cgitb prints html for text when display disabled. In-Reply-To: <1345523795.76.0.397222969623.issue15749@psf.upfronthosting.co.za> Message-ID: <1345953821.87.0.496304917983.issue15749@psf.upfronthosting.co.za> aliles added the comment: Not an exact duplicate, although I should have seen that issue. Oops. The 'display' and 'logdir' arguments are independent. Although I do appear to have gone a little overboard and fixed 12890 issue as well. Should I wait for that fix to be merged then reissue the patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 26 06:04:07 2012 From: report at bugs.python.org (Mike Hoy) Date: Sun, 26 Aug 2012 04:04:07 +0000 Subject: [issue11776] Constructor signatures missing in types module documentation In-Reply-To: <1302036805.33.0.506634428921.issue11776@psf.upfronthosting.co.za> Message-ID: <1345953847.45.0.244905052385.issue11776@psf.upfronthosting.co.za> Mike Hoy added the comment: Ezio Melotti was the one that offered to change the wording on MappingProxyType doc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 26 06:24:48 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 26 Aug 2012 04:24:48 +0000 Subject: [issue11776] Constructor signatures missing in types module documentation In-Reply-To: <1302036805.33.0.506634428921.issue11776@psf.upfronthosting.co.za> Message-ID: <1345955087.82.0.650139607387.issue11776@psf.upfronthosting.co.za> Ezio Melotti added the comment: > We decided to leave it to the review process to determine the exact wording. The problem with the current wording is that it explain how to use it (in case it's used to create a new mapping proxy), but doesn't say much about the object itself (in case it's used for isinstance/issubclass checks). This consideration can also be applied to the rest of the patch. Currently the types are documented as if they were only useful for isinstance/issuclass checks and the arguments are omitted from the doc. Given that this is the main use case IMHO, it makes sense having a lightweight list of types with a short description of what they are. OTOH these types can also be used to create new objects, so for this use case the arguments should be listed and documented. I'm not sure if these two use cases should be kept separate or not though. One possible way to do this is to have a table, followed by the full doc with arguments and explanation. The table will also be useful as an index to jump to the full doc, and as a quick overview of the available types. Something like: The following table summarizes the types defined in the types module. Typical use is of these names is for isinstance() or issubclass() checks. ----------- ------------------------------------------------ Type Name Type of ----------- ------------------------------------------------ MethodType methods of user-defined instances CodeType code objects such as returned by :func:`compile` ... ... ----------- ------------------------------------------------ These types can also be used to create new objects: .. class:: MethodType(function, instance) Create a bound instance method object. .. class:: CodeType(argcount, kwonlyargcount, nlocals, stacksize, flags, codestring, constants, names, varnames, filename, name, firstlineno, lnotab) Create a code object. Not for the faint of heart. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 26 06:25:57 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 26 Aug 2012 04:25:57 +0000 Subject: [issue15510] textwrap.wrap('') returns empty list In-Reply-To: <1343697979.41.0.629576632811.issue15510@psf.upfronthosting.co.za> Message-ID: <1345955155.39.0.16598788252.issue15510@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Here is a patch that documents and adds tests for the existing behavior (i.e. keeping the current behavior the same). I also expanded the patch slightly to cover related edge cases that involve the interplay between whitespace, empty lines, and indenting (some of which came out of the discussions above). ---------- keywords: +needs review type: behavior -> enhancement Added file: http://bugs.python.org/file27004/issue-15510-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 26 06:45:56 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 26 Aug 2012 04:45:56 +0000 Subject: [issue12890] cgitb displays

tags when executed in text mode In-Reply-To: <1315016521.13.0.175763253408.issue12890@psf.upfronthosting.co.za> Message-ID: <1345956356.64.0.151447612829.issue12890@psf.upfronthosting.co.za> Ezio Melotti added the comment: What about closing the

too (see attached patch)? (I know the

is not necessary, but I prefer to add it.) ---------- Added file: http://bugs.python.org/file27005/issue12890.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 26 07:54:10 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 26 Aug 2012 05:54:10 +0000 Subject: [issue15767] add ModuleNotFoundError In-Reply-To: <1345664718.23.0.712313947558.issue15767@psf.upfronthosting.co.za> Message-ID: <1345960450.45.0.982030765519.issue15767@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 26 08:55:59 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 26 Aug 2012 06:55:59 +0000 Subject: [issue13801] The Python 3 Docs don't highlight nonlocal In-Reply-To: <1326720484.97.0.730349515473.issue13801@psf.upfronthosting.co.za> Message-ID: <1345964159.79.0.998005576722.issue13801@psf.upfronthosting.co.za> Ezio Melotti added the comment: Sphinx is configured to use Python3Lexer (highlight_language is set to 'python3' in Doc/conf.py). 'nonlocal' is not highlighted because in the pygments version that we are using 'nonlocal' is missing in Python3Lexer.tokens['keywords'] see (Doc/tools/pygments/lexers/agile.py:196). If this is fixed in more recent pygments versions, we only have to update our version. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 26 10:12:55 2012 From: report at bugs.python.org (Berker Peksag) Date: Sun, 26 Aug 2012 08:12:55 +0000 Subject: [issue13801] The Python 3 Docs don't highlight nonlocal In-Reply-To: <1326720484.97.0.730349515473.issue13801@psf.upfronthosting.co.za> Message-ID: <1345968775.16.0.465663905499.issue13801@psf.upfronthosting.co.za> Berker Peksag added the comment: > 'nonlocal' is not highlighted because in the pygments version that we are using 'nonlocal' is missing in Python3Lexer.tokens['keywords'] see (Doc/tools/pygments/lexers/agile.py:196). The nonlocal keyword has been added in Pygments 1.5. https://bitbucket.org/birkenfeld/pygments-main/src/972a251fa742/pygments/lexers/agile.py#cl-202 ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 26 12:07:06 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 26 Aug 2012 10:07:06 +0000 Subject: [issue13801] The Python 3 Docs don't highlight nonlocal In-Reply-To: <1326720484.97.0.730349515473.issue13801@psf.upfronthosting.co.za> Message-ID: <1345975626.97.0.897960142126.issue13801@psf.upfronthosting.co.za> Ezio Melotti added the comment: Our version is 1.3.1. Georg said that this can be update after the 3.3 release. ---------- versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 26 12:09:39 2012 From: report at bugs.python.org (Adam Simpkins) Date: Sun, 26 Aug 2012 10:09:39 +0000 Subject: [issue15785] curses.get_wch() returns keypad codes incorrectly Message-ID: <1345975778.97.0.705241878581.issue15785@psf.upfronthosting.co.za> New submission from Adam Simpkins: The curses.get_wch() function does not check if wget_wch() returned OK or KEY_CODE_YES. In either case, it simply returns the character code. This makes get_wch() unusable when keypad is enabled, because the caller cannot distinguish function key or arrow key presses from real unicode code points. For example, get_wch() returns 259 both for an up arrow press and for the input character '?'. It seems like this API needs to be redesigned somehow to allow terminal keypad codes to be distinguished from unicode input. ---------- components: Library (Lib) messages: 169165 nosy: simpkins priority: normal severity: normal status: open title: curses.get_wch() returns keypad codes incorrectly type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 26 12:59:20 2012 From: report at bugs.python.org (aliles) Date: Sun, 26 Aug 2012 10:59:20 +0000 Subject: [issue8256] input() doesn't catch _PyUnicode_AsString() exception; io.StringIO().encoding is None In-Reply-To: <1269807316.51.0.487538621224.issue8256@psf.upfronthosting.co.za> Message-ID: <1345978760.7.0.580862885146.issue8256@psf.upfronthosting.co.za> aliles added the comment: Upload new patch that uses encoding and errors from stderr if stdout values are invalid unicode. Includes unit test in test_builtin.py. With this patch I am no longer able to replicate this issue. ---------- Added file: http://bugs.python.org/file27006/p1345978092.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 26 14:08:20 2012 From: report at bugs.python.org (Christian Heimes) Date: Sun, 26 Aug 2012 12:08:20 +0000 Subject: [issue15781] test_threaded_import fails with -j4 In-Reply-To: <1345883620.41.0.296577026972.issue15781@psf.upfronthosting.co.za> Message-ID: <1345982900.48.0.308907429136.issue15781@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 26 18:32:20 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 26 Aug 2012 16:32:20 +0000 Subject: [issue15785] curses.get_wch() returns keypad codes incorrectly In-Reply-To: <1345975778.97.0.705241878581.issue15785@psf.upfronthosting.co.za> Message-ID: <1345998740.25.0.869205726988.issue15785@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 26 18:46:03 2012 From: report at bugs.python.org (Matthew Barnett) Date: Sun, 26 Aug 2012 16:46:03 +0000 Subject: [issue10076] Regex objects became uncopyable in 2.5 In-Reply-To: <1286916324.24.0.772801528988.issue10076@psf.upfronthosting.co.za> Message-ID: <1345999563.8.0.923253086052.issue10076@psf.upfronthosting.co.za> Matthew Barnett added the comment: Is it necessary to actually copy it? Isn't the pattern object immutable? ---------- nosy: +mrabarnett _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 26 20:51:04 2012 From: report at bugs.python.org (Georg Brandl) Date: Sun, 26 Aug 2012 18:51:04 +0000 Subject: [issue15720] move __import__() out of the default lookup chain In-Reply-To: <1345261089.07.0.0712105087978.issue15720@psf.upfronthosting.co.za> Message-ID: <1346007064.39.0.280192262862.issue15720@psf.upfronthosting.co.za> Georg Brandl added the comment: I agree with David. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 26 20:56:19 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 26 Aug 2012 18:56:19 +0000 Subject: [issue15693] expose glossary link on hover In-Reply-To: <1345132108.78.0.567099034623.issue15693@psf.upfronthosting.co.za> Message-ID: <1346007379.01.0.710815557279.issue15693@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I submitted a patch for this issue on the Sphinx tracker. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 26 21:31:50 2012 From: report at bugs.python.org (Roger Serwy) Date: Sun, 26 Aug 2012 19:31:50 +0000 Subject: [issue15780] IDLE (windows) with PYTHONPATH and multiple python versions In-Reply-To: <1345841085.37.0.939660475067.issue15780@psf.upfronthosting.co.za> Message-ID: <1346009510.96.0.203952037676.issue15780@psf.upfronthosting.co.za> Roger Serwy added the comment: Look in the registry at "Computer\HKEY_CLASSES_ROOT\Python.File\shell\" and then inspect the launch commands under "open\command" and "Edit with IDLE\command". ---------- nosy: +serwy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 26 21:51:17 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 26 Aug 2012 19:51:17 +0000 Subject: [issue15785] curses.get_wch() returns keypad codes incorrectly In-Reply-To: <1345975778.97.0.705241878581.issue15785@psf.upfronthosting.co.za> Message-ID: <1346010677.28.0.787049765872.issue15785@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 26 21:58:04 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 26 Aug 2012 19:58:04 +0000 Subject: [issue15753] No-argument super in method with variable arguments raises SystemError In-Reply-To: <1345549960.82.0.102703520127.issue15753@psf.upfronthosting.co.za> Message-ID: <1346011084.67.0.576947759908.issue15753@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 26 22:05:03 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 26 Aug 2012 20:05:03 +0000 Subject: [issue15783] decimal.localcontext(None) fails when using the C accelerator module In-Reply-To: <1345904683.65.0.863127291798.issue15783@psf.upfronthosting.co.za> Message-ID: <1346011503.28.0.510034351127.issue15783@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 26 22:13:06 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 26 Aug 2012 20:13:06 +0000 Subject: [issue15731] Mechanism for inheriting docstrings and signatures In-Reply-To: <1345437452.28.0.514901819881.issue15731@psf.upfronthosting.co.za> Message-ID: <1346011986.44.0.540239049959.issue15731@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 26 23:07:40 2012 From: report at bugs.python.org (STINNER Victor) Date: Sun, 26 Aug 2012 21:07:40 +0000 Subject: [issue15785] curses.get_wch() returns keypad codes incorrectly In-Reply-To: <1345975778.97.0.705241878581.issue15785@psf.upfronthosting.co.za> Message-ID: <1346015260.26.0.3127259418.issue15785@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, right. I agree that the current implementation of window.get_wch() is useless. I missed completly key codes. Attached patch changes the API of get_wch() from get_wch()->key:int to get_wch()->(is_key_code: bool, key: str). Examples: (True, 'KEY_UP'), (False, '?'). Problem: unget_wch() test fails. "unget_wch('?'); is_key_code, ch = win.get_wch()" returns is_key_code=True, ch=''. I don't see how to specify to unget_wch() if the argument is a key code or not... It's maybe an issue in unget_wch() API that cannot be fixed in Python? ---------- keywords: +patch Added file: http://bugs.python.org/file27007/curses_get_wch.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 26 23:09:32 2012 From: report at bugs.python.org (STINNER Victor) Date: Sun, 26 Aug 2012 21:09:32 +0000 Subject: [issue15785] curses.get_wch() returns keypad codes incorrectly In-Reply-To: <1345975778.97.0.705241878581.issue15785@psf.upfronthosting.co.za> Message-ID: <1346015372.19.0.841675700561.issue15785@psf.upfronthosting.co.za> STINNER Victor added the comment: I consider this issue as a release blocker because the bug requires to change the API (of a function added to Python 3.3). If this issue cannot be fixed before Python 3.3 final, I prefer to drop the function until a better implementation is written. ---------- priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 00:27:46 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 26 Aug 2012 22:27:46 +0000 Subject: [issue1432343] Description of file-object read() method is wrong. Message-ID: <1346020066.63.0.500804926927.issue1432343@psf.upfronthosting.co.za> R. David Murray added the comment: It looks to me like we (now, as of 67dc99a989cd) handle EINTR, so that the suggested caveat is no longer true. Since the TTY example has also been explained as correct, I'm going to close this. If I'm wrong about EINTR, someone (Antoine or Gregory, presumably) can reopen it... ---------- assignee: docs at python -> nosy: +gregory.p.smith, r.david.murray resolution: -> out of date stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 02:11:16 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 27 Aug 2012 00:11:16 +0000 Subject: [issue9148] os.execve puts process to background on windows In-Reply-To: <1278156575.44.0.771660264126.issue9148@psf.upfronthosting.co.za> Message-ID: <1346026276.25.0.409789356554.issue9148@psf.upfronthosting.co.za> R. David Murray added the comment: This looks like the answer to the cygwin question, assuming things haven't changed: http://cygwin.com/ml/cygwin-developers/2001-02/msg00106.html Basically, it does the same thing as Python, except that a special return code is reported by the execing process to signal to whoever created the execing process that an exec has occurred. Would it be at all useful to add such a return code? ---------- nosy: +r.david.murray versions: +Python 3.4 -Python 2.6, Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 02:35:01 2012 From: report at bugs.python.org (suddha sourav) Date: Mon, 27 Aug 2012 00:35:01 +0000 Subject: [issue15786] IDLE code completion window does not scoll/select with mouse Message-ID: <1346027701.33.0.908436854594.issue15786@psf.upfronthosting.co.za> New submission from suddha sourav: In IDLE, pressing tab brings up the code completion menu - however, the scrollbar, when clicked, does not scroll - it disappears. Same goes for clicking an option in the code completion widget - it disappears. Keyboard navigation (pgup/pgdown/up/down) and tab works. In addition, pressing enter does not autocomplete but execute what was meant to be selected. ---------- components: IDLE messages: 169175 nosy: suddha.sourav priority: normal severity: normal status: open title: IDLE code completion window does not scoll/select with mouse versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 05:25:24 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 27 Aug 2012 03:25:24 +0000 Subject: [issue3760] PEP 3121 --- PyType_Copy is missing In-Reply-To: <1220383344.44.0.399854586534.issue3760@psf.upfronthosting.co.za> Message-ID: <1346037924.87.0.0312141641716.issue3760@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 05:26:30 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 27 Aug 2012 03:26:30 +0000 Subject: [issue15720] move __import__() out of the default lookup chain In-Reply-To: <1345261089.07.0.0712105087978.issue15720@psf.upfronthosting.co.za> Message-ID: <1346037990.1.0.501666590134.issue15720@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Definitely "won't fix" until at least Python 4. ---------- nosy: +benjamin.peterson resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 05:29:41 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 27 Aug 2012 03:29:41 +0000 Subject: [issue15390] PEP 3121, 384 refactoring applied to datetime module In-Reply-To: <1342647232.82.0.0763290244077.issue15390@psf.upfronthosting.co.za> Message-ID: <1346038181.23.0.273126627098.issue15390@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- assignee: -> belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 05:30:28 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 27 Aug 2012 03:30:28 +0000 Subject: [issue15711] PEP 3121, 384 Refactoring applied to time module In-Reply-To: <1345152968.9.0.714502729899.issue15711@psf.upfronthosting.co.za> Message-ID: <1346038227.99.0.979535849327.issue15711@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- assignee: -> belopolsky nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 05:36:05 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 27 Aug 2012 03:36:05 +0000 Subject: [issue15787] PEP 3121 Refactoring Message-ID: <1346038565.61.0.980658052428.issue15787@psf.upfronthosting.co.za> New submission from Alexander Belopolsky: This is a meta-issue to keep track of a global PEP 3121 refactoring effort. Per-module issues will be added as dependencies. Let's move the discussion that is not specific to any particular module here. ---------- components: Extension Modules messages: 169177 nosy: Robin.Schreiber, belopolsky priority: normal severity: normal status: open title: PEP 3121 Refactoring type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 05:40:58 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 27 Aug 2012 03:40:58 +0000 Subject: [issue15787] PEP 3121 Refactoring In-Reply-To: <1346038565.61.0.980658052428.issue15787@psf.upfronthosting.co.za> Message-ID: <1346038858.88.0.727507072735.issue15787@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- dependencies: +PEP 3121, 384 refactoring applied to curses module, PEP 3121, 384 refactoring applied to datetime module, PEP 3121, 384 refactoring applied to dbm module _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 05:41:57 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 27 Aug 2012 03:41:57 +0000 Subject: [issue15787] PEP 3121 Refactoring In-Reply-To: <1346038565.61.0.980658052428.issue15787@psf.upfronthosting.co.za> Message-ID: <1346038917.88.0.519001191561.issue15787@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- dependencies: +PEP 3121, 384 refactoring applied to elementtree module, PEP 3121, 384 refactoring applied to gdbm module, PEP 3121, 384 refactoring applied to hashopenssl module, PEP 3121, 384 refactoring applied to lzma module _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 05:42:36 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 27 Aug 2012 03:42:36 +0000 Subject: [issue15787] PEP 3121 Refactoring In-Reply-To: <1346038565.61.0.980658052428.issue15787@psf.upfronthosting.co.za> Message-ID: <1346038956.33.0.312050041192.issue15787@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- dependencies: +PEP 3121 refactoring applied to audioop module, PEP 3121 refactoring applied to binascii module, PEP 3121 refactoring applied to fpectl module, PEP 3121, 384 Refactoring applied to array module, PEP 3121, 384 Refactoring applied to random module, PEP 3121, 384 Refactoring applied to sre module, PEP 3121, 384 Refactoring applied to ssl module, PEP 3121, 384 Refactoring applied to struct module, PEP 3121, 384 Refactoring applied to testbuffer module, PEP 3121, 384 Refactoring applied to testcapi module, PEP 3121, 384 Refactoring applied to thread module, PEP 3121, 384 refactoring applied to pickle module _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 05:46:04 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 27 Aug 2012 03:46:04 +0000 Subject: [issue15787] PEP 3121 Refactoring In-Reply-To: <1346038565.61.0.980658052428.issue15787@psf.upfronthosting.co.za> Message-ID: <1346039164.59.0.909629982767.issue15787@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- dependencies: +Add VS CRT redist to the MSI installer, PEP 3121 Refactoring applied to nis module, PEP 3121 refactoring applied to fpetest module, PEP 3121 refactoring applied to pwd module, PEP 3121, 384 Refactoring applied to itertools module, PEP 3121, 384 Refactoring applied to md5 module, PEP 3121, 384 Refactoring applied to mmap module, PEP 3121, 384 Refactoring applied to operator module, PEP 3121, 384 Refactoring applied to parser module, PEP 3121, 384 Refactoring applied to posix module, PEP 3121, 384 Refactoring applied to pyexpat module _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 05:46:18 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 27 Aug 2012 03:46:18 +0000 Subject: [issue15787] PEP 3121 Refactoring In-Reply-To: <1346038565.61.0.980658052428.issue15787@psf.upfronthosting.co.za> Message-ID: <1346039178.3.0.0523940560241.issue15787@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- dependencies: -Add VS CRT redist to the MSI installer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 05:49:13 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 27 Aug 2012 03:49:13 +0000 Subject: [issue15787] PEP 3121 Refactoring In-Reply-To: <1346038565.61.0.980658052428.issue15787@psf.upfronthosting.co.za> Message-ID: <1346039353.99.0.622044102345.issue15787@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- dependencies: +PEP 3121, 384 Refactoring applied to decimal module, PEP 3121, 384 Refactoring applied to grp module, PEP 3121, 384 Refactoring applied to ossaudio module, PEP 3121, 384 Refactoring applied to resource module, PEP 3121, 384 Refactoring applied to select module, PEP 3121, 384 Refactoring applied to sha1 module, PEP 3121, 384 Refactoring applied to sha256 module, PEP 3121, 384 Refactoring applied to sha512 module, PEP 3121, 384 Refactoring applied to signal module, PEP 3121, 384 Refactoring applied to socket module, PEP 3121, 384 Refactoring applied to spwd module, PEP 3121, 384 Refactoring applied to termios module, PEP 3121, 384 Refactoring applied to time module, PEP 3121, 384 Refactoring applied to tkinter module, PEP 3121, 384 Refactoring applied to unicodedata module, PEP 3121, 384 Refactoring applied to winapi module, PEP 3121, 384 Refactoring applied to zipimport module _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 05:54:38 2012 From: report at bugs.python.org (Colin Su) Date: Mon, 27 Aug 2012 03:54:38 +0000 Subject: [issue15786] IDLE code completion window does not scoll/select with mouse In-Reply-To: <1346027701.33.0.908436854594.issue15786@psf.upfronthosting.co.za> Message-ID: <1346039678.29.0.654296976094.issue15786@psf.upfronthosting.co.za> Colin Su added the comment: On which platform? ---------- nosy: +littleq0903 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 05:56:27 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 27 Aug 2012 03:56:27 +0000 Subject: [issue15787] PEP 3121 Refactoring In-Reply-To: <1346038565.61.0.980658052428.issue15787@psf.upfronthosting.co.za> Message-ID: <1346039787.5.0.852559767811.issue15787@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Robin, Perhaps we should start with the "xx" modules: Modules/xxmodule.c and Modules/xxsubtype.c. These modules server as a demonstration of best practices and it is natural to use them to iron out any refactoring issues without any risk to deployed code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 05:57:31 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 27 Aug 2012 03:57:31 +0000 Subject: [issue15787] PEP 3121 Refactoring In-Reply-To: <1346038565.61.0.980658052428.issue15787@psf.upfronthosting.co.za> Message-ID: <1346039851.78.0.591369681278.issue15787@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 07:00:15 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Mon, 27 Aug 2012 05:00:15 +0000 Subject: [issue13769] json.dump(ensure_ascii=False) return str instead of unicode In-Reply-To: <1326300079.82.0.279410736545.issue13769@psf.upfronthosting.co.za> Message-ID: <1346043615.43.0.759302166798.issue13769@psf.upfronthosting.co.za> Petri Lehtinen added the comment: It seems to me that when ensure_ascii is False, the return value will be a unicode instance if and only if there's a unicode object anywhere in the input. >>> json.dumps({'foo': 'bar'}, ensure_ascii=False) '{"foo": "bar"}' >>> json.dumps({'foo': u'bar'}, ensure_ascii=False) u'{"foo": "bar"}' >>> json.dumps({'foo': u'?iti'}, ensure_ascii=False) u'{"foo": "\xe4iti"}' >>> json.dumps({'foo': u'?iti'.encode('utf-8')}, ensure_ascii=False) '{"foo": "\xc3\xa4iti"}' >>> json.dumps({'foo': u'?iti'.encode('utf-16')}, ensure_ascii=False) '{"foo": "\xff\xfe\xe4\\u0000i\\u0000t\\u0000i\\u0000"}' ---------- nosy: +petri.lehtinen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 07:50:14 2012 From: report at bugs.python.org (Chris Rebert) Date: Mon, 27 Aug 2012 05:50:14 +0000 Subject: [issue14880] csv.reader and .writer use wrong kwargs notation in 2.7 docs In-Reply-To: <1337670456.12.0.0273828432105.issue14880@psf.upfronthosting.co.za> Message-ID: <1346046614.92.0.7614932592.issue14880@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- keywords: +patch Added file: http://bugs.python.org/file27008/issue14880.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 07:59:42 2012 From: report at bugs.python.org (Chris Rebert) Date: Mon, 27 Aug 2012 05:59:42 +0000 Subject: [issue14824] reprlib documentation references string module In-Reply-To: <1337147544.42.0.726566417701.issue14824@psf.upfronthosting.co.za> Message-ID: <1346047182.91.0.127291935526.issue14824@psf.upfronthosting.co.za> Chris Rebert added the comment: Updated patch. I concur that anyone creating a type whose name has whitespace in it is just asking for trouble. ---------- Added file: http://bugs.python.org/file27009/reprlib.rst.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 08:46:20 2012 From: report at bugs.python.org (Chris Rebert) Date: Mon, 27 Aug 2012 06:46:20 +0000 Subject: [issue15788] cross-refs in the subprocess.Popen.std{in, out, err} warning box aren't linked Message-ID: <1346049980.8.0.0439689816925.issue15788@psf.upfronthosting.co.za> New submission from Chris Rebert: The cross-references, particularly to Popen.communicate(), in the warning box in the subprocess docs about using Popen.stdout.read() etc. aren't hyperlinked. The attached patch fixes that. ---------- assignee: docs at python components: Documentation files: link_communicate_warning.patch keywords: patch messages: 169182 nosy: cvrebert, docs at python priority: normal severity: normal status: open title: cross-refs in the subprocess.Popen.std{in,out,err} warning box aren't linked versions: Python 2.7, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file27010/link_communicate_warning.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 08:48:20 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 27 Aug 2012 06:48:20 +0000 Subject: [issue15788] cross-refs in the subprocess.Popen.std{in, out, err} warning box aren't linked In-Reply-To: <1346049980.8.0.0439689816925.issue15788@psf.upfronthosting.co.za> Message-ID: <1346050100.48.0.664040509155.issue15788@psf.upfronthosting.co.za> Ezio Melotti added the comment: + Use :meth:`communicate() ` I believe you can simply use :meth:`~Popen.communicate` here. ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 08:52:42 2012 From: report at bugs.python.org (Chris Rebert) Date: Mon, 27 Aug 2012 06:52:42 +0000 Subject: [issue15788] cross-refs in the subprocess.Popen.std{in, out, err} warning box aren't linked In-Reply-To: <1346049980.8.0.0439689816925.issue15788@psf.upfronthosting.co.za> Message-ID: <1346050362.56.0.137940596408.issue15788@psf.upfronthosting.co.za> Chris Rebert added the comment: So you can. Neat trick. Patch changed accordingly. ---------- Added file: http://bugs.python.org/file27011/link_communicate_warning.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 08:54:17 2012 From: report at bugs.python.org (Chris Rebert) Date: Mon, 27 Aug 2012 06:54:17 +0000 Subject: [issue15788] cross-refs in the subprocess.Popen.std{in, out, err} warning box aren't linked In-Reply-To: <1346049980.8.0.0439689816925.issue15788@psf.upfronthosting.co.za> Message-ID: <1346050457.02.0.401007519126.issue15788@psf.upfronthosting.co.za> Chris Rebert added the comment: Let's try that again. ---------- Added file: http://bugs.python.org/file27012/link_communicate_warning.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 08:54:23 2012 From: report at bugs.python.org (Chris Rebert) Date: Mon, 27 Aug 2012 06:54:23 +0000 Subject: [issue15788] cross-refs in the subprocess.Popen.std{in, out, err} warning box aren't linked In-Reply-To: <1346049980.8.0.0439689816925.issue15788@psf.upfronthosting.co.za> Message-ID: <1346050463.99.0.830220735607.issue15788@psf.upfronthosting.co.za> Changes by Chris Rebert : Removed file: http://bugs.python.org/file27011/link_communicate_warning.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 09:07:00 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 27 Aug 2012 07:07:00 +0000 Subject: [issue15788] cross-refs in the subprocess.Popen.std{in, out, err} warning box aren't linked In-Reply-To: <1346049980.8.0.0439689816925.issue15788@psf.upfronthosting.co.za> Message-ID: <3X540M1VXvzQFk@mail.python.org> Roundup Robot added the comment: New changeset 92aa438a5c4b by Ezio Melotti in branch '2.7': #15788: fix broken links in subprocess doc. Patch by Chris Rebert. http://hg.python.org/cpython/rev/92aa438a5c4b New changeset 1676e423054a by Ezio Melotti in branch '3.2': #15788: fix broken links in subprocess doc. Patch by Chris Rebert. http://hg.python.org/cpython/rev/1676e423054a New changeset 64640a02b0ca by Ezio Melotti in branch 'default': #15788: merge with 3.2. http://hg.python.org/cpython/rev/64640a02b0ca ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 09:07:57 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 27 Aug 2012 07:07:57 +0000 Subject: [issue15788] cross-refs in the subprocess.Popen.std{in, out, err} warning box aren't linked In-Reply-To: <1346049980.8.0.0439689816925.issue15788@psf.upfronthosting.co.za> Message-ID: <1346051277.2.0.200331408782.issue15788@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the patch! ---------- assignee: docs at python -> ezio.melotti resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> enhancement versions: +Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 09:24:02 2012 From: report at bugs.python.org (Chris Rebert) Date: Mon, 27 Aug 2012 07:24:02 +0000 Subject: [issue15789] mention shell-like parts of the std lib in the subprocess docs Message-ID: <1346052242.66.0.254880477781.issue15789@psf.upfronthosting.co.za> New submission from Chris Rebert: To further dissuade people from using subprocess.Popen's shell=True option unnecessarily, this patch points out that some common shell features are also available directly in Python via certain modules & functions. ---------- assignee: docs at python components: Documentation files: subprocess.rst.patch keywords: patch messages: 169188 nosy: cvrebert, docs at python priority: normal severity: normal status: open title: mention shell-like parts of the std lib in the subprocess docs versions: Python 2.7, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file27013/subprocess.rst.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 09:34:41 2012 From: report at bugs.python.org (Chris Rebert) Date: Mon, 27 Aug 2012 07:34:41 +0000 Subject: [issue15767] add ModuleNotFoundError In-Reply-To: <1345664718.23.0.712313947558.issue15767@psf.upfronthosting.co.za> Message-ID: <1346052881.43.0.677421789871.issue15767@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 09:46:29 2012 From: report at bugs.python.org (Chris Rebert) Date: Mon, 27 Aug 2012 07:46:29 +0000 Subject: [issue14570] Document json "sort_keys" parameter properly In-Reply-To: <1334284947.71.0.88941407788.issue14570@psf.upfronthosting.co.za> Message-ID: <1346053589.9.0.320255549846.issue14570@psf.upfronthosting.co.za> Chris Rebert added the comment: Erm, the patch seems to have some ANSI terminal coloring escape code junk (e.g. "") in it... ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 09:54:46 2012 From: report at bugs.python.org (Chris Rebert) Date: Mon, 27 Aug 2012 07:54:46 +0000 Subject: [issue11964] Undocumented change to indent param of json.dump in 3.2 In-Reply-To: <1304178435.78.0.522459822796.issue11964@psf.upfronthosting.co.za> Message-ID: <1346054086.43.0.46781164748.issue11964@psf.upfronthosting.co.za> Chris Rebert added the comment: It's been over a year and the patch is trivial. Any chance of it getting applied soon? ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 10:16:37 2012 From: report at bugs.python.org (suddha sourav) Date: Mon, 27 Aug 2012 08:16:37 +0000 Subject: [issue15786] IDLE code completion window does not scoll/select with mouse In-Reply-To: <1346027701.33.0.908436854594.issue15786@psf.upfronthosting.co.za> Message-ID: <1346055397.22.0.139575963666.issue15786@psf.upfronthosting.co.za> suddha sourav added the comment: Platform is Windows 7 Professional 64-bit. Sorry for not including the information! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 11:02:02 2012 From: report at bugs.python.org (Chris Rebert) Date: Mon, 27 Aug 2012 09:02:02 +0000 Subject: [issue15533] subprocess.Popen(cwd) documentation In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za> Message-ID: <1346058122.26.0.698208017083.issue15533@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 11:03:20 2012 From: report at bugs.python.org (Chris Rebert) Date: Mon, 27 Aug 2012 09:03:20 +0000 Subject: [issue7186] Document specialness of __doc__, and possibly other "special" attributes In-Reply-To: <1256240855.61.0.550470965616.issue7186@psf.upfronthosting.co.za> Message-ID: <1346058200.93.0.629214677226.issue7186@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 11:03:30 2012 From: report at bugs.python.org (Chris Rebert) Date: Mon, 27 Aug 2012 09:03:30 +0000 Subject: [issue9650] format codes in time.strptime docstrings In-Reply-To: <1282319380.5.0.724924373031.issue9650@psf.upfronthosting.co.za> Message-ID: <1346058210.6.0.315883693883.issue9650@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 11:03:46 2012 From: report at bugs.python.org (Chris Rebert) Date: Mon, 27 Aug 2012 09:03:46 +0000 Subject: [issue14783] Update int() docstring from manual In-Reply-To: <1336751413.58.0.519130225761.issue14783@psf.upfronthosting.co.za> Message-ID: <1346058226.22.0.401066787926.issue14783@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 11:18:26 2012 From: report at bugs.python.org (Chris Rebert) Date: Mon, 27 Aug 2012 09:18:26 +0000 Subject: [issue14870] Descriptions of os.utime() and os.utimensat() use wrong notation In-Reply-To: <1337601006.45.0.685713178373.issue14870@psf.upfronthosting.co.za> Message-ID: <1346059106.24.0.426699136462.issue14870@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 11:31:34 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 27 Aug 2012 09:31:34 +0000 Subject: [issue15761] Setting PYTHONEXECUTABLE can cause segfaults on OS X In-Reply-To: <1345623707.33.0.86377230375.issue15761@psf.upfronthosting.co.za> Message-ID: <1346059894.54.0.0975492790641.issue15761@psf.upfronthosting.co.za> Changes by Ronald Oussoren : ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 11:44:55 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 27 Aug 2012 09:44:55 +0000 Subject: [issue15787] PEP 3121 Refactoring In-Reply-To: <1346038565.61.0.980658052428.issue15787@psf.upfronthosting.co.za> Message-ID: <1346060695.61.0.513643298712.issue15787@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 12:02:51 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Mon, 27 Aug 2012 10:02:51 +0000 Subject: [issue14880] csv.reader and .writer use wrong kwargs notation in 2.7 docs In-Reply-To: <1337670456.12.0.0273828432105.issue14880@psf.upfronthosting.co.za> Message-ID: <1346061771.71.0.584468795014.issue14880@psf.upfronthosting.co.za> Petri Lehtinen added the comment: Chris: Thanks for the patch. I'm not sure register_dialect()'s signature is good like that, though. Hynek, what do you think? ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 12:20:45 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 27 Aug 2012 10:20:45 +0000 Subject: [issue9650] format codes in time.strptime docstrings In-Reply-To: <1282319380.5.0.724924373031.issue9650@psf.upfronthosting.co.za> Message-ID: <1346062845.75.0.351658753903.issue9650@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I would like to add my +1 to this issue. I suggest adding something like this: """ Commonly used format codes: %Y Year with century as a decimal number. %m Month as a decimal number [01,12]. %d Day of the month as a decimal number [01,31]. %H Hour (24-hour clock) as a decimal number [00,23]. %M Minute as a decimal number [00,59]. %S Second as a decimal number [00,61]. %z Time zone offset from UTC. %a Locale?s abbreviated weekday name. %A Locale?s full weekday name. %b Locale?s abbreviated month name. %B Locale?s full month name. %c Locale?s appropriate date and time representation. Other codes may be available on your platform. See documentation for the C library strftime function. """ This is a subjective selection in a subjective order of importance, so some bikesheding is welcome. My choice was motivated by the assumption that most commonly used are the codes required to form RFC 3339 timestamps. I deliberately omitted deprecated %y code and the %Z code that produces non-standardized TZ names. I can be persuaded to add 12 hour clock codes. ---------- assignee: docs at python -> belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 13:41:37 2012 From: report at bugs.python.org (Pas) Date: Mon, 27 Aug 2012 11:41:37 +0000 Subject: [issue15790] Python 3.3.0rc1 release notes claims PEP-405 support, yet pysetup is not in the package (needs more usage documentation, to get pip working) Message-ID: <1346067697.02.0.646215299942.issue15790@psf.upfronthosting.co.za> New submission from Pas: Python 3.3.0rc1 release notes ( http://python.org/download/releases/3.3.0/ ) claims PEP-405 support, yet pysetup is not in the tarball. (After reading through mailing lists and bugs it's clear that the move to "packaging" module got pulled, so it's still just distutils in there.) There is no documentation on how to get a pyvenv (or virtualenv, or any other virtual enviroment solution) built venv to gain setuptools/pip support. ---------- assignee: docs at python components: Documentation messages: 169194 nosy: docs at python, pas priority: normal severity: normal status: open title: Python 3.3.0rc1 release notes claims PEP-405 support, yet pysetup is not in the package (needs more usage documentation, to get pip working) versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 13:53:21 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 27 Aug 2012 11:53:21 +0000 Subject: [issue15790] Python 3.3.0rc1 release notes claims PEP-405 support, yet pysetup is not in the package (needs more usage documentation, to get pip working) In-Reply-To: <1346067697.02.0.646215299942.issue15790@psf.upfronthosting.co.za> Message-ID: <1346068401.37.0.380352050775.issue15790@psf.upfronthosting.co.za> Ronald Oussoren added the comment: PEP 405 is for "venv" support and that is available. Documenting how to use pip/distribute/setuptools with venv is IMHO beyond the scope of the stdlib documentation (and should be easy enough: create a virtual environment using pyvenv, then install pip using its setup.py file). The pep mentions the pysetup script from the packaging module, but as the packaging module got pulled for python 3.3 the pysetup script is not present in the python 3.3 installation and therefore also not in venv-s. ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 14:28:43 2012 From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=) Date: Mon, 27 Aug 2012 12:28:43 +0000 Subject: [issue15791] pydoc does not handle unicode AUTHOR field Message-ID: <1346070523.56.0.605519792769.issue15791@psf.upfronthosting.co.za> New submission from Michele Orr?: $ echo "__author__ = u'Michele Orr\xf9'" > foo.py && python -c "import foo; print foo.__author__; help(foo)" Michele Orr? Traceback (most recent call last): File "", line 1, in File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site.py", line 467, in __call__ return pydoc.help(*args, **kwds) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pydoc.py", line 1747, in __call__ self.help(request) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pydoc.py", line 1794, in help else: doc(request, 'Help on %s:') File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pydoc.py", line 1531, in doc pager(render_doc(thing, title, forceload)) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pydoc.py", line 1526, in render_doc return title % desc + '\n\n' + text.document(object, name) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pydoc.py", line 329, in document if inspect.ismodule(object): return self.docmodule(*args) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pydoc.py", line 1126, in docmodule result = result + self.section('AUTHOR', str(object.__author__)) UnicodeEncodeError: 'ascii' codec can't encode character u'\xf9' in position 11: ordinal not in range(128) ---------- components: Unicode messages: 169196 nosy: eric.araujo, ezio.melotti, maker priority: normal severity: normal status: open title: pydoc does not handle unicode AUTHOR field type: crash versions: Python 2.6, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 14:56:08 2012 From: report at bugs.python.org (Pas) Date: Mon, 27 Aug 2012 12:56:08 +0000 Subject: [issue15790] Python 3.3.0rc1 release notes claims PEP-405 support, yet pysetup is not in the package (needs more usage documentation, to get pip working) In-Reply-To: <1346067697.02.0.646215299942.issue15790@psf.upfronthosting.co.za> Message-ID: <1346072168.88.0.993036086752.issue15790@psf.upfronthosting.co.za> Pas added the comment: It's not straightforward, at all. # (v3.3rc1) /home/pas/wololo/pip-1.1$ python setup.py install Traceback (most recent call last): File "setup.py", line 3, in from setuptools import setup ImportError: No module named 'setuptools' Then, of course one can try installing setuptools, but it won't work. Traceback (most recent call last): File "setup.py", line 7, in execfile(convert_path('setuptools/command/__init__.py'), d) NameError: name 'execfile' is not defined So, yes, venv is available. Great. But Python is not so great without those batteries, which are allegedly included. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 15:03:20 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 27 Aug 2012 13:03:20 +0000 Subject: [issue15790] Python 3.3.0rc1 release notes claims PEP-405 support, yet pysetup is not in the package (needs more usage documentation, to get pip working) In-Reply-To: <1346067697.02.0.646215299942.issue15790@psf.upfronthosting.co.za> Message-ID: <1346072600.41.0.166027236582.issue15790@psf.upfronthosting.co.za> Ronald Oussoren added the comment: pyvenv won't install setuptools because setuptools is not a stdlib package. Having packaging would have been nice, but that library was not in a good enough shape for the 3.3 release. I don't understand what you try to do in the second traceback. Installing distribute works fine though: 1) Create environment using pyvenv: $ pyenv myenv 2) Download distribute archive from PyPI 3) Extract this archive 4) Install: $ cd distribute-0.6.28; ../pyenv/bin/python setup.py install If you have a setup.py file where you want to use the distribute package you can use distribute_setup, as described in . I'm using this in my own packages and this works fine with pyvenv as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 15:08:48 2012 From: report at bugs.python.org (Aaron Iles) Date: Mon, 27 Aug 2012 13:08:48 +0000 Subject: [issue12403] Mention sys.displayhook in code module docs and the compile builtin docs In-Reply-To: <1308959744.93.0.261089879651.issue12403@psf.upfronthosting.co.za> Message-ID: <1346072928.31.0.118646474607.issue12403@psf.upfronthosting.co.za> Aaron Iles added the comment: I've submitted a patch which adds a section to the code module's documentation on overriding console output. It attempts to catalogue when sys.stderr, sys.excepthook and sys.displayhook are used to print console output. ---------- keywords: +patch nosy: +aliles Added file: http://bugs.python.org/file27014/p1346072775.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 16:17:31 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Mon, 27 Aug 2012 14:17:31 +0000 Subject: [issue15792] Fix compiler options for x64 builds on Windows Message-ID: <1346077051.29.0.85020459134.issue15792@psf.upfronthosting.co.za> New submission from Jeremy Kloth: The attached patch fixes the compiler options used for building the x64 platform. - In VC10 the passing /GS- as an additional option has been replaced by the MSBuild BufferSecurityCheck command - The /USECL:xxx option is only for the VSExtComp plugin for VS.NET 2003 (VC7.1) used to build a 64-bit Python 2.5 The attached patch modifies the x64 properties for VS8/9/10. ---------- components: Build files: pcbuild.diff keywords: patch messages: 169200 nosy: jkloth priority: normal severity: normal status: open title: Fix compiler options for x64 builds on Windows versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file27015/pcbuild.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 16:34:56 2012 From: report at bugs.python.org (Pas) Date: Mon, 27 Aug 2012 14:34:56 +0000 Subject: [issue15790] Python 3.3.0rc1 release notes claims PEP-405 support, yet pysetup is not in the package (needs more usage documentation, to get pip working) In-Reply-To: <1346067697.02.0.646215299942.issue15790@psf.upfronthosting.co.za> Message-ID: <1346078096.63.0.218647781171.issue15790@psf.upfronthosting.co.za> Pas added the comment: Thank you. The missing detail was to install distribute when a package needs setuptools. So, documentation. The setuptools page doesn't even mention distribute. The PEP mentions both, even though setuptools pretty much looks incompatible with Py3.3. Anyway. I'm honestly grateful for your immediate responses. Thanks again for sorting this out, let's hope others will find this via a search engine. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 17:34:37 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 27 Aug 2012 15:34:37 +0000 Subject: [issue11964] Undocumented change to indent param of json.dump in 3.2 In-Reply-To: <1304178435.78.0.522459822796.issue11964@psf.upfronthosting.co.za> Message-ID: <1346081677.34.0.952084176806.issue11964@psf.upfronthosting.co.za> ?ric Araujo added the comment: See my previous message where I say that a careful check is needed. ---------- nosy: +sandro.tosi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 17:35:51 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 27 Aug 2012 15:35:51 +0000 Subject: [issue15791] pydoc does not handle non-ASCII unicode AUTHOR field In-Reply-To: <1346070523.56.0.605519792769.issue15791@psf.upfronthosting.co.za> Message-ID: <1346081751.14.0.22488950902.issue15791@psf.upfronthosting.co.za> ?ric Araujo added the comment: I think this works if you set PYTTHONIOENCODING=utf-8 in your environment. (2.6 does not get bugfixes anymore.) ---------- title: pydoc does not handle unicode AUTHOR field -> pydoc does not handle non-ASCII unicode AUTHOR field versions: -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 17:38:39 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 27 Aug 2012 15:38:39 +0000 Subject: [issue15791] pydoc does not handle non-ASCII unicode AUTHOR field In-Reply-To: <1346070523.56.0.605519792769.issue15791@psf.upfronthosting.co.za> Message-ID: <1346081919.52.0.319338795869.issue15791@psf.upfronthosting.co.za> ?ric Araujo added the comment: One could argue that since print does respect the terminal encoding if sys.stdin is a tty, pydoc could be as smart and do the same. I think the problem comes from the use of a pager, which means a subprocess, which mean that the streams are not ttys and the encoding can?t be detected. print doesn?t work either with pipes: python -c "import foo; print foo.__author__" | cat So I fear that this bug may only get a doc note. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 17:55:04 2012 From: report at bugs.python.org (Wichert Akkerman) Date: Mon, 27 Aug 2012 15:55:04 +0000 Subject: [issue2988] Invalid cookies crash web applications In-Reply-To: <1211963484.7.0.388679808819.issue2988@psf.upfronthosting.co.za> Message-ID: <1346082904.72.0.452861977084.issue2988@psf.upfronthosting.co.za> Wichert Akkerman added the comment: I do not agree that this is a fix. Effectively this means that if a user has a single cookie that SimpleCookie does not like a webapp can not use any cookie at all. Imho at a minimum there should be a way to tell SimpleCookie to ignore invalid cookies. ---------- nosy: +wichert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 17:56:13 2012 From: report at bugs.python.org (Wichert Akkerman) Date: Mon, 27 Aug 2012 15:56:13 +0000 Subject: [issue2988] Invalid cookies crash web applications In-Reply-To: <1211963484.7.0.388679808819.issue2988@psf.upfronthosting.co.za> Message-ID: <1346082973.13.0.704354341907.issue2988@psf.upfronthosting.co.za> Changes by Wichert Akkerman : ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 18:08:57 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 27 Aug 2012 16:08:57 +0000 Subject: [issue15533] subprocess.Popen(cwd) documentation In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za> Message-ID: <1346083737.84.0.799156787268.issue15533@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Attached are a few test cases showing that Popen *does* consider cwd when searching for the executable (as well as for args[0]), and in particular that you *can* specify the program's path relative to cwd. I also moved the test_cwd test to be adjacent to the other cwd test (the one that tests cwd with the executable argument). I can also prepare the documentation changes for addition to the patch. ---------- keywords: +patch Added file: http://bugs.python.org/file27016/issue-15533-test-cases-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 18:16:55 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 27 Aug 2012 16:16:55 +0000 Subject: [issue15533] subprocess.Popen(cwd) documentation In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za> Message-ID: <1346084215.11.0.830995090351.issue15533@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 18:22:21 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 27 Aug 2012 16:22:21 +0000 Subject: [issue15775] Add StopParser() to expat In-Reply-To: <1345796297.89.0.127411549702.issue15775@psf.upfronthosting.co.za> Message-ID: <1346084541.27.0.691086552145.issue15775@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: If a handler function raises an exception, the Parse() method exits and the exception is propagated; internally, this also calls XML_StopParser(). Why would one call XML_StopParser() explicitely? ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 18:29:26 2012 From: report at bugs.python.org (Zachary Ware) Date: Mon, 27 Aug 2012 16:29:26 +0000 Subject: [issue15783] decimal.localcontext(None) fails when using the C accelerator module In-Reply-To: <1345904683.65.0.863127291798.issue15783@psf.upfronthosting.co.za> Message-ID: <1346084966.79.0.580884480938.issue15783@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 18:38:22 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 27 Aug 2012 16:38:22 +0000 Subject: [issue15791] pydoc does not handle non-ASCII unicode AUTHOR field In-Reply-To: <1346070523.56.0.605519792769.issue15791@psf.upfronthosting.co.za> Message-ID: <1346085502.95.0.202954552527.issue15791@psf.upfronthosting.co.za> R. David Murray added the comment: There is a proposed patch in issue 1065986 waiting for review. ---------- nosy: +r.david.murray resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> Fix pydoc crashing on unicode strings type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 18:48:53 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 27 Aug 2012 16:48:53 +0000 Subject: [issue1065986] Fix pydoc crashing on unicode strings Message-ID: <1346086133.21.0.886291067807.issue1065986@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I fail to see how this patch solves this issue. Taking the example from issue15791, I still get the traceback of that issue, namely in the line result = result + self.section('AUTHOR', str(object.__author__)) If __author__ is a unicode object, it's the str call that fails. This is long before any attempt is made to render the resulting string to an output device. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 19:21:35 2012 From: report at bugs.python.org (Georg Brandl) Date: Mon, 27 Aug 2012 17:21:35 +0000 Subject: [issue15792] Fix compiler options for x64 builds on Windows In-Reply-To: <1346077051.29.0.85020459134.issue15792@psf.upfronthosting.co.za> Message-ID: <1346088095.48.0.0122161995496.issue15792@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 20:12:28 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 27 Aug 2012 18:12:28 +0000 Subject: [issue13405] Add DTrace probes In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za> Message-ID: <1346091148.73.0.578233255416.issue13405@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Samuel, the program complaining about not being able to find the C Preprocessor is the system "dtrace" executable. Looks like a dependency there. To check this hypotesis, create a file called "a.d", with the following content: """ provider test { probe abc(int); }; """ and try to generate the header file with the following command: """ dtrace -C -h -s a.d """ If that command complains about being unable to find the C Preprocessor, well, you need a C Preprocessor. If dtrace doesn't obey environment variables pointing to the preprocessor, that would be a dtrace bug. You could create a symbolic link to "clang" executable, but that would be an ugly hack. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 21:29:34 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Mon, 27 Aug 2012 19:29:34 +0000 Subject: [issue11964] Undocumented change to indent param of json.dump in 3.2 In-Reply-To: <1304178435.78.0.522459822796.issue11964@psf.upfronthosting.co.za> Message-ID: <1346095774.28.0.613502170944.issue11964@psf.upfronthosting.co.za> Petri Lehtinen added the comment: I don't think the test changes are needed, because both dump() and dumps() use JSONEncoder internally, and all current indent testing is done using dumps() anyway. More important would be to update the documentation of indent for JSONEncoder to match that of dump() and add the versionchanged directives to both. ---------- nosy: +petri.lehtinen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 21:54:11 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Mon, 27 Aug 2012 19:54:11 +0000 Subject: [issue11964] Undocumented change to indent param of json.dump in 3.2 In-Reply-To: <1304178435.78.0.522459822796.issue11964@psf.upfronthosting.co.za> Message-ID: <1346097251.19.0.516546595895.issue11964@psf.upfronthosting.co.za> Petri Lehtinen added the comment: Attached a new patch. ---------- Added file: http://bugs.python.org/file27017/issue11964.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 22:12:29 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 27 Aug 2012 20:12:29 +0000 Subject: [issue11964] Undocumented change to indent param of json.dump in 3.2 In-Reply-To: <1304178435.78.0.522459822796.issue11964@psf.upfronthosting.co.za> Message-ID: <1346098349.71.0.823312666533.issue11964@psf.upfronthosting.co.za> ?ric Araujo added the comment: LGTM. ---------- assignee: eric.araujo -> petri.lehtinen stage: needs patch -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 22:20:25 2012 From: report at bugs.python.org (Michael Shields) Date: Mon, 27 Aug 2012 20:20:25 +0000 Subject: [issue10076] Regex objects became uncopyable in 2.5 In-Reply-To: <1286916324.24.0.772801528988.issue10076@psf.upfronthosting.co.za> Message-ID: <1346098825.64.0.59147020729.issue10076@psf.upfronthosting.co.za> Michael Shields added the comment: It's not strictly necessary that re objects be copyable, but there's no reason to break it either. It's not strictly necessary that str or int be copyable either. This came up in code that had objects with a number of members, one of which was a regexp pattern object. deepcopy of this object broke in 2.5. ---------- nosy: +shields _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 22:23:47 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 27 Aug 2012 20:23:47 +0000 Subject: [issue15533] subprocess.Popen(cwd) documentation In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za> Message-ID: <1346099027.16.0.574388580112.issue15533@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Here is a full patch for the default branch (documentation correction and test cases for the documented behavior). If this patch looks acceptable, I can prepare a separate patch for 2.7. ---------- Added file: http://bugs.python.org/file27018/issue-15533-2-default.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 22:27:59 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 27 Aug 2012 20:27:59 +0000 Subject: [issue15533] subprocess.Popen(cwd) documentation In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za> Message-ID: <1346099279.15.0.320511116147.issue15533@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- keywords: +needs review stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 22:37:09 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 27 Aug 2012 20:37:09 +0000 Subject: [issue15533] subprocess.Popen(cwd) documentation In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za> Message-ID: <1346099829.76.0.757503282853.issue15533@psf.upfronthosting.co.za> Chris Jerdonek added the comment: python_dir = os.path.dirname(os.path.realpath(sys.executable)) wrong_cwd = os.path.join(python_dir, 'Doc') Actually, is there a better directory to be using for this? I'd like a directory that is guaranteed to exist that is in the same directory as sys.executable -- so that I can construct a simple relative path from that directory to sys.executable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 22:51:33 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 27 Aug 2012 20:51:33 +0000 Subject: [issue15781] test_threaded_import fails with -j4 In-Reply-To: <1345883620.41.0.296577026972.issue15781@psf.upfronthosting.co.za> Message-ID: <1346100693.27.0.263254020591.issue15781@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, I can now reproduce with setswitchinterval(). Here is a patch. There was a race between putting the new module in sys.modules and setting its __initializing__ attribute, so now __initializing__ is set before putting the module in sys.modules. Also, there was another race when retrieving a module lock from the locks dict (the weakref could be destroyed between the __contains__ test and the actual fetch). ---------- keywords: +patch nosy: +georg.brandl priority: normal -> release blocker stage: -> patch review Added file: http://bugs.python.org/file27019/importrace.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 22:59:45 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 27 Aug 2012 20:59:45 +0000 Subject: [issue15792] Fix compiler options for x64 builds on Windows In-Reply-To: <1346077051.29.0.85020459134.issue15792@psf.upfronthosting.co.za> Message-ID: <1346101185.56.0.0760033873161.issue15792@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +brian.curtin, tim.golden _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 22:59:47 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 27 Aug 2012 20:59:47 +0000 Subject: [issue15781] test_threaded_import fails with -j4 In-Reply-To: <1345883620.41.0.296577026972.issue15781@psf.upfronthosting.co.za> Message-ID: <1346101187.5.0.958354055309.issue15781@psf.upfronthosting.co.za> Brett Cannon added the comment: Didn't patch it in to evaluate the surrounding code, but otherwise the patch LGTM. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 23:02:26 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 27 Aug 2012 21:02:26 +0000 Subject: [issue15785] curses.get_wch() returns keypad codes incorrectly In-Reply-To: <1345975778.97.0.705241878581.issue15785@psf.upfronthosting.co.za> Message-ID: <1346101346.16.0.459157872437.issue15785@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +georg.brandl, loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 23:13:43 2012 From: report at bugs.python.org (Georg Brandl) Date: Mon, 27 Aug 2012 21:13:43 +0000 Subject: [issue15785] curses.get_wch() returns keypad codes incorrectly In-Reply-To: <1345975778.97.0.705241878581.issue15785@psf.upfronthosting.co.za> Message-ID: <1346102023.89.0.881242134255.issue15785@psf.upfronthosting.co.za> Georg Brandl added the comment: Please get a review from another developer before I consider this for rc2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 23:15:59 2012 From: report at bugs.python.org (Georg Brandl) Date: Mon, 27 Aug 2012 21:15:59 +0000 Subject: [issue15781] test_threaded_import fails with -j4 In-Reply-To: <1345883620.41.0.296577026972.issue15781@psf.upfronthosting.co.za> Message-ID: <1346102159.17.0.976972939276.issue15781@psf.upfronthosting.co.za> Georg Brandl added the comment: Looks good to me. Please commit to default and I'll cherry-pick to rc2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 23:17:20 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Aug 2012 21:17:20 +0000 Subject: [issue15793] Stack corruption in ssl.RAND_egd() Message-ID: <1346102240.18.0.678395188074.issue15793@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Here is a patch that fixes stack corruption in ssl.RAND_egd(). ---------- components: Library (Lib) files: ssl_RAND_egd.patch keywords: patch messages: 169221 nosy: haypo, storchaka priority: normal severity: normal status: open title: Stack corruption in ssl.RAND_egd() type: crash versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file27020/ssl_RAND_egd.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 23:20:50 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Mon, 27 Aug 2012 21:20:50 +0000 Subject: [issue15792] Fix compiler options for x64 builds on Windows In-Reply-To: <1346077051.29.0.85020459134.issue15792@psf.upfronthosting.co.za> Message-ID: Jeremy Kloth added the comment: I did forgot t mention that this change also silences a compiler warning: cl : Command line warning D9025: overriding '/GS' with '/GS-' The /USECL:xxx option does not provoke a warning is it is being evaluated as '/U "SECL:xxx"' (undefine macro) ---------- nosy: +jeremy.kloth _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 23:27:33 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 27 Aug 2012 21:27:33 +0000 Subject: [issue15781] test_threaded_import fails with -j4 In-Reply-To: <1345883620.41.0.296577026972.issue15781@psf.upfronthosting.co.za> Message-ID: <1346102853.21.0.267470374026.issue15781@psf.upfronthosting.co.za> Antoine Pitrou added the comment: If possible I would like to wait for Stefan's confirmation that it fixes the failures for him. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 23:29:09 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 27 Aug 2012 21:29:09 +0000 Subject: [issue15784] OSError.__str__() should distinguish between errno and winerror In-Reply-To: <1345920277.5.0.279969365859.issue15784@psf.upfronthosting.co.za> Message-ID: <1346102949.62.0.493184771058.issue15784@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 23:30:11 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 27 Aug 2012 21:30:11 +0000 Subject: [issue15784] OSError.__str__() should distinguish between errno and winerror In-Reply-To: <1345920277.5.0.279969365859.issue15784@psf.upfronthosting.co.za> Message-ID: <1346103011.19.0.401914366052.issue15784@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I originally kept it that way to minimize disruption with 3.2, but I agree it's a welcome change. As for acceptance in 3.3, Georg will have to decide. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 23:30:53 2012 From: report at bugs.python.org (Georg Brandl) Date: Mon, 27 Aug 2012 21:30:53 +0000 Subject: [issue15781] test_threaded_import fails with -j4 In-Reply-To: <1345883620.41.0.296577026972.issue15781@psf.upfronthosting.co.za> Message-ID: <1346103053.93.0.259845210315.issue15781@psf.upfronthosting.co.za> Georg Brandl added the comment: Sure. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 27 23:36:49 2012 From: report at bugs.python.org (Georg Brandl) Date: Mon, 27 Aug 2012 21:36:49 +0000 Subject: [issue15784] OSError.__str__() should distinguish between errno and winerror In-Reply-To: <1345920277.5.0.279969365859.issue15784@psf.upfronthosting.co.za> Message-ID: <1346103409.35.0.988823315564.issue15784@psf.upfronthosting.co.za> Georg Brandl added the comment: Uh, currently it's "Errno" or "Error", so there is a way to tell which. I'll leave to Antoine to decide what to do here; it's not like changing it a big deal. "WinError" looks kind of ugly to me though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 00:13:54 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 27 Aug 2012 22:13:54 +0000 Subject: [issue15784] OSError.__str__() should distinguish between errno and winerror In-Reply-To: <1345920277.5.0.279969365859.issue15784@psf.upfronthosting.co.za> Message-ID: <1346105634.99.0.730951271939.issue15784@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Well, "Error" and "Errno" are rather hard to distinguish, and the difference isn't obvious either, so Richard's patch is a good improvement IMHO. ---------- assignee: -> sbt components: +Interpreter Core versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 00:18:38 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 27 Aug 2012 22:18:38 +0000 Subject: [issue15793] Stack corruption in ssl.RAND_egd() In-Reply-To: <1346102240.18.0.678395188074.issue15793@psf.upfronthosting.co.za> Message-ID: <1346105918.4.0.845802484088.issue15793@psf.upfronthosting.co.za> Antoine Pitrou added the comment: You should add a test (e.g. that TypeError is raised when a second argument is passed). ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 00:21:36 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 27 Aug 2012 22:21:36 +0000 Subject: [issue15781] test_threaded_import fails with -j4 In-Reply-To: <1346102853.21.0.267470374026.issue15781@psf.upfronthosting.co.za> Message-ID: <20120827222137.GA11246@sleipnir.bytereef.org> Stefan Krah added the comment: Nice, on the finicky i7 machine test_threaded_import is fixed. I'm getting another error in test_importlib, both with and without the patch. I can open another issue for that if you think it's completely unrelated: $ ./python -m test -uall -F test_importlib [ 1] test_importlib test test_importlib failed -- Traceback (most recent call last): File "/home/stefan/hg/cpython/Lib/test/test_importlib/test_locks.py", line 80, in test_deadlock self.assertEqual(results.count((True, False)), 1) AssertionError: 2 != 1 1 test failed: test_importlib ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 00:26:29 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 27 Aug 2012 22:26:29 +0000 Subject: [issue15781] test_threaded_import fails with -j4 In-Reply-To: <20120827222137.GA11246@sleipnir.bytereef.org> Message-ID: <1346106184.3369.0.camel@localhost.localdomain> Antoine Pitrou added the comment: > I'm getting another error in test_importlib, both with and without > the patch. I can open another issue for that if you think it's > completely unrelated: Please do. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 00:29:39 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 27 Aug 2012 22:29:39 +0000 Subject: [issue15781] test_threaded_import fails with -j4 In-Reply-To: <1345883620.41.0.296577026972.issue15781@psf.upfronthosting.co.za> Message-ID: <3X5SSy0x24zQ1L@mail.python.org> Roundup Robot added the comment: New changeset 7fa6336e9864 by Antoine Pitrou in branch 'default': Issue #15781: Fix two small race conditions in import's module locking. http://hg.python.org/cpython/rev/7fa6336e9864 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 00:35:01 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 27 Aug 2012 22:35:01 +0000 Subject: [issue15794] test_importlib: test_locks failure Message-ID: <1346106901.9.0.610184889675.issue15794@psf.upfronthosting.co.za> New submission from Stefan Krah: On the obstinate i7 machine (see #15781), test_importlib fails sporadically (after 10 repetitions or so). $ ./python -m test -uall -F test_importlib [ 1] test_importlib test test_importlib failed -- Traceback (most recent call last): File "/home/stefan/hg/cpython/Lib/test/test_importlib/test_locks.py", line 80, in test_deadlock self.assertEqual(results.count((True, False)), 1) AssertionError: 2 != 1 1 test failed: test_importlib ---------- components: Tests messages: 169232 nosy: brett.cannon, christian.heimes, eric.snow, georg.brandl, haypo, ncoghlan, pitrou, skrah priority: normal severity: normal status: open title: test_importlib: test_locks failure type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 00:36:04 2012 From: report at bugs.python.org (Alexey Boriskin) Date: Mon, 27 Aug 2012 22:36:04 +0000 Subject: [issue15795] Zipfile.extractall does not preserve file permissions Message-ID: <1346106964.12.0.723201722432.issue15795@psf.upfronthosting.co.za> New submission from Alexey Boriskin: Zipfile._extract_member does not preserve file permissions while extracting it. As may be seen at link[1], raw open() is used and no os.chmod() applied after that, therefore any permission data stored in zipfile is dropped and file is created with default permission depending on current user's umask. [1] http://hg.python.org/cpython/file/52159aa5d401/Lib/zipfile.py#l1251 ---------- components: Library (Lib) messages: 169233 nosy: uruz priority: normal severity: normal status: open title: Zipfile.extractall does not preserve file permissions type: behavior versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 00:42:19 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 27 Aug 2012 22:42:19 +0000 Subject: [issue15789] mention shell-like parts of the std lib in the subprocess docs In-Reply-To: <1346052242.66.0.254880477781.issue15789@psf.upfronthosting.co.za> Message-ID: <1346107339.61.0.0943990012128.issue15789@psf.upfronthosting.co.za> ?ric Araujo added the comment: Thanks, LGTM. Maybe there?s a section about walking files in the os module doc that you could also link to? Also shutil. ---------- nosy: +eric.araujo versions: +Python 3.2 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 00:43:57 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Aug 2012 22:43:57 +0000 Subject: [issue15796] Fix readline() docstrings Message-ID: <1346107437.01.0.760856446484.issue15796@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Here is a patch that escapes '\n' in readline() docstrings. ---------- assignee: docs at python components: Documentation files: escape_nl.patch keywords: patch messages: 169235 nosy: docs at python, storchaka priority: normal severity: normal status: open title: Fix readline() docstrings versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file27021/escape_nl.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 00:44:12 2012 From: report at bugs.python.org (Ned Deily) Date: Mon, 27 Aug 2012 22:44:12 +0000 Subject: [issue15533] subprocess.Popen(cwd) documentation In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za> Message-ID: <1346107452.08.0.028306660407.issue15533@psf.upfronthosting.co.za> Ned Deily added the comment: Because tests should be runnable from installed Pythons (including binary -only installations), tests should not assume that a Python source directory is available nor make any assumptions about the location of the Python executable itself. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 00:44:28 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Aug 2012 22:44:28 +0000 Subject: [issue15796] Fix readline() docstrings In-Reply-To: <1346107437.01.0.760856446484.issue15796@psf.upfronthosting.co.za> Message-ID: <1346107468.23.0.441600722724.issue15796@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file27022/escape_nl-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 00:44:47 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Aug 2012 22:44:47 +0000 Subject: [issue15793] Stack corruption in ssl.RAND_egd() In-Reply-To: <1346102240.18.0.678395188074.issue15793@psf.upfronthosting.co.za> Message-ID: <1346107487.97.0.357873192116.issue15793@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Patch updated with tests. ---------- Added file: http://bugs.python.org/file27023/ssl_RAND_egd-3.3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 00:45:14 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Aug 2012 22:45:14 +0000 Subject: [issue15793] Stack corruption in ssl.RAND_egd() In-Reply-To: <1346102240.18.0.678395188074.issue15793@psf.upfronthosting.co.za> Message-ID: <1346107514.44.0.954885053363.issue15793@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file27024/ssl_RAND_egd-3.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 00:45:49 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Aug 2012 22:45:49 +0000 Subject: [issue15793] Stack corruption in ssl.RAND_egd() In-Reply-To: <1346102240.18.0.678395188074.issue15793@psf.upfronthosting.co.za> Message-ID: <1346107549.77.0.638864263092.issue15793@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file27020/ssl_RAND_egd.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 00:47:19 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 27 Aug 2012 22:47:19 +0000 Subject: [issue15794] test_importlib: test_locks failure In-Reply-To: <1346106901.9.0.610184889675.issue15794@psf.upfronthosting.co.za> Message-ID: <1346107639.09.0.637259789601.issue15794@psf.upfronthosting.co.za> Stefan Krah added the comment: Also reproduced on Ubuntu Lucid/Core 2 Duo with a very low switch interval and -j4. It takes more repetitions than on the i7: $ ./python -m test -uall -F -j4 test_importlib [...] [224] test_importlib [225] test_importlib [226/1] test_importlib test test_importlib failed -- Traceback (most recent call last): File "/home/stefan/pydev/cpython/Lib/test/test_importlib/test_locks.py", line 80, in test_deadlock self.assertEqual(results.count((True, False)), 1) AssertionError: 2 != 1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 00:52:01 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 27 Aug 2012 22:52:01 +0000 Subject: [issue15793] Stack corruption in ssl.RAND_egd() In-Reply-To: <1346102240.18.0.678395188074.issue15793@psf.upfronthosting.co.za> Message-ID: <1346107921.24.0.502732478897.issue15793@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 01:53:51 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 27 Aug 2012 23:53:51 +0000 Subject: [issue15790] Python 3.3.0rc1 release notes claims PEP-405 support, yet pysetup is not in the package (needs more usage documentation, to get pip working) In-Reply-To: <1346067697.02.0.646215299942.issue15790@psf.upfronthosting.co.za> Message-ID: <1346111631.37.0.72287214532.issue15790@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 02:05:20 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 28 Aug 2012 00:05:20 +0000 Subject: [issue15794] test_importlib: test_locks failure In-Reply-To: <1346106901.9.0.610184889675.issue15794@psf.upfronthosting.co.za> Message-ID: <1346112320.56.0.403160993805.issue15794@psf.upfronthosting.co.za> Antoine Pitrou added the comment: After a bit of investigation, it turns out the test is probably too strict. The deadlock avoidance logic in importlib._bootstrap is indeed conservative: if you take a look at _ModuleLock.acquire(), _blocking_on[tid] is set even while other threads may run, because the internal lock is not always taken. Therefore, if there's a potential deadlock between several threads, there are situations where DeadlockError will be raised in two threads, not only one. (IMHO it would complicate the code too much to make deadlock avoidance less conservative, without bringing anything in terms of additional functionality) See attached patch. ---------- keywords: +patch Added file: http://bugs.python.org/file27025/relax_deadlock_test.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 02:28:49 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 28 Aug 2012 00:28:49 +0000 Subject: [issue15533] subprocess.Popen(cwd) documentation In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za> Message-ID: <1346113729.33.0.677727156875.issue15533@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Here is a new patch that makes no assumptions about the contents of the directory containing sys.executable. ---------- Added file: http://bugs.python.org/file27026/issue-15533-3-default.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 02:33:37 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 28 Aug 2012 00:33:37 +0000 Subject: [issue15784] OSError.__str__() should distinguish between errno and winerror In-Reply-To: <1345920277.5.0.279969365859.issue15784@psf.upfronthosting.co.za> Message-ID: <1346114017.72.0.0135065458519.issue15784@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > Well, "Error" and "Errno" are rather hard to distinguish Embarrassingly, I did not even notice the was a difference. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 02:33:47 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 28 Aug 2012 00:33:47 +0000 Subject: [issue15795] Zipfile.extractall does not preserve file permissions In-Reply-To: <1346106964.12.0.723201722432.issue15795@psf.upfronthosting.co.za> Message-ID: <1346114027.27.0.55240261536.issue15795@psf.upfronthosting.co.za> R. David Murray added the comment: Does this have any relationship to issue 3394? From the discussion on that issue it sounds like zipfile is doing things with external_attributes if it is set. But I don't know much about zipfile internals. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 03:12:16 2012 From: report at bugs.python.org (Chris Rebert) Date: Tue, 28 Aug 2012 01:12:16 +0000 Subject: [issue9650] format codes in time.strptime docstrings In-Reply-To: <1282319380.5.0.724924373031.issue9650@psf.upfronthosting.co.za> Message-ID: <1346116336.56.0.846522642877.issue9650@psf.upfronthosting.co.za> Chris Rebert added the comment: +1 on including am/pm-related codes. Blame us backwards, non-metric Americans. Sounds GTM otherwise. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 03:17:32 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 28 Aug 2012 01:17:32 +0000 Subject: [issue14649] doctest.DocTestSuite error misleading when module has no docstrings In-Reply-To: <1335192861.9.0.305748973415.issue14649@psf.upfronthosting.co.za> Message-ID: <1346116652.49.0.527618124891.issue14649@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Updating the patch after discussing with David on IRC. The two new files are now added to Lib/test instead of to a subdirectory of Lib/test. Moving the doctest files to a subdirectory can be discussed and possibly addressed as part of a separate issue. ---------- Added file: http://bugs.python.org/file27027/issue-14649-5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 03:45:36 2012 From: report at bugs.python.org (Colin Su) Date: Tue, 28 Aug 2012 01:45:36 +0000 Subject: [issue15716] Ability to specify the PYTHONPATH via a command line flag In-Reply-To: <1345164027.44.0.397805734201.issue15716@psf.upfronthosting.co.za> Message-ID: <1346118336.7.0.0147367201155.issue15716@psf.upfronthosting.co.za> Changes by Colin Su : ---------- nosy: +littleq0903 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 03:54:13 2012 From: report at bugs.python.org (Colin Su) Date: Tue, 28 Aug 2012 01:54:13 +0000 Subject: [issue15716] Ability to specify the PYTHONPATH via a command line flag In-Reply-To: <1345164027.44.0.397805734201.issue15716@psf.upfronthosting.co.za> Message-ID: <1346118853.89.0.412551353731.issue15716@psf.upfronthosting.co.za> Colin Su added the comment: Could anyone provide some properly command line usage for this issue? ex. python -P "path_1:path_2:path_3" I think this point need to be discussed :D ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 03:54:53 2012 From: report at bugs.python.org (Colin Su) Date: Tue, 28 Aug 2012 01:54:53 +0000 Subject: [issue15716] Ability to specify the PYTHONPATH via a command line flag In-Reply-To: <1345164027.44.0.397805734201.issue15716@psf.upfronthosting.co.za> Message-ID: <1346118893.3.0.0112039651148.issue15716@psf.upfronthosting.co.za> Colin Su added the comment: s/properly/proper (typo) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 04:03:15 2012 From: report at bugs.python.org (Colin Su) Date: Tue, 28 Aug 2012 02:03:15 +0000 Subject: [issue15716] Ability to specify the PYTHONPATH via a command line flag In-Reply-To: <1345164027.44.0.397805734201.issue15716@psf.upfronthosting.co.za> Message-ID: <1346119395.17.0.849481641324.issue15716@psf.upfronthosting.co.za> Colin Su added the comment: started working on it :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 05:23:42 2012 From: report at bugs.python.org (Adam Simpkins) Date: Tue, 28 Aug 2012 03:23:42 +0000 Subject: [issue15785] curses.get_wch() returns keypad codes incorrectly In-Reply-To: <1345975778.97.0.705241878581.issue15785@psf.upfronthosting.co.za> Message-ID: <1346124222.32.0.617662222379.issue15785@psf.upfronthosting.co.za> Adam Simpkins added the comment: > + Get a wide character as (is_key_code, key). *is_key_code* is True for > + function keys, keypad keys and so, in this case, *key* is a multibyte string > + containing the key name. Otherwise, *key* is a single character > + corresponding to the key. The curses module already exposes the integer KEY_* constants. I think the API would be easier to use if it simply returned the integer keycode constant rather than returning the human-readable name returned by keyname(). I suspect most callers will want to compare the keycode against one of these KEY_* constants to see what type of key was pressed so they can take action on specific keys. Comparing the return value against one of the curses.KEY_* constants seems easier than having to compare it to the result of curses.keyname(curses.KEY_*) The curses module also already exposes the keyname() function if callers do want to get the human-readable string for an integer keycode. If the function returned either a single-character unicode string or an integer keycode, this would also make it possible to completely drop the is_key_code part of the return value. (Callers could simply check the type of the return value to see if it is a keycode.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 06:09:44 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 28 Aug 2012 04:09:44 +0000 Subject: [issue15789] mention shell-like parts of the std lib in the subprocess docs In-Reply-To: <1346052242.66.0.254880477781.issue15789@psf.upfronthosting.co.za> Message-ID: <1346126984.7.0.968353432858.issue15789@psf.upfronthosting.co.za> Chris Jerdonek added the comment: This is a nit, but can you adhere to an 80-character line length? Much (but not all) of the documentation does. ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 06:47:12 2012 From: report at bugs.python.org (Eric Snow) Date: Tue, 28 Aug 2012 04:47:12 +0000 Subject: [issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite In-Reply-To: <1242857063.47.0.919073638283.issue6074@psf.upfronthosting.co.za> Message-ID: <1346129232.59.0.165170450395.issue6074@psf.upfronthosting.co.za> Eric Snow added the comment: Here's a patch for 3.3 with a test. Though, I'm still setting up my windows box for building Python, I wanted to get this patch up. On its own the test should fail on Windows. In that case, it should be backport-able. If no one has a chance to verify the test on windows (or the fix) before I get everything set up, I'll do it. ---------- Added file: http://bugs.python.org/file27028/issue6074_3.3_eric.snow.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 07:51:08 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 28 Aug 2012 05:51:08 +0000 Subject: [issue15136] Decimal accepting Fraction In-Reply-To: <1340365912.14.0.935631231431.issue15136@psf.upfronthosting.co.za> Message-ID: <1346133068.79.0.682940440717.issue15136@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Thanks Nick. I'll go ahead and close this one, leaving the Decimal module only with lossless coercions that do not depend on the decimal context (this matches the underlying design of the decimal module which treats all numbers as exact, and only applying to the result of an arithmetic operation). If needed, a new issue can be opened for a format specifier for the Fraction type. It seems that we're all in agreement that that would be useful for the fractions module. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 07:59:28 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 28 Aug 2012 05:59:28 +0000 Subject: [issue14783] Update int() docstring from manual In-Reply-To: <1336751413.58.0.519130225761.issue14783@psf.upfronthosting.co.za> Message-ID: <1346133568.85.0.825348594691.issue14783@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The 3.3 version has the virtue of being accurate and the vice of being confusing. In a way, it has made the docs worse for the average user of common cases. Is there a way to stack the alternative signatures rather than mush the various used into a single pile of mush? int(x=0) --> integer coercion int(str, base=10) --> integer converted from string in a given base ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 08:13:11 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 28 Aug 2012 06:13:11 +0000 Subject: [issue15783] decimal.localcontext(None) fails when using the C accelerator module In-Reply-To: <1345904683.65.0.863127291798.issue15783@psf.upfronthosting.co.za> Message-ID: <1346134391.79.0.896505715927.issue15783@psf.upfronthosting.co.za> Nick Coghlan added the comment: Note that it's only the 3.2 interactive help that specifies "ctx=None", and it's almost certainly lifting that directly from the Python implementation. The C implementation is definitely in compliance with the prose docs, which give the signature as localcontext([c]) and say "If no context is specified, a copy of the current context is used" without indicating whether passing in None explicitly is supposed to count as not specifying a context. However, the specific problem that prompted this report is that you used to be able to write code like: def my_decimal_func(arg1, arg2, context=None): with decimal.localcontext(context): # perform decimal operations on arg1 and arg2 but with the C implementation, such code will break. You have to instead write something less idiomatic like: def my_decimal_func(arg1, arg2, *context): with decimal.localcontext(*context): # perform decimal operations on arg1 and arg2 Any third party Decimal manipulating function that accepts an optional context and passes it down to the standard Decimal API will be confronted with the same problem in 3.3: passing None as the context no longer means the same thing as omitting the context argument entirely. We can either handle this as a documentation issue (recommending the *args based idiom above as an alternative to passing an explicit None), or else change the C implementation to accept context=None as equivalent to omitting the context argument entirely. I'm inclined towards the latter, simply due to the backwards compatibility breach: explicitly calling localcontext(None) would indeed be silly, but calling localcontext(context), where context comes from a parameter with a default value of None, is perfectly normal Python code. Idiomatic code that worked correctly in the previous Python version is a reasonably strong argument in favour of retaining the feature. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 08:24:38 2012 From: report at bugs.python.org (Martin Burger) Date: Tue, 28 Aug 2012 06:24: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: <1346135078.43.0.915685948333.issue9694@psf.upfronthosting.co.za> Changes by Martin Burger : ---------- nosy: +mburger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 08:45:48 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Tue, 28 Aug 2012 06:45:48 +0000 Subject: [issue14880] csv.reader and .writer use wrong kwargs notation in 2.7 docs In-Reply-To: <1337670456.12.0.0273828432105.issue14880@psf.upfronthosting.co.za> Message-ID: <1346136348.33.0.706531396486.issue14880@psf.upfronthosting.co.za> Hynek Schlawack added the comment: What does bother you? Both sigs look like in py3 if I'm looking correctly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 10:17:05 2012 From: report at bugs.python.org (=?utf-8?q?Nemeskey_D=C3=A1vid?=) Date: Tue, 28 Aug 2012 08:17:05 +0000 Subject: [issue15775] Add StopParser() to expat In-Reply-To: <1345796297.89.0.127411549702.issue15775@psf.upfronthosting.co.za> Message-ID: <1346141825.22.0.348340789423.issue15775@psf.upfronthosting.co.za> Nemeskey D?vid added the comment: OK, then this issue has a "bug" part, too: it is not mentioned in the documentation that exceptions from the handler methods propagate through the Parse() method. I guess the parser can be then stopped in this way too, but it is a dirty method as opposed to calling StopParser(). To answer your question, there are several situations where StopParser() could come in handy. For instance, the XML file might contain records (such as the output of a search engine), from which we only need the first n. Another example would be that reading through the file we realize halfway that e.g. it does not contain the information we need, contains wrong information, etc. so we want to skip the rest of it. Since the file might be huge and since XML parsing can in now way be considered fast, being able to stop the parsing in a clear way would spare the superfluous and possible lengthy computation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 10:59:52 2012 From: report at bugs.python.org (Chris Rebert) Date: Tue, 28 Aug 2012 08:59:52 +0000 Subject: [issue15789] mention shell-like parts of the std lib in the subprocess docs In-Reply-To: <1346052242.66.0.254880477781.issue15789@psf.upfronthosting.co.za> Message-ID: <1346144392.64.0.413916457461.issue15789@psf.upfronthosting.co.za> Chris Rebert added the comment: Revised patch in response to comments. ---------- Added file: http://bugs.python.org/file27029/subprocess.rst.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 11:00:50 2012 From: report at bugs.python.org (Stefan Krah) Date: Tue, 28 Aug 2012 09:00:50 +0000 Subject: [issue15794] test_importlib: test_locks failure In-Reply-To: <1346112320.56.0.403160993805.issue15794@psf.upfronthosting.co.za> Message-ID: <20120828090050.GA15277@sleipnir.bytereef.org> Stefan Krah added the comment: The patch works fine here (as expected). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 11:33:16 2012 From: report at bugs.python.org (David Lam) Date: Tue, 28 Aug 2012 09:33:16 +0000 Subject: [issue11176] give more meaningful argument names in argparse documentation In-Reply-To: <1297352937.46.0.470038569364.issue11176@psf.upfronthosting.co.za> Message-ID: <1346146396.08.0.812388575496.issue11176@psf.upfronthosting.co.za> David Lam added the comment: here's a patch that covers all but one of the foo/bar/baz examples it also has fixes for the sample code near the beginning from the review Ezio did the one example I didn't do was the "Arguments containing -" part. I guess it felt like changing the names in that example would distract from what it was trying to illustrate there Anyways, I tried to proofread it so hopefully it reads okay, enjoy enjoy ^^ ---------- Added file: http://bugs.python.org/file27030/issue11176.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 11:33:25 2012 From: report at bugs.python.org (Mike Hoy) Date: Tue, 28 Aug 2012 09:33:25 +0000 Subject: [issue1185124] pydoc doesn't find all module doc strings Message-ID: <1346146405.83.0.181246659508.issue1185124@psf.upfronthosting.co.za> Changes by Mike Hoy : ---------- nosy: +mikehoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 11:36:43 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 28 Aug 2012 09:36:43 +0000 Subject: [issue11964] Undocumented change to indent param of json.dump in 3.2 In-Reply-To: <1304178435.78.0.522459822796.issue11964@psf.upfronthosting.co.za> Message-ID: <3X5lGd601TzPwn@mail.python.org> Roundup Robot added the comment: New changeset 5bff555168ab by Petri Lehtinen in branch '3.2': #11964: Document a change in v3.2 to the json indent parameter http://hg.python.org/cpython/rev/5bff555168ab New changeset 0fb511659ef4 by Petri Lehtinen in branch 'default': #11964: Document a change in v3.2 to the json indent parameter http://hg.python.org/cpython/rev/0fb511659ef4 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 11:38:04 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Tue, 28 Aug 2012 09:38:04 +0000 Subject: [issue11964] Undocumented change to indent param of json.dump in 3.2 In-Reply-To: <1304178435.78.0.522459822796.issue11964@psf.upfronthosting.co.za> Message-ID: <1346146684.7.0.480140495151.issue11964@psf.upfronthosting.co.za> Petri Lehtinen added the comment: Fixed, thanks. ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 11:40:28 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Tue, 28 Aug 2012 09:40:28 +0000 Subject: [issue14880] csv.reader and .writer use wrong kwargs notation in 2.7 docs In-Reply-To: <1337670456.12.0.0273828432105.issue14880@psf.upfronthosting.co.za> Message-ID: <1346146828.58.0.654099524544.issue14880@psf.upfronthosting.co.za> Petri Lehtinen added the comment: Well, I wasn't sure about [optional] params before **kwargs. But if that's ok, then I think the patch is good. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 11:51:12 2012 From: report at bugs.python.org (B Maqueira) Date: Tue, 28 Aug 2012 09:51:12 +0000 Subject: [issue15797] bdist_msi does not pass -install/remove flags to install_script Message-ID: <1346147472.01.0.0635028414042.issue15797@psf.upfronthosting.co.za> New submission from B Maqueira: When building an msi package using the --install-script=xx.py, the script "xx.py" is called on msi package install/removal as expected. However the cmd line flags -install/-remove are not passed to the script making it hard to write "step specific" code. I experienced this under python 2.7.3 (winXP / distutils 2.7.3, setuptools 0.6c11). I attach a patch for bdist_msi.py for your consideration. Kind regards, Braudel ---------- assignee: eric.araujo components: Distutils files: patch.diff keywords: patch messages: 169262 nosy: braudel, eric.araujo, tarek priority: normal severity: normal status: open title: bdist_msi does not pass -install/remove flags to install_script type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file27031/patch.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 12:03:59 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Tue, 28 Aug 2012 10:03:59 +0000 Subject: [issue11489] json.dumps not parsable by json.loads (on Linux only) In-Reply-To: <1300058240.59.0.513243746739.issue11489@psf.upfronthosting.co.za> Message-ID: <1346148239.32.0.993702148075.issue11489@psf.upfronthosting.co.za> Petri Lehtinen added the comment: Bear in mind that Douglas Crockford thinks a JSON document is valid even if it contains unpaired surrogates: http://tech.groups.yahoo.com/group/json/message/1603 http://tech.groups.yahoo.com/group/json/message/1583 It's Unicode that considers unpaired surrogates invalid, not UTF-8 by itself. ---------- nosy: +petri.lehtinen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 12:06:02 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Tue, 28 Aug 2012 10:06:02 +0000 Subject: [issue9668] strings in json.dump in '' instead of "" In-Reply-To: <1282652734.85.0.734132617851.issue9668@psf.upfronthosting.co.za> Message-ID: <1346148362.99.0.411697695782.issue9668@psf.upfronthosting.co.za> Petri Lehtinen added the comment: No activity in 2 years, closing. ---------- nosy: +petri.lehtinen status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 12:19:59 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Tue, 28 Aug 2012 10:19:59 +0000 Subject: [issue14880] csv.reader and .writer use wrong kwargs notation in 2.7 docs In-Reply-To: <1337670456.12.0.0273828432105.issue14880@psf.upfronthosting.co.za> Message-ID: <1346149199.24.0.995634431204.issue14880@psf.upfronthosting.co.za> Hynek Schlawack added the comment: It seems correct like that: static PyObject * csv_register_dialect(PyObject *module, PyObject *args, PyObject *kwargs) { PyObject *name_obj, *dialect_obj = NULL; PyObject *dialect; if (!PyArg_UnpackTuple(args, "", 1, 2, &name_obj, &dialect_obj)) return NULL; Therefore going to commit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 12:28:42 2012 From: report at bugs.python.org (Stefan Krah) Date: Tue, 28 Aug 2012 10:28:42 +0000 Subject: [issue15783] decimal.localcontext(None) fails when using the C accelerator module In-Reply-To: <1345904683.65.0.863127291798.issue15783@psf.upfronthosting.co.za> Message-ID: <1346149722.44.0.194261819778.issue15783@psf.upfronthosting.co.za> Stefan Krah added the comment: Nick Coghlan wrote: > Any third party Decimal manipulating function that accepts an > optional context and passes it down to the standard Decimal API > will be confronted with the same problem in 3.3: passing None > as the context no longer means the same thing as omitting the > context argument entirely. I agree, but for me the issue is: What is the standard API? If you look at the Context methods in decimal.py, you see this pattern: def add(self, a, b): ... r = a.__add__(b, context=self) So I think it's reasonably safe to say that all Decimal methods only take a context=None argument because it happens to be a convenient way of implementing the Context methods. With that reasoning, most of the list in msg169144 would be eliminated already. I sort of regret that the Decimal methods of the C version take a context argument at all, but the arguments are documented. Now to localcontext(ctx=None). Yes, code might exist that does the following: def f(a, b, context=None): with localcontext(context): return a / b It is, however, a strange function: If I explicitly pass a context to a function, I'd expect that it is also used for recording any status that accumulates in the function (or that the function actually *can* accumulate status at all). If I'm only interested in the precision, I'd write: def f(a, b, prec=None): with localcontext() as c: c.prec = 9 if prec is None else prec return Decimal(a) / b [This is along the lines of Raymond's original suggestion in #15136.] But there are other examples of unexpected behavior, such as Decimal.to_eng_string(context) taking a context purely to determine the value of context.capitals, i.e. no status flags can possibly be set. Here I'd also prefer: to_eng_string(capitals=1) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 12:35:29 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 28 Aug 2012 10:35:29 +0000 Subject: [issue14880] csv.reader and .writer use wrong kwargs notation in 2.7 docs In-Reply-To: <1337670456.12.0.0273828432105.issue14880@psf.upfronthosting.co.za> Message-ID: <3X5mZS0cD1zPyW@mail.python.org> Roundup Robot added the comment: New changeset dc080e19f7aa by Hynek Schlawack in branch '2.7': #14880: Fix kwargs notation in csv.reader, .writer & .register_dialect http://hg.python.org/cpython/rev/dc080e19f7aa ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 12:36:30 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Tue, 28 Aug 2012 10:36:30 +0000 Subject: [issue14880] csv.reader and .writer use wrong kwargs notation in 2.7 docs In-Reply-To: <1337670456.12.0.0273828432105.issue14880@psf.upfronthosting.co.za> Message-ID: <1346150190.05.0.508044828823.issue14880@psf.upfronthosting.co.za> Hynek Schlawack added the comment: Thank you for your contribution Chris! ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 12:40:02 2012 From: report at bugs.python.org (Samuel John) Date: Tue, 28 Aug 2012 10:40:02 +0000 Subject: [issue13405] Add DTrace probes In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za> Message-ID: <1346150402.94.0.639318051844.issue13405@psf.upfronthosting.co.za> Samuel John added the comment: I did your test. Thank you! You are absolutely right, it seems, dtrace does not honor "CPP" or "PATH" or any other flags and bluntly looks in a hard-coded location. It's not up to you to patch that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 12:44:39 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Tue, 28 Aug 2012 10:44:39 +0000 Subject: [issue13769] json.dump(ensure_ascii=False) return str instead of unicode In-Reply-To: <1326300079.82.0.279410736545.issue13769@psf.upfronthosting.co.za> Message-ID: <1346150679.36.0.212256139666.issue13769@psf.upfronthosting.co.za> Petri Lehtinen added the comment: It may also be unicode if the encoding parameter is used even if there are no unicode objects in the input. >>> json.dumps([u'?'.encode('iso-8859-9')], encoding='iso-8859-9', ensure_ascii=False) u'["\u015e"]' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 12:51:26 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Tue, 28 Aug 2012 10:51:26 +0000 Subject: [issue14042] json.dumps() documentation is slightly incorrect. In-Reply-To: <1329494870.59.0.571991231564.issue14042@psf.upfronthosting.co.za> Message-ID: <1346151086.25.0.561120126282.issue14042@psf.upfronthosting.co.za> Petri Lehtinen added the comment: This is a documentation bug for 2.7. Setting as duplicate of #13769. ---------- nosy: +petri.lehtinen resolution: -> duplicate stage: needs patch -> committed/rejected status: open -> closed superseder: -> json.dump(ensure_ascii=False) return str instead of unicode versions: -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 12:54:14 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 28 Aug 2012 10:54:14 +0000 Subject: [issue15785] curses.get_wch() returns keypad codes incorrectly In-Reply-To: <1346124222.32.0.617662222379.issue15785@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > If the function returned either a single-character unicode string or an integer > keycode, this would also make it possible to completely drop the is_key_code > part of the return value. (Callers could simply check the type of the return > value to see if it is a keycode.) I tried to mimic the getkey() function, but I like your idea. In many cases you don't have to check explicitly the type. Example: if key == "q": quit(), or if key == curses.KEY_UP: move(1). It works also if the key is used as a key of a dictionary: key => callback. And yes, keyname() can be used to mimic manually getkey() behaviour. It does not solve unget_wch() issue, but I propose to drop the unget_wch()+get_wch() test on non-ASCII keys because it looks like a bug in the curses library. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 13:07:54 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Tue, 28 Aug 2012 11:07:54 +0000 Subject: [issue13769] json.dump(ensure_ascii=False) return str instead of unicode In-Reply-To: <1326300079.82.0.279410736545.issue13769@psf.upfronthosting.co.za> Message-ID: <1346152074.12.0.984090554907.issue13769@psf.upfronthosting.co.za> Petri Lehtinen added the comment: Attached a patch for 2.7 that updates docs and docstrings. ---------- keywords: +needs review, patch stage: needs patch -> patch review Added file: http://bugs.python.org/file27032/issue13769.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 13:08:39 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Tue, 28 Aug 2012 11:08:39 +0000 Subject: [issue13769] json.dump(ensure_ascii=False) return str instead of unicode In-Reply-To: <1326300079.82.0.279410736545.issue13769@psf.upfronthosting.co.za> Message-ID: <1346152119.82.0.432808061329.issue13769@psf.upfronthosting.co.za> Changes by Petri Lehtinen : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 14:03:54 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 28 Aug 2012 12:03:54 +0000 Subject: [issue1185124] pydoc doesn't find all module doc strings Message-ID: <1346155434.09.0.417694066641.issue1185124@psf.upfronthosting.co.za> Nick Coghlan added the comment: The standard library has moved on quite a bit since this patch was written... 1. source_synopsis() should be using the tokeniser module when reading the docstring. The current implementation is broken in more ways than just those noted here (e.g. it completely ignores the declared encoding) (The reason for not using full compilation is that you would then have to either *run* the compiled code or else compile to the AST and interrogate that, which is technically implementation dependent) 2. For 3.3+, synopsis should be using importlib to get the source code rather than assuming filesystem imports. That's probably better handled in a separate issue, though. ---------- assignee: ping -> nosy: +ncoghlan versions: +Python 3.3 -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 14:10:36 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 28 Aug 2012 12:10:36 +0000 Subject: [issue1185124] pydoc doesn't find all module doc strings Message-ID: <1346155836.97.0.348663901691.issue1185124@psf.upfronthosting.co.za> Nick Coghlan added the comment: Oops, I somehow ended up looking at an old revision of pydoc.py The current version *is* using tokenize.open and importlib in synopsis(), so those aspects of my comments are incorrect. However, the point that pydoc should probably be using the tokenize module to do the parsing inside source_synopsis remains valid. There's no good reason to continue duplicating a subset of that text processing logic within pydoc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 15:03:50 2012 From: report at bugs.python.org (Aleksey Filippov) Date: Tue, 28 Aug 2012 13:03:50 +0000 Subject: [issue15798] subprocess.Popen() fails if 0, 1 or 2 descriptor is closed Message-ID: <1346159030.18.0.947370235022.issue15798@psf.upfronthosting.co.za> New submission from Aleksey Filippov: System info: kernel: 3.4.8-1-ARCH dist: Arch linux python: 3.2.3 subprocess.Popen() fails if python interpreter is started with closed 0, 1 or 2 descriptor. Traceback (most recent call last): File "", line 14, in File "/usr/lib/python3.2/subprocess.py", line 745, in __init__ restore_signals, start_new_session) File "/usr/lib/python3.2/subprocess.py", line 1197, in _execute_child restore_signals, start_new_session, preexec_fn) ValueError: errpipe_write must be >= 3 ---------- messages: 169276 nosy: sarum9in priority: normal severity: normal status: open title: subprocess.Popen() fails if 0, 1 or 2 descriptor is closed versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 15:12:45 2012 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 28 Aug 2012 13:12:45 +0000 Subject: [issue15798] subprocess.Popen() fails if 0, 1 or 2 descriptor is closed In-Reply-To: <1346159030.18.0.947370235022.issue15798@psf.upfronthosting.co.za> Message-ID: <1346159565.07.0.0657144596602.issue15798@psf.upfronthosting.co.za> Ezio Melotti added the comment: #10806 seems related. ---------- components: +Library (Lib) nosy: +ezio.melotti, pitrou, rosslagerwall type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 15:21:28 2012 From: report at bugs.python.org (Mark Hammond) Date: Tue, 28 Aug 2012 13:21:28 +0000 Subject: [issue15751] Support subinterpreters in the GIL state API In-Reply-To: <1345526301.75.0.455071650321.issue15751@psf.upfronthosting.co.za> Message-ID: <1346160088.9.0.594319532302.issue15751@psf.upfronthosting.co.za> Mark Hammond added the comment: The GIL state api was mainly interested in the case of a thread which has (possibly) never been seen before calling into Python. IIUC, the proposal here is so that a thread that *has* been seen before can be associated with a thread-state specified by the embedding application (and the degenerate case would be to assume the thread hasn't been seen, and as such should get the default interpreter) If that isn't too wide of the mark, I agree it sounds workable and worthwhile. ---------- nosy: +mhammond _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 15:21:55 2012 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 28 Aug 2012 13:21:55 +0000 Subject: [issue14783] Update int() docstring from manual In-Reply-To: <1336751413.58.0.519130225761.issue14783@psf.upfronthosting.co.za> Message-ID: <1346160115.35.0.619118575585.issue14783@psf.upfronthosting.co.za> Ezio Melotti added the comment: .. function:: int(n=0) int(s, base=10) should do the trick. +1 on using this instead of int([number | string[, base]]) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 15:36:24 2012 From: report at bugs.python.org (Mark Hammond) Date: Tue, 28 Aug 2012 13:36:24 +0000 Subject: [issue15751] Support subinterpreters in the GIL state API In-Reply-To: <1345526301.75.0.455071650321.issue15751@psf.upfronthosting.co.za> Message-ID: <1346160984.08.0.830232742659.issue15751@psf.upfronthosting.co.za> Mark Hammond added the comment: To clarify, I wrote: > can be associated with a thread-state specified by the > embedding application Where I meant to say: Can be associated with an interpreter state and corresponding thread-state ... Or something like that - it's been a while since I've looked at that code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 15:39:38 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 28 Aug 2012 13:39:38 +0000 Subject: [issue15775] Add StopParser() to expat In-Reply-To: <1345796297.89.0.127411549702.issue15775@psf.upfronthosting.co.za> Message-ID: <1346161178.15.0.228014206173.issue15775@psf.upfronthosting.co.za> Martin v. L?wis added the comment: nemeskeyd: would you like to work on a patch (for Python 3.4)? ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 15:53:34 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 28 Aug 2012 13:53:34 +0000 Subject: [issue15762] Windows 8 certification In-Reply-To: <1345625605.38.0.633732854192.issue15762@psf.upfronthosting.co.za> Message-ID: <1346162014.61.0.754427848708.issue15762@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The change you proposed cannot be applied to Python 2.7, or any distutils code bases, for a number of reasons: - it's not clear (and probably not the case) that the proposed command line flags are correct for all distutils code. It may well be that some code breaks if you use the flags - if they were 100% backwards compatible, Microsoft wouldn't have made them separate options. - distutils is essentially frozen, any change to it requires considerable negotiation. - for Python 2.7 to 3.3, making such a change would be a new feature (to pass the Windows 8 certification), which cannot be added to a bug fix release. So if you insist that this is a distutils bug, I'll re-close the issue as "won't fix". Instead, I suggest to find a way to solve this within py2exe's setup.py, e.g. by monkey-patching distutils.msvccompiler.MSVCCompiler with a subclass of msvc9compiler.MSVCCompiler. ---------- resolution: invalid -> wont fix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 15:58:29 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 Aug 2012 13:58:29 +0000 Subject: [issue11489] json.dumps not parsable by json.loads (on Linux only) In-Reply-To: <1300058240.59.0.513243746739.issue11489@psf.upfronthosting.co.za> Message-ID: <1346162309.53.0.965792304651.issue11489@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > It's Unicode that considers unpaired surrogates invalid, not UTF-8 by itself. It's UTF-8 too. See RFC 3629: The definition of UTF-8 prohibits encoding character numbers between U+D800 and U+DFFF, which are reserved for use with the UTF-16 encoding form (as surrogate pairs) and do not directly represent characters. When encoding in UTF-8 from UTF-16 data, it is necessary to first decode the UTF-16 data to obtain character numbers, which are then encoded in UTF-8 as described above. ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 16:12:10 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 28 Aug 2012 14:12:10 +0000 Subject: [issue15751] Support subinterpreters in the GIL state API In-Reply-To: <1345526301.75.0.455071650321.issue15751@psf.upfronthosting.co.za> Message-ID: <1346163130.72.0.253867674322.issue15751@psf.upfronthosting.co.za> Nick Coghlan added the comment: Thinking about it, I believe there still needs to be a concept of an "active thread state" TLS key in order to deal with Graham's original problem. Specifically, if PyGILState_EnsureEx is used to associate the thread with a particular interpreter, then subsequent calls to PyGILState_Ensure from *that thread* should get the explicitly associated interpreter, rather than the main interpreter. Then, the lookup sequence for "interpreter=NULL" would be: 1. Check the active TLS key, if set, use that thread state 2. If not set, look up the main interpreter's TLS key. If set, also set that on the active TLS key and use that thread state. 3. If still not set, create a new thread state on the main interpreter, set it for both the active TLS and the main interpreter's TLS key and use that thread state A similar approach almost works when requesting a specific interpreter, but where that goes wrong is when the active TLS key is *already set*. You can't just overwrite it, because that will cause problems for subsequent PyGIL_Release calls. You could just make it an error, but I think Graham's original idea makes it possible to do better than that. Specifically, a PyGILState_SwitchInterpreter API could focus solely on the manipulation of the "active thread state" TLS key entry. The sequence of commands in mod_wsgi would then look like: old_interp = PyGILState_SwitchInterpreter(target_interp); old_gil = PyGILState_Ensure(); /* Call into Python using target_interp */ PyGILState_Release(old_gil); PyGILState_SwitchInterpreter(old_interp); /* May not be needed in the mod_wsgi case, since it knows it is making the outermost call into the PyGILState_* APIs */ All of the other elements of Antoine's proposal (i.e. the per-interpreter TLS key entries) would still be needed, it's just that the API for associating a thread with an interpreter would remain separated from that of associating the thread with a particular thread state. The big advantage of doing it this way is that it will nest properly, whereas PyGILState_EnsureEx would need a more complicated API to correctly report both the old interpreter state and the old GIL state within that interpreter. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 16:37:49 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 28 Aug 2012 14:37:49 +0000 Subject: [issue13266] Add inspect.unwrap(f) to easily unravel "__wrapped__" chains In-Reply-To: <1319611391.89.0.610441716125.issue13266@psf.upfronthosting.co.za> Message-ID: <1346164669.86.0.26004832143.issue13266@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 17:34:59 2012 From: report at bugs.python.org (=?utf-8?q?Nemeskey_D=C3=A1vid?=) Date: Tue, 28 Aug 2012 15:34:59 +0000 Subject: [issue15775] Add StopParser() to expat In-Reply-To: <1345796297.89.0.127411549702.issue15775@psf.upfronthosting.co.za> Message-ID: <1346168099.1.0.545730775854.issue15775@psf.upfronthosting.co.za> Nemeskey D?vid added the comment: loewis: I don't think it would be difficult to fix, so theoretically I'd be in. However, I don't really have the time to work on this right now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 17:38:08 2012 From: report at bugs.python.org (B Maqueira) Date: Tue, 28 Aug 2012 15:38:08 +0000 Subject: [issue15797] bdist_msi does not pass -install/remove flags to install_script In-Reply-To: <1346147472.01.0.0635028414042.issue15797@psf.upfronthosting.co.za> Message-ID: <1346168288.53.0.596337450218.issue15797@psf.upfronthosting.co.za> Changes by B Maqueira : Added file: http://bugs.python.org/file27033/patch1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 18:47:57 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 28 Aug 2012 16:47:57 +0000 Subject: [issue15751] Support subinterpreters in the GIL state API In-Reply-To: <1346163130.72.0.253867674322.issue15751@psf.upfronthosting.co.za> Message-ID: <1346172271.3349.3.camel@localhost.localdomain> Antoine Pitrou added the comment: Le mardi 28 ao?t 2012 ? 14:12 +0000, Nick Coghlan a ?crit : > old_interp = PyGILState_SwitchInterpreter(target_interp); > old_gil = PyGILState_Ensure(); > /* Call into Python using target_interp */ > PyGILState_Release(old_gil); > PyGILState_SwitchInterpreter(old_interp); /* May not be needed in the mod_wsgi case, since it knows it is making the outermost call into the PyGILState_* APIs */ Why wouldn't it be simply written: old_gil = PyGILState_EnsureEx(target_interp); /* Call into Python using target_interp */ PyGILState_Release(old_gil); ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 18:50:26 2012 From: report at bugs.python.org (Matthias Klose) Date: Tue, 28 Aug 2012 16:50:26 +0000 Subject: [issue15591] when building the extensions, stdout is lost when stdout is redirected In-Reply-To: <1344423177.77.0.190751096511.issue15591@psf.upfronthosting.co.za> Message-ID: <1346172626.64.0.796691078867.issue15591@psf.upfronthosting.co.za> Matthias Klose added the comment: bah, this happens when you do a parallel build. --jobserver-fds is passed in MAKEFLAGS, and the test for sharedmods turns on the quiet mode, because it matches just *s* in MAKEFLAGS :-/ The patch tries to parse MAKEFLAGS using getopt, and if getopt is not available, falls back to MAKEFLAGS, and then tries to match -s. The only downside is that you won't get a quiet build, if you don't have getopt, and pass MAKEFLAGS options as a combined option (e.g. -fs). ---------- keywords: +patch Added file: http://bugs.python.org/file27034/makeflags.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 18:59:01 2012 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 28 Aug 2012 16:59:01 +0000 Subject: [issue13592] repr(regex) doesn't include actual regex In-Reply-To: <1323772944.14.0.269599775604.issue13592@psf.upfronthosting.co.za> Message-ID: <1346173141.84.0.336678069501.issue13592@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 19:03:05 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 28 Aug 2012 17:03:05 +0000 Subject: [issue15591] when building the extensions, stdout is lost when stdout is redirected In-Reply-To: <1344423177.77.0.190751096511.issue15591@psf.upfronthosting.co.za> Message-ID: <3X5x9h09ZbzPvw@mail.python.org> Roundup Robot added the comment: New changeset 1a1d097b17e2 by Matthias Klose in branch '2.7': - Issue #15591: Fix parsing MAKEFLAGS in the sharedmods target. http://hg.python.org/cpython/rev/1a1d097b17e2 New changeset 763d188a96bb by Matthias Klose in branch '3.2': - Issue #15591: Fix parsing MAKEFLAGS in the sharedmods target. http://hg.python.org/cpython/rev/763d188a96bb New changeset 3a3fd48a6ef7 by Matthias Klose in branch 'default': - Issue #15591: Fix parsing MAKEFLAGS in the sharedmods target. http://hg.python.org/cpython/rev/3a3fd48a6ef7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 19:04:27 2012 From: report at bugs.python.org (Matthias Klose) Date: Tue, 28 Aug 2012 17:04:27 +0000 Subject: [issue15591] when building the extensions, stdout is lost when stdout is redirected In-Reply-To: <1344423177.77.0.190751096511.issue15591@psf.upfronthosting.co.za> Message-ID: <1346173467.82.0.825848398415.issue15591@psf.upfronthosting.co.za> Matthias Klose added the comment: fixed. ---------- resolution: -> fixed status: open -> closed versions: -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 20:13:56 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 28 Aug 2012 18:13:56 +0000 Subject: [issue15794] test_importlib: test_locks failure In-Reply-To: <1346106901.9.0.610184889675.issue15794@psf.upfronthosting.co.za> Message-ID: <3X5ylQ6gXNzPvq@mail.python.org> Roundup Robot added the comment: New changeset 454dceb5fd56 by Antoine Pitrou in branch 'default': Issue #15794: Relax a test case due to the deadlock detection's conservativeness. http://hg.python.org/cpython/rev/454dceb5fd56 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 20:14:47 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 28 Aug 2012 18:14:47 +0000 Subject: [issue15794] test_importlib: test_locks failure In-Reply-To: <1346106901.9.0.610184889675.issue15794@psf.upfronthosting.co.za> Message-ID: <1346177687.49.0.00437275919109.issue15794@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 21:02:39 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 28 Aug 2012 19:02:39 +0000 Subject: [issue15591] when building the extensions, stdout is lost when stdout is redirected In-Reply-To: <1344423177.77.0.190751096511.issue15591@psf.upfronthosting.co.za> Message-ID: <1346180559.4.0.94998597263.issue15591@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 21:11:21 2012 From: report at bugs.python.org (Mike Hoy) Date: Tue, 28 Aug 2012 19:11:21 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1346181081.74.0.962484968117.issue14468@psf.upfronthosting.co.za> Changes by Mike Hoy : ---------- nosy: +mikehoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 21:22:47 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 28 Aug 2012 19:22:47 +0000 Subject: [issue15784] OSError.__str__() should distinguish between errno and winerror In-Reply-To: <1345920277.5.0.279969365859.issue15784@psf.upfronthosting.co.za> Message-ID: <3X60Gt5ND6zPvm@mail.python.org> Roundup Robot added the comment: New changeset 2e587b9bae35 by Richard Oudkerk in branch 'default': Issue #15784: Modify OSError.__str__() to better distinguish between http://hg.python.org/cpython/rev/2e587b9bae35 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 21:55:32 2012 From: report at bugs.python.org (Stefan Krah) Date: Tue, 28 Aug 2012 19:55:32 +0000 Subject: [issue15783] decimal.localcontext(None) fails when using the C accelerator module In-Reply-To: <1345904683.65.0.863127291798.issue15783@psf.upfronthosting.co.za> Message-ID: <1346183732.07.0.0376681794244.issue15783@psf.upfronthosting.co.za> Stefan Krah added the comment: I don't want to block this, BTW. Personally I'm +-0 on the issue. If more people think this is needed for backwards compatibility, I'll write a patch for localcontext. But I'd rather do that *very* soon. FWIW, none of the cdecimal users has ever complained about this. So we have a tie here: Mark thinks it can wait, Nick thinks it's better to do something. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 22:31:31 2012 From: report at bugs.python.org (karl) Date: Tue, 28 Aug 2012 20:31:31 +0000 Subject: [issue15799] httplib client and statusline Message-ID: <1346185891.22.0.123491218752.issue15799@psf.upfronthosting.co.za> New submission from karl: The current parsing of HTTP status line seems strange with regards to its definition in HTTP. http://hg.python.org/cpython/file/3.2/Lib/http/client.py#l307 Currently the code is version, status, reason = line.split(None, 2) >>> status1 = "HTTP/1.1 200 OK" >>> status2 = "HTTP/1.1 200 " >>> status3 = "HTTP/1.1 200" >>> status1.split(None, 2) ['HTTP/1.1', '200', 'OK'] >>> status2.split(None, 2) ['HTTP/1.1', '200'] >>> status3.split(None, 2) ['HTTP/1.1', '200'] According to the production rules of HTTP/1.1 bis only status1 and status2 are valid. status-line = HTTP-version SP status-code SP reason-phrase CRLF ? http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-20#section-3.1.2 with reason-phrase = *( HTAB / SP / VCHAR / obs-text ) aka 0 or more characters. I'm also not sure what are the expected ValueError with additional parsing rules which seems even more bogus. First modification should be >>> status1.split(' ', 2) ['HTTP/1.1', '200', 'OK'] >>> status2.split(' ', 2) ['HTTP/1.1', '200', ''] Which would be correct for the first two, with an empty reason-phrase The third one is still no good. >>> status3.split(' ', 2) ['HTTP/1.1', '200'] An additional check could be done with len(status.split(' ', 2)) == 3 Will return False in the third case. Do you want me to create a patch and a test for it? ---------- messages: 169293 nosy: karlcow priority: normal severity: normal status: open title: httplib client and statusline type: enhancement versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 22:39:17 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 28 Aug 2012 20:39:17 +0000 Subject: [issue15799] httplib client and statusline In-Reply-To: <1346185891.22.0.123491218752.issue15799@psf.upfronthosting.co.za> Message-ID: <1346186357.35.0.0579419925913.issue15799@psf.upfronthosting.co.za> R. David Murray added the comment: Could you explain the error you are seeing in more detail first? You are talk about parsing and fixes here, but I'm not clear on what the actual bug is you are reporting. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 22:43:14 2012 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 28 Aug 2012 20:43:14 +0000 Subject: [issue15783] decimal.localcontext(None) fails when using the C accelerator module In-Reply-To: <1345904683.65.0.863127291798.issue15783@psf.upfronthosting.co.za> Message-ID: <1346186594.94.0.480197766558.issue15783@psf.upfronthosting.co.za> Mark Dickinson added the comment: I don't really feel that strongly either way, either. I understand Nick's arguments, but can't help feeling that we're letting a doc mistake dictate the API here. (And my inner type-system has an aversion to APIs where arguments are expected to be *either* None or of type/interface XXX.) So colour me -0 on changing cdecimal to allow the 'None' argument. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 22:52:06 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 Aug 2012 20:52:06 +0000 Subject: [issue15800] Closing of sys.std* files in gzip test. Message-ID: <1346187126.27.0.0616133533378.issue15800@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: When porting gzip module from Python 2 to Python 3, binary files sys.std(in|out) was replaced by sys.std(in|out).buffer in gzip module internal testing code (when gzip used as executable). But in one place the replacement was skipped. As the result the condition now always true and standard files are closed after use. Here is a patch that fixes this error. ---------- components: Library (Lib) files: gzip_main_close.patch keywords: patch messages: 169296 nosy: pitrou, storchaka priority: low severity: normal status: open title: Closing of sys.std* files in gzip test. type: resource usage versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file27035/gzip_main_close.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 22:59:21 2012 From: report at bugs.python.org (karl) Date: Tue, 28 Aug 2012 20:59:21 +0000 Subject: [issue15799] httplib client and statusline In-Reply-To: <1346185891.22.0.123491218752.issue15799@psf.upfronthosting.co.za> Message-ID: <1346187561.97.0.976211888186.issue15799@psf.upfronthosting.co.za> karl added the comment: ok. status lines 1 and 2 are valid. the third one is invalid and should trigger a raise BadStatusLine(line) The code at line 318 is bogus as it will parse happily the third line without raising an exception. http://hg.python.org/cpython/file/3.2/Lib/http/client.py#l318 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 23:01:07 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 28 Aug 2012 21:01:07 +0000 Subject: [issue15799] httplib client and statusline In-Reply-To: <1346185891.22.0.123491218752.issue15799@psf.upfronthosting.co.za> Message-ID: <1346187667.17.0.384291884434.issue15799@psf.upfronthosting.co.za> R. David Murray added the comment: Why should it raise an error? The postel principle suggests that we should treat it as equivalent to the second line. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 23:03:12 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 28 Aug 2012 21:03:12 +0000 Subject: [issue15799] httplib client and statusline In-Reply-To: <1346185891.22.0.123491218752.issue15799@psf.upfronthosting.co.za> Message-ID: <1346187792.27.0.0510572173067.issue15799@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I would point out that the goal of the http module is to provide interoperability with real-life servers, rather than be a strict implementation of RFCs. So, starting to raise errors for "HTTP/1.1 200" while "HTTP/1.1 200 " remains ok might not be the best idea. ---------- nosy: +orsenthil, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 23:06:22 2012 From: report at bugs.python.org (Erik Allik) Date: Tue, 28 Aug 2012 21:06:22 +0000 Subject: [issue15801] Weird string interpolation behaviour Message-ID: <1346187982.17.0.733777939563.issue15801@psf.upfronthosting.co.za> New submission from Erik Allik: >>> class Foo(object): ... pass ... >>> "asdads" % Foo() 'asdads' Doesn't look like it's supposed to be this way. As per the documentation: "If format requires a single argument, values may be a single non-tuple object. [5] Otherwise, values must be a tuple with exactly the number of items specified by the format string, or a single mapping object (for example, a dictionary)." Tested and confirmed on 2.5, 2.6, 2.7 (both old and new style classes) and 3.2. ---------- messages: 169300 nosy: eallik priority: normal severity: normal status: open title: Weird string interpolation behaviour type: behavior versions: Python 2.6, Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 23:07:58 2012 From: report at bugs.python.org (Alex Gaynor) Date: Tue, 28 Aug 2012 21:07:58 +0000 Subject: [issue15801] Weird string interpolation behaviour In-Reply-To: <1346187982.17.0.733777939563.issue15801@psf.upfronthosting.co.za> Message-ID: <1346188078.26.0.668469087096.issue15801@psf.upfronthosting.co.za> Alex Gaynor added the comment: Additional detail, if and only if Foo defines an __str__ method, this raises an exception. ---------- nosy: +alex _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 23:16:52 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 28 Aug 2012 21:16:52 +0000 Subject: [issue15801] Weird string interpolation behaviour In-Reply-To: <1346187982.17.0.733777939563.issue15801@psf.upfronthosting.co.za> Message-ID: <1346188612.08.0.00690941835094.issue15801@psf.upfronthosting.co.za> R. David Murray added the comment: That doesn't appear to be true in 3.2. I happened to test this on email.message.Message, and it also did not raise an error, but it defines an __str__. I suspect this is some oddball result of the coercion rules. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 23:19:39 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 28 Aug 2012 21:19:39 +0000 Subject: [issue15801] Weird string interpolation behaviour In-Reply-To: <1346187982.17.0.733777939563.issue15801@psf.upfronthosting.co.za> Message-ID: <1346188779.03.0.828066201394.issue15801@psf.upfronthosting.co.za> R. David Murray added the comment: Didn't get an error in 2.7, either, with Message(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 23:27:59 2012 From: report at bugs.python.org (Mike Graham) Date: Tue, 28 Aug 2012 21:27:59 +0000 Subject: [issue15801] Weird string interpolation behaviour In-Reply-To: <1346187982.17.0.733777939563.issue15801@psf.upfronthosting.co.za> Message-ID: <1346189279.66.0.447106090152.issue15801@psf.upfronthosting.co.za> Mike Graham added the comment: Line 13464 of unicodeobject.c is if (Py_TYPE(args)->tp_as_mapping && !PyTuple_Check(args) && !PyUnicode_Check(args)) Too lazy to check, but don't user-created types have a tp_as_mapping? If so, I think it mistakes Foo() for a dict. ---------- nosy: +Mike.Graham _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 23:28:10 2012 From: report at bugs.python.org (karl) Date: Tue, 28 Aug 2012 21:28:10 +0000 Subject: [issue15799] httplib client and statusline In-Reply-To: <1346185891.22.0.123491218752.issue15799@psf.upfronthosting.co.za> Message-ID: <1346189290.71.0.465646485962.issue15799@psf.upfronthosting.co.za> karl added the comment: Fair enough, it could be a warning when * more than one space in between http version and status code * if there is a missing space after the status code I'm not advocating for being strict only. I'm advocating for giving the tools to developer to assess that things are right and choose or not to ignore and having to avoid to patch the libraries or rewrite modules when you create code which needs to be strict for specifically validating responses and requests. :) ps: I haven't checked yet if the server counter part of httplib was strict in the production rule. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 23:30:14 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 28 Aug 2012 21:30:14 +0000 Subject: [issue15591] when building the extensions, stdout is lost when stdout is redirected In-Reply-To: <1344423177.77.0.190751096511.issue15591@psf.upfronthosting.co.za> Message-ID: <1346189414.8.0.60481911151.issue15591@psf.upfronthosting.co.za> Benjamin Peterson added the comment: This seems to have broken parallel building of modules. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 23:50:08 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 Aug 2012 21:50:08 +0000 Subject: [issue15802] Illegal test for mailbox Message-ID: <1346190608.89.0.55767676189.issue15802@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Test for mailbox contains meaningless asserts. Here is a patch that corrects testing, if I correctly understand it. ---------- components: Tests files: test_mailbox_create_tmp.patch keywords: patch messages: 169307 nosy: akuchling, barry, r.david.murray, storchaka priority: normal severity: normal status: open title: Illegal test for mailbox type: behavior versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file27036/test_mailbox_create_tmp.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 23:50:51 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 Aug 2012 21:50:51 +0000 Subject: [issue15802] Illegal test for mailbox In-Reply-To: <1346190608.89.0.55767676189.issue15802@psf.upfronthosting.co.za> Message-ID: <1346190651.03.0.86322477403.issue15802@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file27037/test_mailbox_create_tmp-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 28 23:57:11 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 28 Aug 2012 21:57:11 +0000 Subject: [issue15802] Illegal test for mailbox In-Reply-To: <1346190608.89.0.55767676189.issue15802@psf.upfronthosting.co.za> Message-ID: <1346191031.73.0.777895168269.issue15802@psf.upfronthosting.co.za> R. David Murray added the comment: Looks right to me on a quick scan, but I'm not familiar with that test. ---------- nosy: +petri.lehtinen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 00:01:58 2012 From: report at bugs.python.org (A.M. Kuchling) Date: Tue, 28 Aug 2012 22:01:58 +0000 Subject: [issue15802] Illegal test for mailbox In-Reply-To: <1346190608.89.0.55767676189.issue15802@psf.upfronthosting.co.za> Message-ID: <1346191318.24.0.53028767277.issue15802@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 00:02:46 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 28 Aug 2012 22:02:46 +0000 Subject: [issue15801] Weird string interpolation behaviour In-Reply-To: <1346187982.17.0.733777939563.issue15801@psf.upfronthosting.co.za> Message-ID: <3X63q50kDXzQ31@mail.python.org> Roundup Robot added the comment: New changeset 2801bf875a24 by Benjamin Peterson in branch '2.7': use the stricter PyMapping_Check (closes #15801) http://hg.python.org/cpython/rev/2801bf875a24 New changeset 4d431e719646 by Benjamin Peterson in branch '3.2': use the stricter PyMapping_Check (closes #15801) http://hg.python.org/cpython/rev/4d431e719646 New changeset 263d09ce3e9e by Benjamin Peterson in branch 'default': merge 3.2 (#15801) http://hg.python.org/cpython/rev/263d09ce3e9e ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 00:10:13 2012 From: report at bugs.python.org (Graham Dumpleton) Date: Tue, 28 Aug 2012 22:10:13 +0000 Subject: [issue15751] Support subinterpreters in the GIL state API In-Reply-To: <1345526301.75.0.455071650321.issue15751@psf.upfronthosting.co.za> Message-ID: <1346191813.13.0.60126446433.issue15751@psf.upfronthosting.co.za> Graham Dumpleton added the comment: Sorry, Mark. Is not for associating thread state specified by embedding application. In simple terms it is exactly like existing PyGILState_Ensure() in that caller doesn't have a thread state, whether it has already been created. Only difference is to allow that simplified API to work against a sub interpreter. Nick, I previously said: """In the case of the latter, if a Python thread is created in a specific sub interpreter, it should automatically designate for that thread that that is its interpreter context, so if it calls out and does the Release/Ensure dance, that it goes back into the same sub interpreter.""" So yes to your: """Thinking about it, I believe there still needs to be a concept of an "active thread state" TLS key in order to deal with Graham's original problem. Specifically, if PyGILState_EnsureEx is used to associate the thread with a particular interpreter, then subsequent calls to PyGILState_Ensure from *that thread* should get the explicitly associated interpreter, rather than the main interpreter.""" My example was more to do with a thread created in Python then calling out and back in, but same deal as foreign thread calling in, out and back in. Antoine, yes, can possibly can be simplified to that. The original idea of a switch interpreter function was suggested on basis that PyGILState_Ensure would not be modified or extended version of function created. Rolling an implicit switch interpreter into PyGILState_EnsureEx when argument is different to the current may serve same purpose. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 00:18:04 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 28 Aug 2012 22:18:04 +0000 Subject: [issue15785] curses.get_wch() returns keypad codes incorrectly In-Reply-To: <1345975778.97.0.705241878581.issue15785@psf.upfronthosting.co.za> Message-ID: <1346192284.61.0.677694442452.issue15785@psf.upfronthosting.co.za> STINNER Victor added the comment: New patch fixing the issue with a better API: window.get_wch()->int or str depending on the key (int for key codes, str for other keys). Oh, I realized that test_curses does also fail on my laptop without the patch. My laptop is running Fedora 11 which uses libncurses 5.7. This version is old and has known bugs. So the "unget_wch" issue is maybe unrelated. ---------- Added file: http://bugs.python.org/file27038/curses_get_wch-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 00:18:17 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 28 Aug 2012 22:18:17 +0000 Subject: [issue15785] curses.get_wch() returns keypad codes incorrectly In-Reply-To: <1345975778.97.0.705241878581.issue15785@psf.upfronthosting.co.za> Message-ID: <1346192297.3.0.0107839097603.issue15785@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file27007/curses_get_wch.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 00:19:05 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 28 Aug 2012 22:19:05 +0000 Subject: [issue15785] curses.get_wch() returns keypad codes incorrectly In-Reply-To: <1345975778.97.0.705241878581.issue15785@psf.upfronthosting.co.za> Message-ID: <1346192345.67.0.461907098421.issue15785@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Perhaps you should simply remove the new function, and re-add it in 3.4 when you've thought it out a bit more. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 00:23:44 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 28 Aug 2012 22:23:44 +0000 Subject: [issue15785] curses.get_wch() returns keypad codes incorrectly In-Reply-To: <1345975778.97.0.705241878581.issue15785@psf.upfronthosting.co.za> Message-ID: <1346192624.14.0.755271906798.issue15785@psf.upfronthosting.co.za> STINNER Victor added the comment: window.get_wch() has been added by the issue #6755, and curses.unget_wch() by #12567. Copy the nosy of the issue #6755. ---------- nosy: +Nicholas.Cole, akuchling, cben, gpolo, inigoserna, jcea, phep, python-dev, r.david.murray, schodet, zeha _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 00:31:49 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 28 Aug 2012 22:31:49 +0000 Subject: [issue15785] curses.get_wch() returns keypad codes incorrectly In-Reply-To: <1345975778.97.0.705241878581.issue15785@psf.upfronthosting.co.za> Message-ID: <1346193109.33.0.974235305045.issue15785@psf.upfronthosting.co.za> STINNER Victor added the comment: New patch with a test for this specific issue. (It's not easy to me to write a patch because my version of libncurses doesn't work with integers bigger than 128...) ---------- Added file: http://bugs.python.org/file27039/curses_get_wch-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 00:31:59 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 28 Aug 2012 22:31:59 +0000 Subject: [issue15785] curses.get_wch() returns keypad codes incorrectly In-Reply-To: <1345975778.97.0.705241878581.issue15785@psf.upfronthosting.co.za> Message-ID: <1346193119.08.0.350625838028.issue15785@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file27038/curses_get_wch-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 00:52:34 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 28 Aug 2012 22:52:34 +0000 Subject: [issue14649] doctest.DocTestSuite error misleading when module has no docstrings In-Reply-To: <1335192861.9.0.305748973415.issue14649@psf.upfronthosting.co.za> Message-ID: <1346194354.2.0.917461746439.issue14649@psf.upfronthosting.co.za> R. David Murray added the comment: With your patch 5 applied, test_zipimport_support fails. I took a quick look at this and it looks like it is because we've added a dependency on an external data file to the test for DocTestSuite. Note that with patch 4 applied, test_pyclbr fails...I found that out by accident. Not sure why test_zipimport_support didn't fail with that one. But regardless we'll have to deal with pyclbr if/when we isolate the doctest test files. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 00:55:14 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 28 Aug 2012 22:55:14 +0000 Subject: [issue15785] curses.get_wch() returns keypad codes incorrectly In-Reply-To: <1345975778.97.0.705241878581.issue15785@psf.upfronthosting.co.za> Message-ID: <1346194514.7.0.64599508011.issue15785@psf.upfronthosting.co.za> STINNER Victor added the comment: > Perhaps you should simply remove the new function, and re-add it in 3.4 when you've thought it out a bit more. Python 3 forces somehow to use Unicode, and the Unicode support of the curses module in Python 3.2 is incomplete or broken (see . Many issues have been fixed in Python 3.3. It would be a regression to remove get_wch(), it's an important function to use the curses module with Python 3. Changes between Python 3.2 and 3.3: http://docs.python.org/dev/whatsnew/3.3.html#curses ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 01:05:22 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 28 Aug 2012 23:05:22 +0000 Subject: [issue14649] doctest.DocTestSuite error misleading when module has no docstrings In-Reply-To: <1335192861.9.0.305748973415.issue14649@psf.upfronthosting.co.za> Message-ID: <1346195122.75.0.315113579481.issue14649@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > With your patch 5 applied, test_zipimport_support fails. You're right. It looks like test_zipimport_support is tightly coupled to test_doctest. For example-- http://hg.python.org/cpython/file/786d9516663e/Lib/test/test_zipimport_support.py#l94 My apologies for not running the full test suite before uploading those patches. I'll take a closer look. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 01:06:25 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 28 Aug 2012 23:06:25 +0000 Subject: [issue15785] curses.get_wch() returns keypad codes incorrectly In-Reply-To: <1345975778.97.0.705241878581.issue15785@psf.upfronthosting.co.za> Message-ID: <1346195185.75.0.575521069155.issue15785@psf.upfronthosting.co.za> Changes by STINNER Victor : Added file: http://bugs.python.org/file27038/curses_get_wch-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 01:06:46 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 28 Aug 2012 23:06:46 +0000 Subject: [issue15785] curses.get_wch() returns keypad codes incorrectly In-Reply-To: <1345975778.97.0.705241878581.issue15785@psf.upfronthosting.co.za> Message-ID: <1346195206.55.0.275792274463.issue15785@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file27039/curses_get_wch-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 01:10:40 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 28 Aug 2012 23:10:40 +0000 Subject: [issue15785] curses.get_wch() returns keypad codes incorrectly In-Reply-To: <1345975778.97.0.705241878581.issue15785@psf.upfronthosting.co.za> Message-ID: <1346195440.46.0.472391019022.issue15785@psf.upfronthosting.co.za> STINNER Victor added the comment: bitdancer tested the patch version 3 for me and it fails: unget_wch(KEY_UP) inserts the character U+0103 (259, ?) instead of KEY_UP in get_wch() buffer. unget_wch() cannot be used to insert key codes, only classic keys like letters. So I removed the patch version 3 and restored patch version 2 which only changes the get_wch() API and adapts the existing unit test. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 01:14:01 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 28 Aug 2012 23:14:01 +0000 Subject: [issue15785] curses.get_wch() returns keypad codes incorrectly In-Reply-To: <1345975778.97.0.705241878581.issue15785@psf.upfronthosting.co.za> Message-ID: <1346195641.08.0.172667336198.issue15785@psf.upfronthosting.co.za> STINNER Victor added the comment: @simpkins: can you please try my patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 01:29:26 2012 From: report at bugs.python.org (Erik Allik) Date: Tue, 28 Aug 2012 23:29:26 +0000 Subject: [issue15801] Weird string interpolation behaviour In-Reply-To: <1346187982.17.0.733777939563.issue15801@psf.upfronthosting.co.za> Message-ID: <1346196566.28.0.270082487889.issue15801@psf.upfronthosting.co.za> Erik Allik added the comment: Respectable reaction time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 01:31:05 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 28 Aug 2012 23:31:05 +0000 Subject: [issue15785] curses.get_wch() returns keypad codes incorrectly In-Reply-To: <1345975778.97.0.705241878581.issue15785@psf.upfronthosting.co.za> Message-ID: <1346196665.21.0.210521483777.issue15785@psf.upfronthosting.co.za> STINNER Victor added the comment: bitdancer proposes (on IRC) a better doc for get_wch(): "Get a wide character. Return a character for most keys, or an integer for function keys, keypad keys, and other special keys." We may also replace "and so on" by "and other special keys" in getkey() definition. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 01:41:48 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 28 Aug 2012 23:41:48 +0000 Subject: [issue15785] curses.get_wch() returns keypad codes incorrectly In-Reply-To: <1345975778.97.0.705241878581.issue15785@psf.upfronthosting.co.za> Message-ID: <3X661l0ssczPvY@mail.python.org> Roundup Robot added the comment: New changeset c58789634d22 by Victor Stinner in branch 'default': Issue #15785: Modify window.get_wch() API of the curses module: return a http://hg.python.org/cpython/rev/c58789634d22 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 02:10:16 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 29 Aug 2012 00:10:16 +0000 Subject: [issue14649] doctest.DocTestSuite error misleading when module has no docstrings In-Reply-To: <1335192861.9.0.305748973415.issue14649@psf.upfronthosting.co.za> Message-ID: <1346199016.51.0.356891754312.issue14649@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I updated the patch to fix the test_zipimport_support tests. All tests now pass. The only changes were to Lib/test/test_zipimport_support.py. I'll make a note about test_pyclbr and test_zipimport_support when I create the issue to move the supporting doctest files into a subdirectory. Thanks again for the catch, David. ---------- Added file: http://bugs.python.org/file27040/issue-14649-6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 02:45:58 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 29 Aug 2012 00:45:58 +0000 Subject: [issue15800] Closing of sys.std* files in gzip test. In-Reply-To: <1346187126.27.0.0616133533378.issue15800@psf.upfronthosting.co.za> Message-ID: <1346201158.45.0.4779929916.issue15800@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 02:47:57 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 29 Aug 2012 00:47:57 +0000 Subject: [issue15802] Illegal test for mailbox In-Reply-To: <1346190608.89.0.55767676189.issue15802@psf.upfronthosting.co.za> Message-ID: <1346201277.65.0.493339553535.issue15802@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 03:12:25 2012 From: report at bugs.python.org (Nathan Trapuzzano) Date: Wed, 29 Aug 2012 01:12:25 +0000 Subject: [issue15803] Incorrect docstring on ConfigParser.items() Message-ID: <1346202745.06.0.103510250689.issue15803@psf.upfronthosting.co.za> New submission from Nathan Trapuzzano: The docstring on ConfigParser.items() is self-evidently bass ackwards. Fix is in attached patch. ---------- components: Library (Lib) files: cpython.patch keywords: patch messages: 169324 nosy: nbtrap priority: normal severity: normal status: open title: Incorrect docstring on ConfigParser.items() type: enhancement versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file27041/cpython.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 03:37:14 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 29 Aug 2012 01:37:14 +0000 Subject: [issue15783] decimal.localcontext(None) fails when using the C accelerator module In-Reply-To: <1345904683.65.0.863127291798.issue15783@psf.upfronthosting.co.za> Message-ID: <1346204234.72.0.592747386065.issue15783@psf.upfronthosting.co.za> Nick Coghlan added the comment: I agree it's an acceptable risk for 3.3.0. Most third party decimal operations simply won't accept an explicit context argument at all - avoiding the need to pass the current context around explicitly is the whole point of it being stored in the thread locals. However, I still think it would be better if consistency with the Python API could be restored for 3.3.1. If that's done via a more general "this value means the arg is actually missing" C API that can be made public in 3.4, so much the better. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 03:37:16 2012 From: report at bugs.python.org (gd2shoe) Date: Wed, 29 Aug 2012 01:37:16 +0000 Subject: [issue15804] Feature request, implicit "except : pass" Message-ID: <1346204236.32.0.579082427996.issue15804@psf.upfronthosting.co.za> New submission from gd2shoe: I'm constantly finding myself writing itty-bitty try blocks like such: process stuff try : someSubProcess.kill() except : pass process stuff I realize this isn't a rigorous use of except, but it's good enough for a vast majority of what I need it for. Still, it adds excess verbiage and makes code slightly harder to read. All I need except to do most of the time is suppress exceptions. I think the language could be enhanced by making the except clause implicit. the above would become: process stuff try : someSubProcess.kill() process stuff The intent remains clear. The code is cleaner and easier to read. This does not happen often in rigorous code, but grep does find 3 counts in standard modules and 9 counts in numpy. I'm certain most prototype code (like mine) would greatly benefit. (My current 300 line project uses 4 so far.) ---------- components: Interpreter Core messages: 169326 nosy: gd2shoe priority: normal severity: normal status: open title: Feature request, implicit "except : pass" type: enhancement versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 03:45:17 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 29 Aug 2012 01:45:17 +0000 Subject: [issue15804] Feature request, implicit "except : pass" In-Reply-To: <1346204236.32.0.579082427996.issue15804@psf.upfronthosting.co.za> Message-ID: <1346204717.51.0.677136138237.issue15804@psf.upfronthosting.co.za> Raymond Hettinger added the comment: FWIW, this is already easy to do with decorators: >>> class Pass: def __init__(self, exc): self.exc = exc def __enter__(self): return self def __exit__(self, exctype, excinst, exctb): return exctype == self.exc >>> with Pass(IndexError): 'hello'[10] ---------- nosy: +rhettinger priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 03:52:43 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 29 Aug 2012 01:52:43 +0000 Subject: [issue15804] Feature request, implicit "except : pass" In-Reply-To: <1346204236.32.0.579082427996.issue15804@psf.upfronthosting.co.za> Message-ID: <1346205163.85.0.956816814545.issue15804@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: No way this is going to be in 2.7. ---------- nosy: +jcea versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 04:19:14 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 29 Aug 2012 02:19:14 +0000 Subject: [issue15751] Support subinterpreters in the GIL state API In-Reply-To: <1345526301.75.0.455071650321.issue15751@psf.upfronthosting.co.za> Message-ID: <1346206754.17.0.487622792732.issue15751@psf.upfronthosting.co.za> Nick Coghlan added the comment: The reason I'm proposing going back to the original SwitchInterpreter idea is because the EnsureEx idea doesn't nest cleanly - if your thread is already associated with "interpreter A", you can't readily call into "interpeter B", because the API provides no way to correctly restore the associated interpreter back to interpreter A when you're done. EnsureEx works fine if extension modules are not aware of multiple interpreters: /* Embedding application (GIL always unlocked) */ gilstate = PyGILState_EnsureEx(interp_A); /* Python code and extension code happens */ /* Callback needs to reach back into Python */ cb_gilstate = PyGILState_Ensure(); /* Callback runs */ PyGILState_Release(cb_gilstate); /* Python code and extension code unwinds */ PyGILState_Release(gilstate); However, it *doesn't* work (at least, not easily) if the extension itself wants to call back into an interpreter other than the one already associated with the current thread: /* Embedding application (GIL always unlocked) */ gilstate = PyGILState_EnsureEx(interp_A); /* Python code and extension code happens */ /* Callback needs to reach back into a specific interpreter */ cb_gilstate = PyGILState_EnsureEx(interp_B); /* Callback runs */ PyGILState_Release(cb_gilstate); /* Python code and extension code unwinds */ PyGILState_Release(gilstate); Does that second call to EnsureEx fail? If it succeeds, how does the client know which interpreter to use for the PyGILState_Release call? It could be made to work if PyGILState_STATE was changed from an enum to a struct that included in interpreter state pointer, or if EnsureEx returned a different type and was paired up with a new ReleaseEx pointer. However, that's starting to get very messy compared to a separate SwitchInterpreter call: /* Embedding application (GIL always unlocked) */ old_interp = PyGILState_SwitchInterpreter(interp_A); /* "autoTLSkey" now refers to a thread state for interpreter A */ gilstate = PyGILState_Ensure(); /* Python code and extension code happens */ /* Callback needs to reach back into Python */ pre_cb_interp = PyGILState_SwitchInterpreter(interp_B); /* "autoTLSkey" now refers to a thread state for interpreter B */ cb_gilstate = PyGILState_Ensure(); /* Callback runs */ PyGILState_Release(cb_gilstate); PyGILState_SwitchInterpreter(pre_cb_interp); /* "autoTLSkey" again refers to a thread state for interpreter A */ /* Python code and extension code unwinds */ PyGILState_Release(gilstate); PyGILState_SwitchInterpreter(old_interp); And yes, I'm pondering ways that this could be used to implement Rust-style "channels" for communication between interpreters without needing to copy data, by using this API to create proxy interfaces for accessing an object owned by another subinterpreter. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 04:49:48 2012 From: report at bugs.python.org (Graham Dumpleton) Date: Wed, 29 Aug 2012 02:49:48 +0000 Subject: [issue15751] Support subinterpreters in the GIL state API In-Reply-To: <1345526301.75.0.455071650321.issue15751@psf.upfronthosting.co.za> Message-ID: <1346208588.94.0.43842431361.issue15751@psf.upfronthosting.co.za> Graham Dumpleton added the comment: Nick. Valid point. I guess I hadn't been thinking about case of one thread calling out of one interpreter and then into another, as I don't do it in mod_wsgi and even I regard doing that as partly evil. Does that mean this switch interpreter call somehow gets used in the Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 05:04:24 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 29 Aug 2012 03:04:24 +0000 Subject: [issue15804] Feature request, implicit "except : pass" In-Reply-To: <1346204236.32.0.579082427996.issue15804@psf.upfronthosting.co.za> Message-ID: <1346209464.01.0.793301446601.issue15804@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Please submit your idea to the python-ideas list. ---------- nosy: +benjamin.peterson resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 06:03:40 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 29 Aug 2012 04:03:40 +0000 Subject: [issue15751] Support subinterpreters in the GIL state API In-Reply-To: <1345526301.75.0.455071650321.issue15751@psf.upfronthosting.co.za> Message-ID: <1346213020.41.0.0308292718246.issue15751@psf.upfronthosting.co.za> Nick Coghlan added the comment: No, those wouldn't change at all. However, after thinking about it further, I'm leaning back towards the option of an EnsureEx/ReleaseEx pair that allows the previous interpreter to be reported and restored along with the GIL state. I'd also like to make the state an opaque structure that isn't exposed in the limited API. Something along the lines of: typedef struct _gilinfo { PyGILState_STATE lock_state; PyInterpreter *active; } PyGILState_INFO; int /* Allow returning an error code */ PyGILState_EnsureEx(PyInterpreterState *target, PyGILState_INFO *prev); void PyGILState_ReleaseEx(PyGILState_INFO *prev); This allows various issues related to implicitly creating thread states to be handled the same way they are now, where PyThreadState_New will create a persistent thread state, while PyGILState_EnsureEx will either use a preexisting thread state for the requested interpreter (if it exists), or implicitly create one. Implicitly created thread states would be destroyed by the corresponding call to ReleaseEx. To make this work, I believe all that should be needed is for: 1. PyInterpreterState updated to include a per-interpreter TLS key 2. _PyGILState_NoteThreadState would update both the autoTLSkey entry and the per-interpreter key entry 3. PyGILState_EnsureEx added to support switching the autoTLSkey entry to point to a different thread state (creating it if needed) 4. PyGILState_Ensure updated to map to PyGILState_EnsureEx(NULL) and to extract the lock state from the info structure 5. PyGILState_Release updated to populate the info structure with the active interpreter and the passed in previous GIL state before calling PyGILState_ReleaseEx 5. PyThreadState_Delete and PyThreadState_DeleteCurrent updated to also clobber the per-interpreter TLS key entry PyThreadState_New already calls _PyGILState_NoteThreadState implicitly, so Python created threads (and embedded threads with an explicitly created thread state) should do the right thing automatically. Making the INFO struct an opaque token also means it can be expanded to cover any future needs that arise. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 06:13:59 2012 From: report at bugs.python.org (Graham Dumpleton) Date: Wed, 29 Aug 2012 04:13:59 +0000 Subject: [issue15751] Support subinterpreters in the GIL state API In-Reply-To: <1345526301.75.0.455071650321.issue15751@psf.upfronthosting.co.za> Message-ID: <1346213639.93.0.948204321485.issue15751@psf.upfronthosting.co.za> Graham Dumpleton added the comment: So you are saying that as user of this I am meant to call it as: PyGILState_INFO info; PyGILState_EnsureEx(interp, &info); ... PyGILState_ReleaseEx(&info); What is the potential error code from PyGILState_EnsureEx() considering that right now for PyGILState_Ensure() it is a value passed back into PyGILState_Release(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 06:21:19 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 29 Aug 2012 04:21:19 +0000 Subject: [issue15751] Support subinterpreters in the GIL state API In-Reply-To: <1345526301.75.0.455071650321.issue15751@psf.upfronthosting.co.za> Message-ID: <1346214079.25.0.544073228468.issue15751@psf.upfronthosting.co.za> Nick Coghlan added the comment: Currently, both PyGILState_Ensure and PyGILState_Release just call PyFatal_Error if anything goes wrong. With the *Ex versions, it would be possible to replace those fatal errors with more conventional error handling. For Ensure, the likely error is failing to create the thread state. For Release, the likely error is calling it with the system in the wrong state. I think the current API reflects a difference between an extension mindset and an embedding mindset. If those calls go wrong in an extension context, killing the entire application is likely the only thing you can reasonably do. In an embedded context, though, the embedding application likely has other options (such as reinitialising the entire Python interpreter). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 06:26:24 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 29 Aug 2012 04:26:24 +0000 Subject: [issue15805] Add stdout redirection tool to contextlib Message-ID: <1346214384.31.0.130580797931.issue15805@psf.upfronthosting.co.za> New submission from Raymond Hettinger: The technique of temporarily redirecting stdout could be encapsulated in a context manager. print('This goes to stdout') with RedirectStdout(sys.stderr): print('This goes to stderr') print('So does this') print('This goes to stdout') The print function already supports redirection but it much be done for every single call to print(). The context manager let's the redirection apply to a batch of statements. The context manager is also useful with existing tools that don't currently provide output redirection hooks: from collections import namedtuple with open('model.py', 'w') as module: with RedirectStdout(module): namedtuple('Person', ['name', 'age', 'email'], verbose=True) import dis with open('disassembly.txt', 'w') as f: with RedirectStdout(f): dis.dis(myfunc) A possible implementation is: class RedirectStdout: ''' Create a context manager for redirecting sys.stdout to another file. ''' def __init__(self, new_target): self.new_target = new_target def __enter__(self): self.old_target = sys.stdout sys.stdout = self.new_target return self def __exit__(self, exctype, excinst, exctb): sys.stdout = self.old_target ---------- components: Library (Lib) messages: 169335 nosy: rhettinger priority: normal severity: normal status: open title: Add stdout redirection tool to contextlib type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 06:27:10 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 29 Aug 2012 04:27:10 +0000 Subject: [issue15805] Add stdout redirection tool to contextlib In-Reply-To: <1346214384.31.0.130580797931.issue15805@psf.upfronthosting.co.za> Message-ID: <1346214430.29.0.379455760421.issue15805@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> ncoghlan nosy: +ncoghlan priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 06:45:45 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 29 Aug 2012 04:45:45 +0000 Subject: [issue15805] Add stdout redirection tool to contextlib In-Reply-To: <1346214384.31.0.130580797931.issue15805@psf.upfronthosting.co.za> Message-ID: <1346215545.54.0.365571882897.issue15805@psf.upfronthosting.co.za> Nick Coghlan added the comment: We actually use a variant of this idea in the test suite (http://docs.python.org/dev/library/test#test.support.captured_stdout) It would be pretty easy to combine the two concepts by defaulting the redirection to a new StringIO instance if no other destination is given: print('This goes to stdout') with redirect_stdout(sys.stderr): print('This goes to stderr') print('So does this') print('This goes to stdout') with redirect_stdout() as s: print('This goes to the io.StringIO instance "s"') print('So does this') print('This goes to stdout') ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 07:15:15 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 29 Aug 2012 05:15:15 +0000 Subject: [issue15806] Add context manager for the "try: ... except: pass" pattern Message-ID: <1346217315.31.0.832549559428.issue15806@psf.upfronthosting.co.za> New submission from Raymond Hettinger: It is a somewhat common pattern to write: try: do_something() except SomeException: pass To search examples in the standard library (or any other code base) use: $ egrep -C2 "except( [A-Za-z]+)?:" *py | grep -C2 "pass" In the Python2.7 Lib directory alone, we find 213 examples. I suggest a context manager be added that can ignore specifie exceptions. Here's a possible implementation: class Ignore: ''' Context manager to ignore particular exceptions''' def __init__(self, *ignored_exceptions): self.ignored_exceptions = ignored_exceptions def __enter__(self): return self def __exit__(self, exctype, excinst, exctb): return exctype in self.ignored_exceptions The usage would be something like this: with Ignore(IndexError, KeyError): print(s[t]) Here's a real-world example taken from zipfile.py: def _check_zipfile(fp): try: if _EndRecData(fp): return True # file has correct magic number except IOError: pass return False With Ignore() context manager, the code cleans-up nicely: def _check_zipfile(fp): with Ignore(IOError): return bool(EndRecData(fp)) # file has correct magic number return False I think this would make a nice addition to contextlib. ---------- assignee: ncoghlan messages: 169337 nosy: ncoghlan, rhettinger priority: low severity: normal status: open title: Add context manager for the "try: ... except: pass" pattern type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 07:17:41 2012 From: report at bugs.python.org (Alex Gaynor) Date: Wed, 29 Aug 2012 05:17:41 +0000 Subject: [issue15805] Add stdout redirection tool to contextlib In-Reply-To: <1346214384.31.0.130580797931.issue15805@psf.upfronthosting.co.za> Message-ID: <1346217461.84.0.513509040862.issue15805@psf.upfronthosting.co.za> Alex Gaynor added the comment: Sounds like a special case of a small part of mock. Not sure that this observation is significant though. ---------- nosy: +alex _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 07:17:50 2012 From: report at bugs.python.org (Alex Gaynor) Date: Wed, 29 Aug 2012 05:17:50 +0000 Subject: [issue15806] Add context manager for the "try: ... except: pass" pattern In-Reply-To: <1346217315.31.0.832549559428.issue15806@psf.upfronthosting.co.za> Message-ID: <1346217470.51.0.679247786713.issue15806@psf.upfronthosting.co.za> Changes by Alex Gaynor : ---------- nosy: +alex _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 07:22:12 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 29 Aug 2012 05:22:12 +0000 Subject: [issue15805] Add stdout redirection tool to contextlib In-Reply-To: <1346214384.31.0.130580797931.issue15805@psf.upfronthosting.co.za> Message-ID: <1346217732.58.0.853060569558.issue15805@psf.upfronthosting.co.za> Nick Coghlan added the comment: Sure, but by targeting a specific use case you can make it really trivial to use. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 07:35:27 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 29 Aug 2012 05:35:27 +0000 Subject: [issue15806] Add context manager for the "try: ... except: pass" pattern In-Reply-To: <1346217315.31.0.832549559428.issue15806@psf.upfronthosting.co.za> Message-ID: <1346218527.53.0.439956211278.issue15806@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Hmm, the __exit__ method was doing exact matches by exception type, so KeyError wouldn't match LookupError or Exception. There are probably a number of ways to fix this, but it may be easiest to use the builtin exception catching mechanisms: class Ignore: ''' Context manager to ignore particular exceptions''' def __init__(self, *ignored_exceptions): self.ignored_exceptions = ignored_exceptions def __enter__(self): return self def __exit__(self, exctype, excinst, exctb): if exctype is not None: try: raise except self.ignored_exceptions: return True ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 07:55:38 2012 From: report at bugs.python.org (Alex Gaynor) Date: Wed, 29 Aug 2012 05:55:38 +0000 Subject: [issue15806] Add context manager for the "try: ... except: pass" pattern In-Reply-To: <1346217315.31.0.832549559428.issue15806@psf.upfronthosting.co.za> Message-ID: <1346219738.33.0.501682475668.issue15806@psf.upfronthosting.co.za> Alex Gaynor added the comment: Why not just: issubclass(exctype, self.exception_types)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 08:06:15 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 29 Aug 2012 06:06:15 +0000 Subject: [issue15806] Add context manager for the "try: ... except: pass" pattern In-Reply-To: <1346217315.31.0.832549559428.issue15806@psf.upfronthosting.co.za> Message-ID: <1346220375.94.0.150495606189.issue15806@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Yes, something along those lines would be *much* better: class Ignore: ''' Context manager to ignore particular exceptions''' def __init__(self, *ignored_exceptions): self.ignored_exceptions = ignored_exceptions def __enter__(self): return self def __exit__(self, exctype, excinst, exctb): return exctype and issubclass(exctype, self.ignored_exceptions) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 08:20:49 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 29 Aug 2012 06:20:49 +0000 Subject: [issue15806] Add context manager for the "try: ... except: pass" pattern In-Reply-To: <1346217315.31.0.832549559428.issue15806@psf.upfronthosting.co.za> Message-ID: <1346221249.34.0.835780678858.issue15806@psf.upfronthosting.co.za> Nick Coghlan added the comment: I'd just write it with @contextmanager. Making it easier to cleanly factor out exception handling is one of the main reasons that exists. @contextmanager def ignored(*exceptions): """Context manager to ignore particular exceptions""" try: yield except exceptions: pass While the class based version would likely be fractionally faster, the generator based version is more obviously correct. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 08:43:47 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 29 Aug 2012 06:43:47 +0000 Subject: [issue15806] Add context manager for the "try: ... except: pass" pattern In-Reply-To: <1346217315.31.0.832549559428.issue15806@psf.upfronthosting.co.za> Message-ID: <1346222627.86.0.177342335012.issue15806@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 08:54:14 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 29 Aug 2012 06:54:14 +0000 Subject: [issue15804] Feature request, implicit "except : pass" In-Reply-To: <1346204236.32.0.579082427996.issue15804@psf.upfronthosting.co.za> Message-ID: <1346223254.34.0.655503036045.issue15804@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 08:58:21 2012 From: report at bugs.python.org (Ross Lagerwall) Date: Wed, 29 Aug 2012 06:58:21 +0000 Subject: [issue15798] subprocess.Popen() fails if 0, 1 or 2 descriptor is closed In-Reply-To: <1346159030.18.0.947370235022.issue15798@psf.upfronthosting.co.za> Message-ID: <1346223501.64.0.392683913936.issue15798@psf.upfronthosting.co.za> Ross Lagerwall added the comment: It's caused by the following check in _posixsubprocess.c: if (close_fds && errpipe_write < 3) { /* precondition */ PyErr_SetString(PyExc_ValueError, "errpipe_write must be >= 3"); return NULL; } which was written by Gregory P. Smith in 2010 (adding to nosy list). I'm not entirely sure why this check is here, presumably its due to the way close_fds=True is handled. The close fds logic is also hardcoded to close fds from 3 upwards,. ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 09:24:05 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 29 Aug 2012 07:24:05 +0000 Subject: [issue13405] Add DTrace probes In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za> Message-ID: <1346225045.06.0.809850281564.issue13405@psf.upfronthosting.co.za> Ronald Oussoren added the comment: The obvious workaround w.r.t. dtrace not finding the preprocessor is to install the command-line tools for xcode, which you can do from Xcode's preferences. something else to try (before installing the commandline tools): add $(dirname $(xcrun -find cpp)) to the search path of the shell: bash$ PATH="${PATH}:$(dirname $(xcrun -find cpp))" This adds the directory in the Xcode bundle that contains the command-line tools to the search path of the shell, and might make it possible for dtrace to find the preprocessor (depending on how dtrace is coded). If that works this trick could be added to the build process, we already do something similar to locate the compiler in the configure script. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 09:28:43 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 29 Aug 2012 07:28:43 +0000 Subject: [issue15806] Add context manager for the "try: ... except: pass" pattern In-Reply-To: <1346217315.31.0.832549559428.issue15806@psf.upfronthosting.co.za> Message-ID: <1346225323.46.0.20471066352.issue15806@psf.upfronthosting.co.za> Ezio Melotti added the comment: I think I'm -1 on this. This saves two lines, but makes the code less explicit, it can't be used for try/except/else or try/except/except, it requires an extra import, the implementation is simple enough that it doesn't necessary need to be in the stdlib, it might encourage bad style, and it's slower. Some of these downsides are indeed somewhat weak, but the upside of saving two lines is quite weak too IMHO. ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 09:36:21 2012 From: report at bugs.python.org (Stefan Krah) Date: Wed, 29 Aug 2012 07:36:21 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1346225781.19.0.133913261897.issue15573@psf.upfronthosting.co.za> Stefan Krah added the comment: We overlooked one thing. Since hashing is defined in terms of tobytes(), the equality-hash invariant is now broken: >>> from _testbuffer import ndarray >>> x = ndarray([1,2,3], shape=[3], format='f') >>> y = ndarray([1,2,3], shape=[3], format='B') >>> a = memoryview(x) >>> b = memoryview(y) >>> a == b True >>> hash(a) == hash(b) False >>> This is one problem with the new equality definition. It puts "memoryview" firmly into array territory. I'm not saying that's wrong, I even think it was the intention of the PEP authors to have a zero copy "arrayview". Both array.array and numpy.array sidestep the issue by not being hashable. I don't really see a way around all this except doing slow element-wise hashing. ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 09:51:30 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 29 Aug 2012 07:51:30 +0000 Subject: [issue15806] Add context manager for the "try: ... except: pass" pattern In-Reply-To: <1346217315.31.0.832549559428.issue15806@psf.upfronthosting.co.za> Message-ID: <1346226690.57.0.906425811601.issue15806@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I think the zipfile example is really a bad example. IMO, it would best be written as try: return bool(EndRecData(fp)) except IOError: return False i.e. there shouldn't be a pass statement at all in this code, and the if can be dropped whether you use try-except or with. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 09:53:34 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 29 Aug 2012 07:53:34 +0000 Subject: [issue15802] Illegal test for mailbox In-Reply-To: <1346190608.89.0.55767676189.issue15802@psf.upfronthosting.co.za> Message-ID: <1346226814.15.0.973663332517.issue15802@psf.upfronthosting.co.za> Ezio Melotti added the comment: + if int(groups[0]) == int(previous_groups[0]): + self.assertGreaterEqual(int(groups[1]), int(previous_groups[1]), This checks that int(groups[1]) >= int(previous_groups[1]) if int(groups[0]) == int(previous_groups[0]) whereas the previous version (with the int() fixed) checked that int(groups[1]) >= (previous_groups[1]) or groups[0] != groups[1]. Was the previous check nonsensical apart from the wrong usage of int()? Note that even the indexes you used are different (I haven't checked what those values actually are though). ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 10:00:14 2012 From: report at bugs.python.org (Chris Rebert) Date: Wed, 29 Aug 2012 08:00:14 +0000 Subject: [issue15798] subprocess.Popen() fails if 0, 1 or 2 descriptor is closed In-Reply-To: <1346159030.18.0.947370235022.issue15798@psf.upfronthosting.co.za> Message-ID: <1346227214.57.0.925150332568.issue15798@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 10:01:43 2012 From: report at bugs.python.org (Chris Rebert) Date: Wed, 29 Aug 2012 08:01:43 +0000 Subject: [issue15806] Add context manager for the "try: ... except: pass" pattern In-Reply-To: <1346217315.31.0.832549559428.issue15806@psf.upfronthosting.co.za> Message-ID: <1346227303.43.0.221372743099.issue15806@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 10:32:32 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 29 Aug 2012 08:32:32 +0000 Subject: [issue15798] subprocess.Popen() fails if 0, 1 or 2 descriptor is closed In-Reply-To: <1346159030.18.0.947370235022.issue15798@psf.upfronthosting.co.za> Message-ID: <1346229152.07.0.534207180218.issue15798@psf.upfronthosting.co.za> Gregory P. Smith added the comment: easy enough to reproduce... $ ./python.exe -c 'import os, subprocess as s; os.close(0); os.close(1); s.Popen(["/bin/true"])' Traceback (most recent call last): File "", line 1, in File "/Users/gps/python/hg/default/Lib/subprocess.py", line 818, in __init__ restore_signals, start_new_session) File "/Users/gps/python/hg/default/Lib/subprocess.py", line 1363, in _execute_child restore_signals, start_new_session, preexec_fn) ValueError: errpipe_write must be >= 3 Examining the code, it looks like that restriction is to prevent the dup2's for any passed in stdin, stdout or stderr pipes from overwriting errpipe_write in Modules/_posixsubprocess.c's child_exec() function. First guess at a fix: child_exec() needs to detect this situation and dup(errpipe_write) until it gets a fd not in the 0..2 range before the dup2(...) calls that could otherwise blindly clobber it. This could possibly be done by the parent process's _create_pipe() in Lib/subprocess.py when allocating the errpipe_read and errpipe_write fds. Suggested Workaround: for now for any code running into this (Python daemons launching subprocesses?) - Call os.pipe() twice at the start of your program to burn 4 fds. That'll guarantee 0, 1 and 2 will not be used for this pipe. ---------- assignee: -> gregory.p.smith versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 10:46:27 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 Aug 2012 08:46:27 +0000 Subject: [issue15802] Nonsensical test for mailbox In-Reply-To: <1346190608.89.0.55767676189.issue15802@psf.upfronthosting.co.za> Message-ID: <1346229987.5.0.732108937854.issue15802@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, the previous check nonsensical in two cases -- comparing strings and comparing with wrong value. groups[0] -- current seconds (str), groups[1] -- current milliseconds (str), previous_groups[0] -- previous seconds (str), previous_groups[1] -- previous milliseconds (str). As I understand sensible check should be: current seconds >= previous seconds and if current seconds == previous seconds then current milliseconds >= previous milliseconds. In other words, (int(groups[0]), int(groups[1])) >= (int(previous_groups[0]), int(previous_groups[1])). ---------- title: Illegal test for mailbox -> Nonsensical test for mailbox _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 11:12:37 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 29 Aug 2012 09:12:37 +0000 Subject: [issue15751] Support subinterpreters in the GIL state API In-Reply-To: <1346206754.17.0.487622792732.issue15751@psf.upfronthosting.co.za> Message-ID: <1346231342.3380.4.camel@localhost.localdomain> Antoine Pitrou added the comment: Le mercredi 29 ao?t 2012 ? 02:19 +0000, Nick Coghlan a ?crit : > However, it *doesn't* work (at least, not easily) if the extension > itself wants to call back into an interpreter other than the one > already associated with the current thread: > > /* Embedding application (GIL always unlocked) */ > gilstate = PyGILState_EnsureEx(interp_A); > /* Python code and extension code happens */ > /* Callback needs to reach back into a specific interpreter */ > cb_gilstate = PyGILState_EnsureEx(interp_B); > /* Callback runs */ > PyGILState_Release(cb_gilstate); > /* Python code and extension code unwinds */ > PyGILState_Release(gilstate); > > Does that second call to EnsureEx fail? What would it fail? It should simply change the thread state to interp_B's thread state for the current thread. Then the nested PyGILState_Release changes the thread state back to its old value. (of course, I don't understand how an extension running from a given interpreter would have access to another interpreter's callback, but regardless, it's technically not a problem) > If it succeeds, how does the client know which interpreter to use for > the PyGILState_Release call? It could be made to work if > PyGILState_STATE was changed from an enum to a struct that included in > interpreter state pointer, or if EnsureEx returned a different type > and was paired up with a new ReleaseEx pointer. Making PyGILState_STATE a struct sounds reasonable to me. > However, that's starting to get very messy compared to a separate > SwitchInterpreter call: Why messy? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 11:20:17 2012 From: report at bugs.python.org (Ross Lagerwall) Date: Wed, 29 Aug 2012 09:20:17 +0000 Subject: [issue15798] subprocess.Popen() fails if 0, 1 or 2 descriptor is closed In-Reply-To: <1346159030.18.0.947370235022.issue15798@psf.upfronthosting.co.za> Message-ID: <1346232016.94.0.727877649965.issue15798@psf.upfronthosting.co.za> Ross Lagerwall added the comment: The attached patch + test seems to fix the issue. It's not very elegant. ---------- keywords: +patch Added file: http://bugs.python.org/file27042/issue15798.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 11:31:37 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 29 Aug 2012 09:31:37 +0000 Subject: [issue15751] Support subinterpreters in the GIL state API In-Reply-To: <1345526301.75.0.455071650321.issue15751@psf.upfronthosting.co.za> Message-ID: <1346232697.62.0.74205268898.issue15751@psf.upfronthosting.co.za> Nick Coghlan added the comment: Yeah, I eventually came around to agreeing that it's better to stick with the Ensure/Release model. SwitchInterpreter gets messy when it comes to managing the lifecycle of temporary thread states. So an EnsureEx/ReleaseEx pair with a new struct that includes both the GIL state info and either the previous thread state or an interpreter pointer sounds good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 11:43:27 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 29 Aug 2012 09:43:27 +0000 Subject: [issue13370] test_ctypes fails when building python with clang In-Reply-To: <1320761474.93.0.268896325495.issue13370@psf.upfronthosting.co.za> Message-ID: <1346233406.7.0.972148663524.issue13370@psf.upfronthosting.co.za> Changes by Ronald Oussoren : ---------- status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 11:44:57 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 29 Aug 2012 09:44:57 +0000 Subject: [issue14329] proxy_bypass_macosx_sysconf does not handle singel ip addresses correctly In-Reply-To: <1331851754.34.0.615850283155.issue14329@psf.upfronthosting.co.za> Message-ID: <1346233497.8.0.415104181591.issue14329@psf.upfronthosting.co.za> Changes by Ronald Oussoren : ---------- status: open -> pending type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 11:51:28 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 29 Aug 2012 09:51:28 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1346233888.9.0.416084379579.issue15573@psf.upfronthosting.co.za> Nick Coghlan added the comment: Perhaps the hash could just be based on a subset of the items? For example, hash the format, shape and the first and last items? Yes, such an approach means you're more likely to get collisions if you do start hashing these, but that seems better than making hashing itself excessively slow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 11:51:40 2012 From: report at bugs.python.org (Samuel John) Date: Wed, 29 Aug 2012 09:51:40 +0000 Subject: [issue13405] Add DTrace probes In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za> Message-ID: <1346233900.73.0.831293675348.issue13405@psf.upfronthosting.co.za> Samuel John added the comment: dtrace ignores PATH and CC and CPP. I tried that already :/ Of course I could just install the command line tools. But still it's a shame since all the tools are already there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 11:55:28 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 29 Aug 2012 09:55:28 +0000 Subject: [issue15806] Add context manager for the "try: ... except: pass" pattern In-Reply-To: <1346217315.31.0.832549559428.issue15806@psf.upfronthosting.co.za> Message-ID: <1346234128.86.0.598182482519.issue15806@psf.upfronthosting.co.za> Nick Coghlan added the comment: (Note: I'm not yet convinced this is a good idea. I'm definitely considering it, though) As with many context managers, a key benefit here is in the priming effect for readers. In this code: try: # Whatever except (A, B, C): pass the reader doesn't know that (A, B, C) exceptions will be ignored until the end. The with statement form makes it clear before you start reading the code that certain exceptions won't propagate: with ignored(A, B, C): # Whatever I'm not worried that it makes things less explicit - it's pretty obvious what a context manager called "ignored" that accepts an arbitrary number of exceptions is going to do. One other thing it does is interact well with ExitStack - you can stick this in the stack of exit callbacks to suppress exceptions that you don't want to propagate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 12:07:00 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 29 Aug 2012 10:07:00 +0000 Subject: [issue15806] Add context manager for the "try: ... except: pass" pattern In-Reply-To: <1346217315.31.0.832549559428.issue15806@psf.upfronthosting.co.za> Message-ID: <1346234820.07.0.190853043122.issue15806@psf.upfronthosting.co.za> Ezio Melotti added the comment: > As with many context managers, a key benefit here is > in the priming effect for readers. The "focus" is mostly on what it's being executed rather than what it's being ignored though. "Do this operation and ignore these exceptions if they occur" vs. "Ignore these exceptions if they occur while doing this operation." > I'm not worried that it makes things less explicit - it's pretty > obvious what a context manager called "ignored" that accepts an > arbitrary number of exceptions is going to do. It's still understandable, but while I'm familiar with the semantics of try/except, I wouldn't be sure if e.g. this just ignored those specific exceptions or even their subclasses without checking the doc/code. > One other thing it does is interact well with ExitStack - you can > stick this in the stack of exit callbacks to suppress exceptions that > you don't want to propagate. This seems a good use case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 12:09:46 2012 From: report at bugs.python.org (Graham Dumpleton) Date: Wed, 29 Aug 2012 10:09:46 +0000 Subject: [issue15751] Support subinterpreters in the GIL state API In-Reply-To: <1345526301.75.0.455071650321.issue15751@psf.upfronthosting.co.za> Message-ID: <1346234986.51.0.318050168828.issue15751@psf.upfronthosting.co.za> Graham Dumpleton added the comment: If PyGILState_STATE is a struct, what happens if someone naively does: PyGILState_Release(PyGILState_UNLOCKED) I know they shouldn't, but I actually do this in mod_wsgi in one spot as it is otherwise a pain to carry around the state when I know for sure if was unlocked before the PyGILState_Ensure(). Or can PyGILState_UNLOCKED map to some a global struct instance with certain state in it that represents that without problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 12:14:05 2012 From: report at bugs.python.org (Gunnlaugur Thor Briem) Date: Wed, 29 Aug 2012 10:14:05 +0000 Subject: [issue15807] Bogus versionchanged note in logging.handlers.MemoryHandler doc Message-ID: <1346235245.12.0.797988832511.issue15807@psf.upfronthosting.co.za> New submission from Gunnlaugur Thor Briem: In logging.handlers.MemoryHandler documentation: ?Changed in version 2.6: credentials was added.? There's no `credentials` anywhere nearby, and at first glance I can't see anything new in `MemoryHandler` when this was introduced. Presumably the `.. versionchanged::` note just landed there by copy-paste error in 6fb033af9310. ---------- assignee: docs at python components: Documentation messages: 169360 nosy: docs at python, gthb priority: normal severity: normal status: open title: Bogus versionchanged note in logging.handlers.MemoryHandler doc type: enhancement versions: Python 2.6, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 12:16:49 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 29 Aug 2012 10:16:49 +0000 Subject: [issue15807] Bogus versionchanged note in logging.handlers.MemoryHandler doc In-Reply-To: <1346235245.12.0.797988832511.issue15807@psf.upfronthosting.co.za> Message-ID: <1346235409.07.0.466975183236.issue15807@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +vinay.sajip stage: -> needs patch versions: -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 12:22:44 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 29 Aug 2012 10:22:44 +0000 Subject: [issue13405] Add DTrace probes In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za> Message-ID: <1346235764.37.0.280000095342.issue13405@psf.upfronthosting.co.za> Ronald Oussoren added the comment: It's rather annoying that dtrace doesn't honor the PATH variable, and when you run the strings command on /usr/lib/libdtrace.dylib you'll see that it hardcodes the use of gcc (not even cpp or clang). I've filed radar 12196604 in Apple's tracker, although it is unlikely that this will help. BTW. You (Samuel) could also file a bugreport with Apple, the more people do this the higher the change that they will fix this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 12:24:05 2012 From: report at bugs.python.org (Robert Kern) Date: Wed, 29 Aug 2012 10:24:05 +0000 Subject: [issue13405] Add DTrace probes In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za> Message-ID: <1346235845.07.0.761770053082.issue13405@psf.upfronthosting.co.za> Changes by Robert Kern : ---------- nosy: -robert.kern _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 12:39:06 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 29 Aug 2012 10:39:06 +0000 Subject: [issue15802] Nonsensical test for mailbox In-Reply-To: <1346190608.89.0.55767676189.issue15802@psf.upfronthosting.co.za> Message-ID: <1346236746.61.0.51793228014.issue15802@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > In other words, (int(groups[0]), int(groups[1])) >= (int(previous_groups[0]), int(previous_groups[1])). Why not use a single self.assertGreaterEqual() on the pairs (with an appropriate change in the message)? It currently hand-codes the lexicographic comparison, which seems an unnecessary complication (and may have increased the likelihood of error). ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 12:51:10 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 29 Aug 2012 10:51:10 +0000 Subject: [issue15806] Add context manager for the "try: ... except: pass" pattern In-Reply-To: <1346217315.31.0.832549559428.issue15806@psf.upfronthosting.co.za> Message-ID: <1346237470.14.0.520003410596.issue15806@psf.upfronthosting.co.za> Antoine Pitrou added the comment: If this is desirable then I think it would be better as a classmethod of Exception: with KeyError.trap(): do_something() ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 13:08:32 2012 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 29 Aug 2012 11:08:32 +0000 Subject: [issue15806] Add context manager for the "try: ... except: pass" pattern In-Reply-To: <1346217315.31.0.832549559428.issue15806@psf.upfronthosting.co.za> Message-ID: <1346238512.42.0.952760552365.issue15806@psf.upfronthosting.co.za> Eric V. Smith added the comment: While the classmethod version has some appeal, it doesn't extend well to handling multiple exception types. I'm -0 on this, in any event. I think the original code is more clear. Why force people to learn (or recognize) a second idiom for something so simple? ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 13:23:44 2012 From: report at bugs.python.org (Rostyslav Dzinko) Date: Wed, 29 Aug 2012 11:23:44 +0000 Subject: [issue15808] Possibility of setting custom key bindings for "Additional help sources" menu items Message-ID: <1346239424.4.0.436515008596.issue15808@psf.upfronthosting.co.za> New submission from Rostyslav Dzinko: There's a possibility to add additional help sources in IDLE via Options -> Configure IDLE... -> General -> Additional Help Sources Use case: > If someone wants to download certain version of Python documentation in HTML and specify local "index.html" to be opened by custom menu item which appears the in Help menu. Problem: > It's not possible to assign custom hot-key (Options -> Configure IDLE... -> Keys) for such menu items or reassign to that new menu-item, which actually makes sense when talking in context of the use case specified above. This use case was taken from real life (stackoverflow site): http://stackoverflow.com/questions/12174255/linking-offline-documentation-to-idle-linux ---------- components: IDLE messages: 169365 nosy: Rostyslav.Dzinko priority: normal severity: normal status: open title: Possibility of setting custom key bindings for "Additional help sources" menu items type: enhancement versions: 3rd party, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 13:24:08 2012 From: report at bugs.python.org (Rostyslav Dzinko) Date: Wed, 29 Aug 2012 11:24:08 +0000 Subject: [issue15808] Possibility of setting custom key bindings for "Additional help sources" menu items In-Reply-To: <1346239424.4.0.436515008596.issue15808@psf.upfronthosting.co.za> Message-ID: <1346239448.84.0.764033334616.issue15808@psf.upfronthosting.co.za> Changes by Rostyslav Dzinko : ---------- versions: -3rd party _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 13:25:39 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Wed, 29 Aug 2012 11:25:39 +0000 Subject: [issue15784] OSError.__str__() should distinguish between errno and winerror In-Reply-To: <1345920277.5.0.279969365859.issue15784@psf.upfronthosting.co.za> Message-ID: <1346239539.76.0.422074065822.issue15784@psf.upfronthosting.co.za> Richard Oudkerk added the comment: The changeset is 2e587b9bae35. Georg, could you copy it to your release branch please. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 13:31:56 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 29 Aug 2012 11:31:56 +0000 Subject: [issue15800] Closing of sys.std* files in gzip test. In-Reply-To: <1346187126.27.0.0616133533378.issue15800@psf.upfronthosting.co.za> Message-ID: <1346239916.86.0.934201218318.issue15800@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Test? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 13:35:01 2012 From: report at bugs.python.org (Aaron Iles) Date: Wed, 29 Aug 2012 11:35:01 +0000 Subject: [issue15475] Correct __sizeof__ support for itertools In-Reply-To: <1343418242.58.0.256146467281.issue15475@psf.upfronthosting.co.za> Message-ID: <1346240101.65.0.546023931846.issue15475@psf.upfronthosting.co.za> Changes by Aaron Iles : ---------- nosy: +aliles _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 13:38:25 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 29 Aug 2012 11:38:25 +0000 Subject: [issue15806] Add context manager for the "try: ... except: pass" pattern In-Reply-To: <1346217315.31.0.832549559428.issue15806@psf.upfronthosting.co.za> Message-ID: <1346240305.53.0.0947190515167.issue15806@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 13:41:49 2012 From: report at bugs.python.org (Aaron Iles) Date: Wed, 29 Aug 2012 11:41:49 +0000 Subject: [issue13266] Add inspect.unwrap(f) to easily unravel "__wrapped__" chains In-Reply-To: <1319611391.89.0.610441716125.issue13266@psf.upfronthosting.co.za> Message-ID: <1346240509.11.0.340777093875.issue13266@psf.upfronthosting.co.za> Changes by Aaron Iles : ---------- nosy: +aliles _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 13:53:28 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 29 Aug 2012 11:53:28 +0000 Subject: [issue15510] textwrap.wrap('') returns empty list In-Reply-To: <1343697979.41.0.629576632811.issue15510@psf.upfronthosting.co.za> Message-ID: <1346241208.18.0.63595593163.issue15510@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Attaching an updated patch that improves the organization of the new test cases (test ordering, test names, and test comments, etc). ---------- Added file: http://bugs.python.org/file27043/issue-15510-4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 14:02:40 2012 From: report at bugs.python.org (Aaron Iles) Date: Wed, 29 Aug 2012 12:02:40 +0000 Subject: [issue15696] Correct __sizeof__ support for mmap In-Reply-To: <1345145499.47.0.489635799937.issue15696@psf.upfronthosting.co.za> Message-ID: <1346241760.73.0.637139074205.issue15696@psf.upfronthosting.co.za> Changes by Aaron Iles : ---------- nosy: +aliles _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 14:02:45 2012 From: report at bugs.python.org (Aaron Iles) Date: Wed, 29 Aug 2012 12:02:45 +0000 Subject: [issue15695] Correct __sizeof__ support for StgDict In-Reply-To: <1345144416.71.0.984691068113.issue15695@psf.upfronthosting.co.za> Message-ID: <1346241765.96.0.360081758127.issue15695@psf.upfronthosting.co.za> Changes by Aaron Iles : ---------- nosy: +aliles _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 14:02:50 2012 From: report at bugs.python.org (Aaron Iles) Date: Wed, 29 Aug 2012 12:02:50 +0000 Subject: [issue15490] Correct __sizeof__ support for StringIO In-Reply-To: <1343591617.54.0.289047671129.issue15490@psf.upfronthosting.co.za> Message-ID: <1346241770.87.0.602037070204.issue15490@psf.upfronthosting.co.za> Changes by Aaron Iles : ---------- nosy: +aliles _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 14:04:32 2012 From: report at bugs.python.org (Aaron Iles) Date: Wed, 29 Aug 2012 12:04:32 +0000 Subject: [issue15513] Correct __sizeof__ support for pickle In-Reply-To: <1343723739.69.0.648602242607.issue15513@psf.upfronthosting.co.za> Message-ID: <1346241872.76.0.463389770947.issue15513@psf.upfronthosting.co.za> Changes by Aaron Iles : ---------- nosy: +aliles _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 14:04:37 2012 From: report at bugs.python.org (Aaron Iles) Date: Wed, 29 Aug 2012 12:04:37 +0000 Subject: [issue15436] __sizeof__ is not documented In-Reply-To: <1343073282.53.0.774447573036.issue15436@psf.upfronthosting.co.za> Message-ID: <1346241877.75.0.424907026725.issue15436@psf.upfronthosting.co.za> Changes by Aaron Iles : ---------- nosy: +aliles _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 14:41:42 2012 From: report at bugs.python.org (alex hartwig) Date: Wed, 29 Aug 2012 12:41:42 +0000 Subject: =?utf-8?b?W2lzc3VlMTU4MDldINCh0YLRgNC+0LrQuCDQuNC3IElETEUg0L/QvtGB0YI=?= =?utf-8?b?0YPQv9Cw0Y7RgiDQsiDQvdC10LLQtdGA0L3QvtC5INC60L7QtNC40YDQvtCy?= =?utf-8?b?0LrQtS4=?= Message-ID: <1346244102.55.0.0360895602485.issue15809@psf.upfronthosting.co.za> New submission from alex hartwig: ??? ?? IDLE: Python 2.7.2+ (default, Oct 4 2011, 20:03:08) [GCC 4.6.1] on linux2 Type "copyright", "credits" or "license()" for more information. >>> import sys >>> import locale >>> sys.getdefaultencoding() 'ascii' >>> locale.getpreferredencoding() 'UTF-8' >>> s = u'??????? ?????' >>> print s.encode('utf_8') ? ???????????? ?????????? >>> print s.encode('latin1') ??????? ????? ??? ?? ???????: >>> import sys >>> import locale >>> sys.getdefaultencoding() 'ascii' >>> locale.getpreferredencoding() 'UTF-8' >>> s = u'??????? ?????' >>> print s.encode('utf_8') ??????? ????? ---------- components: IDLE files: ??????-2012-08-21 10:37:23.png messages: 169369 nosy: alex.hartwig, asvetlov priority: normal severity: normal status: open title: ?????? ?? IDLE ????????? ? ???????? ?????????. type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file27044/??????-2012-08-21 10:37:23.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 14:56:18 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 29 Aug 2012 12:56:18 +0000 Subject: =?utf-8?b?W2lzc3VlMTU4MDldINCh0YLRgNC+0LrQuCDQuNC3IElETEUg0L/QvtGB0YI=?= =?utf-8?b?0YPQv9Cw0Y7RgiDQsiDQvdC10LLQtdGA0L3QvtC5INC60L7QtNC40YDQvtCy?= =?utf-8?b?0LrQtS4=?= In-Reply-To: <1346244102.55.0.0360895602485.issue15809@psf.upfronthosting.co.za> Message-ID: <1346244978.08.0.991668515316.issue15809@psf.upfronthosting.co.za> Ezio Melotti added the comment: Looks like your IDLE is set to use latin-1, but s.encode('latin1') should have failed with an UnicodeEncodeError. Are you sure you copied the snippet correctly? The default source encoding refers to the .py files you open with IDLE, and doesn't affect the encoding used by IDLE itself while printing. (Please use English to report issues.) ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 14:59:19 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 29 Aug 2012 12:59:19 +0000 Subject: [issue15809] IDLE console uses incorrect encoding. In-Reply-To: <1346244102.55.0.0360895602485.issue15809@psf.upfronthosting.co.za> Message-ID: <1346245159.47.0.87969612002.issue15809@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- title: ?????? ?? IDLE ????????? ? ???????? ?????????. -> IDLE console uses incorrect encoding. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 15:02:41 2012 From: report at bugs.python.org (alex hartwig) Date: Wed, 29 Aug 2012 13:02:41 +0000 Subject: [issue15809] IDLE console uses incorrect encoding. In-Reply-To: <1346244102.55.0.0360895602485.issue15809@psf.upfronthosting.co.za> Message-ID: <1346245361.77.0.829889931061.issue15809@psf.upfronthosting.co.za> alex hartwig added the comment: Text is correct. See attachment. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 15:18:19 2012 From: report at bugs.python.org (Florent Xicluna) Date: Wed, 29 Aug 2012 13:18:19 +0000 Subject: [issue15810] assertSequenceEqual should be fired when comparing sequences Message-ID: <1346246299.41.0.924919509525.issue15810@psf.upfronthosting.co.za> New submission from Florent Xicluna: When writing unittest, I noticed that I need to uses assertSequenceEqual explicitly when comparing sequences of different kinds. If I only use the plain assertEqual, it does not generate pretty diffs. On second thought, I think it could be fixed in unittest to use assertSequenceEqual when isinstance(arg, (tuple, list)) or isinstance(arg, collections.Sequence) is True. ---------- components: Library (Lib), Tests messages: 169372 nosy: flox priority: normal severity: normal status: open title: assertSequenceEqual should be fired when comparing sequences type: behavior versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 15:18:40 2012 From: report at bugs.python.org (David Buxton) Date: Wed, 29 Aug 2012 13:18:40 +0000 Subject: [issue15811] ElementTree.write() raises TypeError when xml_declaration = True and encoding is a unicode string Message-ID: <1346246320.04.0.762260786774.issue15811@psf.upfronthosting.co.za> New submission from David Buxton: The problem is an inconsistency between the ElementTree.write() method on Python 2 and 3 when xml_declaration is True. For Python 2.7 the encoding argument MUST NOT be a unicode string. For Python 3.2 the encoding argument MUST be a unicode string. On Python 2.7.3 (ElementTree 1.3.0) you can only use byte strings as the encoding argument when including the xml declaration. If you use a unicode object you get TypeError thrown: >>> from xml.etree import ElementTree as ET >>> from io import BytesIO >>> >>> tree = ET.ElementTree(ET.Element(u'example')) >>> tree.write(BytesIO(), xml_declaration=True, encoding='utf-8') >>> tree.write(BytesIO(), xml_declaration=True, encoding=u'utf-8') Traceback (most recent call last): File "", line 1, in File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py", line 813, in write write("\n" % encoding) TypeError: 'unicode' does not have the buffer interface So the encoding argument must be a byte string. However on Python 3.2.3 (ElementTree 1.3.0) the same argument must be a unicode string. If you pass a byte string in it raises TypeError. This only happens when you pass in an encoding and xml_declaration=True. This is a (small) problem when writing Py 2/3 compatible code since the version of ElementTree is supposed to be the same. ---------- components: XML messages: 169373 nosy: David.Buxton priority: normal severity: normal status: open title: ElementTree.write() raises TypeError when xml_declaration = True and encoding is a unicode string type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 15:21:08 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 29 Aug 2012 13:21:08 +0000 Subject: [issue15810] assertSequenceEqual should be fired when comparing sequences In-Reply-To: <1346246299.41.0.924919509525.issue15810@psf.upfronthosting.co.za> Message-ID: <1346246468.93.0.854574305021.issue15810@psf.upfronthosting.co.za> R. David Murray added the comment: I think it works as it should (you shouldn't be asserting that a sequence and a tuple are equal, after all). Once you fix your test, you'll get the pretty print if there are still differences. ---------- nosy: +michael.foord, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 15:21:34 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 29 Aug 2012 13:21:34 +0000 Subject: [issue15765] test_getcwd_long_pathnames (in test_posix) kills NetBSD In-Reply-To: <1345644735.97.0.561553846154.issue15765@psf.upfronthosting.co.za> Message-ID: <3X6SCc2l5KzQ3V@mail.python.org> Roundup Robot added the comment: New changeset bfa5d0ddfbeb by Trent Nelson in branch '2.7': Issue #15765: Fix quirky NetBSD getcwd() behaviour. http://hg.python.org/cpython/rev/bfa5d0ddfbeb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 15:21:34 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 29 Aug 2012 13:21:34 +0000 Subject: [issue9185] os.getcwd causes infinite loop on solaris In-Reply-To: <1278492997.35.0.523630408468.issue9185@psf.upfronthosting.co.za> Message-ID: <3X6SCd1dQgzQ3V@mail.python.org> Roundup Robot added the comment: New changeset bfa5d0ddfbeb by Trent Nelson in branch '2.7': Issue #15765: Fix quirky NetBSD getcwd() behaviour. http://hg.python.org/cpython/rev/bfa5d0ddfbeb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 15:22:31 2012 From: report at bugs.python.org (Florent Xicluna) Date: Wed, 29 Aug 2012 13:22:31 +0000 Subject: [issue15811] ElementTree.write() raises TypeError when xml_declaration = True and encoding is a unicode string In-Reply-To: <1346246320.04.0.762260786774.issue15811@psf.upfronthosting.co.za> Message-ID: <1346246551.41.0.789734512209.issue15811@psf.upfronthosting.co.za> Changes by Florent Xicluna : ---------- components: +Library (Lib) nosy: +eli.bendersky, flox _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 15:28:07 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 29 Aug 2012 13:28:07 +0000 Subject: [issue15807] Bogus versionchanged note in logging.handlers.MemoryHandler doc In-Reply-To: <1346235245.12.0.797988832511.issue15807@psf.upfronthosting.co.za> Message-ID: <3X6SMB0PbGzQ95@mail.python.org> Roundup Robot added the comment: New changeset 48f54b6bf0ef by Vinay Sajip in branch '2.7': Closes #15807: Removed incorrect directive from help. http://hg.python.org/cpython/rev/48f54b6bf0ef ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 15:34:07 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 29 Aug 2012 13:34:07 +0000 Subject: [issue15710] logging module crashes in Python 2.7.3 for handler.setLevel(long) In-Reply-To: <1345152839.48.0.661799461902.issue15710@psf.upfronthosting.co.za> Message-ID: <3X6SV663tszPxW@mail.python.org> Roundup Robot added the comment: New changeset 8ba6d8fc9740 by Vinay Sajip in branch '2.7': Closes #15710: accept long in _checkLevel. http://hg.python.org/cpython/rev/8ba6d8fc9740 ---------- nosy: +python-dev resolution: invalid -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 15:34:36 2012 From: report at bugs.python.org (Florent Xicluna) Date: Wed, 29 Aug 2012 13:34:36 +0000 Subject: [issue15810] assertSequenceEqual should be fired when comparing sequences In-Reply-To: <1346246299.41.0.924919509525.issue15810@psf.upfronthosting.co.za> Message-ID: <1346247276.39.0.0827911034485.issue15810@psf.upfronthosting.co.za> Florent Xicluna added the comment: you're probably right. I will continue to use assertSequenceEqual for my use cases. Actually, what confused me is that these assertions are True: class T(tuple): pass class L(list): pass assertEqual(T('ab'), tuple('ab')) assertEqual(L('ab'), list('ab')) And when these tests fail, the output is not pretty formatted. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 15:45:02 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 29 Aug 2012 13:45:02 +0000 Subject: [issue15810] assertSequenceEqual should be fired when comparing sequence subclasses In-Reply-To: <1346246299.41.0.924919509525.issue15810@psf.upfronthosting.co.za> Message-ID: <1346247902.29.0.912025637037.issue15810@psf.upfronthosting.co.za> R. David Murray added the comment: That sounds like a bug. ---------- title: assertSequenceEqual should be fired when comparing sequences -> assertSequenceEqual should be fired when comparing sequence subclasses _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 15:47:03 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 29 Aug 2012 13:47:03 +0000 Subject: [issue15803] Incorrect docstring on ConfigParser.items() In-Reply-To: <1346202745.06.0.103510250689.issue15803@psf.upfronthosting.co.za> Message-ID: <1346248023.32.0.131909032993.issue15803@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +lukasz.langa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 15:47:17 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 29 Aug 2012 13:47:17 +0000 Subject: [issue15803] Incorrect docstring on ConfigParser.items() In-Reply-To: <1346202745.06.0.103510250689.issue15803@psf.upfronthosting.co.za> Message-ID: <1346248037.71.0.750205908676.issue15803@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: -> patch review type: enhancement -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 15:53:22 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 29 Aug 2012 13:53:22 +0000 Subject: [issue15803] Incorrect docstring on ConfigParser.items() In-Reply-To: <1346202745.06.0.103510250689.issue15803@psf.upfronthosting.co.za> Message-ID: <1346248402.92.0.151089221073.issue15803@psf.upfronthosting.co.za> Chris Jerdonek added the comment: This is a nit, but there should be two spaces after the period: + each option in the section. Otherwise, return a list of tuples with ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 15:57:01 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 29 Aug 2012 13:57:01 +0000 Subject: [issue15810] assertSequenceEqual should be fired when comparing sequence subclasses In-Reply-To: <1346246299.41.0.924919509525.issue15810@psf.upfronthosting.co.za> Message-ID: <1346248621.56.0.291293045327.issue15810@psf.upfronthosting.co.za> Ezio Melotti added the comment: The assertSequenceEqual docs[0] say: """ This method is not called directly by assertEqual(), but it?s used to implement assertListEqual() and assertTupleEqual(). """ The asserEqual docs[1] say: """ In addition, if first and second are the exact same type and one of list, tuple, dict, set, frozenset or str or any type that a subclass registers with addTypeEqualityFunc() the type-specific equality function will be called in order to generate a more useful default error message (see also the list of type-specific methods). """ assertEqual[2] calls _getAssertEqualityFunc[3] that checks if type(first) is type(second), so in your case no specific assert function is called, and since you are not comparing objects of the same type, you are not able to use addTypeEqualityFunc() either. I think in this case using assertSequenceEqual() directly is ok. [0]: http://docs.python.org/py3k/library/unittest.html#unittest.TestCase.assertSequenceEqual [1]: http://docs.python.org/py3k/library/unittest.html#unittest.TestCase.assertEqual [2]: http://hg.python.org/cpython/file/124fb2b39ed9/Lib/unittest/case.py#l637 [3]: http://hg.python.org/cpython/file/124fb2b39ed9/Lib/unittest/case.py#l604 ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 15:59:07 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 29 Aug 2012 13:59:07 +0000 Subject: [issue15803] Incorrect docstring on ConfigParser.items() In-Reply-To: <1346202745.06.0.103510250689.issue15803@psf.upfronthosting.co.za> Message-ID: <1346248747.42.0.482467610906.issue15803@psf.upfronthosting.co.za> Ezio Melotti added the comment: While I like to have two spaces after the period, this convenction is not enforced, and it usually depends on the style used in the file. If the double space is used elsewhere in the same document, then it should be preserved, otherwise using a single space is OK too. ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 16:05:54 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 29 Aug 2012 14:05:54 +0000 Subject: [issue15803] Incorrect docstring on ConfigParser.items() In-Reply-To: <1346202745.06.0.103510250689.issue15803@psf.upfronthosting.co.za> Message-ID: <1346249154.89.0.399044584526.issue15803@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > If the double space is used elsewhere in the same document, You can see one above the change in the patch file. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 16:19:12 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 29 Aug 2012 14:19:12 +0000 Subject: [issue15809] IDLE console uses incorrect encoding. In-Reply-To: <1346244102.55.0.0360895602485.issue15809@psf.upfronthosting.co.za> Message-ID: <1346249952.38.0.762248489122.issue15809@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The problem is that IDLE passes an UTF-8 encoded source string to compile, and compile, in the absence of a source encoding, uses the PEP 263 default source encoding, i.e. Latin-1. As the consequence, the variable s has the value u'\\xd0\\xa0\\xd1\\x83\\xd1\\x81\\xd1\\x81\\xd0\\xba\\xd0\\xb8\\xd0\\xb9 \\xd1\\x82\\xd0\\xb5\\xd0\\xba\\xd1\\x81\\xd1\\x82' IDLE's "Default Source Encoding" is irrelevant - it only applies to editor windows. One solution for that is the attached patch. However, this patch isn't right, since it will cause all source to be interpreted as UTF-8. This would be wrong when the sys.stdin.encoding is not UTF-8, and byte string objects are created in interactive mode. Interactive mode manages to get it right by looking up sys.stdin.encoding during compilation, but it does so only when in interactive mode (i.e. when tok->prompt != NULL. I don't see any way to fix this problem in Python 2. It is fixed in Python 3, basically by always assuming that the source encoding is UTF-8, by making all string objects Unicode objects, and disallowing non-ASCII characters in bytes literals ---------- keywords: +patch nosy: +loewis Added file: http://bugs.python.org/file27045/compile_unicode.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 16:23:08 2012 From: report at bugs.python.org (Nathan Trapuzzano) Date: Wed, 29 Aug 2012 14:23:08 +0000 Subject: [issue15803] Incorrect docstring on ConfigParser.items() In-Reply-To: <1346202745.06.0.103510250689.issue15803@psf.upfronthosting.co.za> Message-ID: <1346250188.15.0.49295485886.issue15803@psf.upfronthosting.co.za> Nathan Trapuzzano added the comment: Looks like the file has about an equal number of single- and double-spaces after periods. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 16:54:39 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Wed, 29 Aug 2012 14:54:39 +0000 Subject: [issue15812] inspect.getframeinfo() cannot show first line Message-ID: <1346252079.7.0.669819400342.issue15812@psf.upfronthosting.co.za> New submission from Richard Oudkerk: When inspect.getframeinfo() tries to collect lines of context it never shows the first line (unless context is as big as the number of lines in the file). The relevant code is start = lineno - 1 - context//2 try: lines, lnum = findsource(frame) except IOError: lines = index = None else: --> start = max(start, 1) start = max(0, min(start, len(lines) - context)) lines = lines[start:start+context] index = lineno - 1 - start I think that start = max(start, 1) should be replaced by start = max(start, 0) For some reason getframeinfo() (and the functions which use it) don't seem to be tested by the testsuite... ---------- messages: 169387 nosy: sbt priority: normal severity: normal status: open title: inspect.getframeinfo() cannot show first line _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 17:05:59 2012 From: report at bugs.python.org (Trent Nelson) Date: Wed, 29 Aug 2012 15:05:59 +0000 Subject: [issue9860] Building python outside of source directory fails In-Reply-To: <1284559695.71.0.359508650396.issue9860@psf.upfronthosting.co.za> Message-ID: <1346252759.42.0.753641903816.issue9860@psf.upfronthosting.co.za> Changes by Trent Nelson : ---------- nosy: +trent _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 17:23:07 2012 From: report at bugs.python.org (Stefan Krah) Date: Wed, 29 Aug 2012 15:23:07 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1346253787.31.0.656002715342.issue15573@psf.upfronthosting.co.za> Stefan Krah added the comment: I'm trying to think of an optimization for the native types. It should be possible to cast any native type element to unsigned char and use the truncated value for the bytes hash. Well, for double probably it's required to go from double -> int64_t -> unsigned char, otherwise the first cast is technically undefined for negative values, though it works with gcc. For non-native types and compound types, Nick's suggestion of hashing the shape and a couple of values seems to be the best solution. Should we do anything about this before 3.3.0? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 17:49:23 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 29 Aug 2012 15:49:23 +0000 Subject: [issue15591] when building the extensions, stdout is lost when stdout is redirected In-Reply-To: <1344423177.77.0.190751096511.issue15591@psf.upfronthosting.co.za> Message-ID: <1346255363.05.0.231392084929.issue15591@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 18:08:49 2012 From: report at bugs.python.org (V.E.O) Date: Wed, 29 Aug 2012 16:08:49 +0000 Subject: [issue15813] Python function decorator scope losing variable Message-ID: <1346256529.91.0.837970613737.issue15813@psf.upfronthosting.co.za> New submission from V.E.O: I just learned python @ decorator, it's cool, but soon I found my modified code coming out weird problems. def with_wrapper(param1): def dummy_wrapper(fn): print param1 param1 = 'new' fn(param1) return dummy_wrapper def dummy(): @with_wrapper('param1') def implementation(param2): print param2 dummy() I debug it, it throws out exception at print param1 UnboundLocalError: local variable 'param1' referenced before assignment If I remove param1 = 'new' this line, without any modify operation(link to new object) on variables from outer scope, this routine might working. Is it meaning I only have made one copy of outer scope variables, then make modification? The policy of variable scope towards decorator is different? ---------- components: Interpreter Core messages: 169389 nosy: V.E.O priority: normal severity: normal status: open title: Python function decorator scope losing variable type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 18:11:32 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 29 Aug 2012 16:11:32 +0000 Subject: [issue15813] Python function decorator scope losing variable In-Reply-To: <1346256529.91.0.837970613737.issue15813@psf.upfronthosting.co.za> Message-ID: <1346256692.79.0.485344944467.issue15813@psf.upfronthosting.co.za> R. David Murray added the comment: When you assign a value to param1 it becomes a local variable, thus the error. You should ask for help on your scoping questions from the python-tutor list or the general python-list. ---------- nosy: +r.david.murray resolution: -> invalid stage: -> committed/rejected status: open -> closed type: compile error -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 18:21:08 2012 From: report at bugs.python.org (David Buxton) Date: Wed, 29 Aug 2012 16:21:08 +0000 Subject: [issue15811] ElementTree.write() raises TypeError when xml_declaration = True and encoding is a unicode string In-Reply-To: <1346246320.04.0.762260786774.issue15811@psf.upfronthosting.co.za> Message-ID: <1346257268.15.0.978187650263.issue15811@psf.upfronthosting.co.za> David Buxton added the comment: A patch against the current default branch to add tests for the xml_declaration keyword argument. This passes when applied to the 2.7 branch too. This does NOT test whether one can use both bytes/unicode for the encoding argument. It just uses the native string type for each interpreter. I don't know whether you would actually consider that part of things worth testing yet. ---------- keywords: +patch Added file: http://bugs.python.org/file27046/xml_declaration_test.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 18:34:17 2012 From: report at bugs.python.org (Eli Bendersky) Date: Wed, 29 Aug 2012 16:34:17 +0000 Subject: [issue15811] ElementTree.write() raises TypeError when xml_declaration = True and encoding is a unicode string In-Reply-To: <1346246320.04.0.762260786774.issue15811@psf.upfronthosting.co.za> Message-ID: <1346258057.03.0.0650336568239.issue15811@psf.upfronthosting.co.za> Eli Bendersky added the comment: Thanks for the patch, David. Alas, due to personal reasons I will not be able to work on core Python in the next 2-3 months. I may throw in a review here and there, but that's not a promise ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 18:34:45 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 29 Aug 2012 16:34:45 +0000 Subject: [issue15798] subprocess.Popen() fails if 0, 1 or 2 descriptor is closed In-Reply-To: <1346159030.18.0.947370235022.issue15798@psf.upfronthosting.co.za> Message-ID: <1346258085.46.0.874230536473.issue15798@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Yes, something along the lines of that patch is what I was thinking. BTW, this is only necessary for the errpipe_write fd. errpipe_read is for the parent process. I'm going to do it within _create_pipe so that the optimal _posixsubprocess.cloexec_pipe pipe2() based implementation can be used when possible rather than needing to call _set_cloexec() on the dup'ed fd. There are some recent Linux specific possibilities such as fcntl with F_DUPFD, or better F_DUPFD_CLOEXEC, that would make this a single call. Using that may be overkill for this situation but it looks easy enough while I'm in there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 18:39:51 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 29 Aug 2012 16:39:51 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1346258391.37.0.253602836331.issue15573@psf.upfronthosting.co.za> Martin v. L?wis added the comment: 1. I STRONGLY request to take hashing out of this issue. The only further action that this issue can have is complete reversal of the patch, starting over. Now that the issue has been resolved, a NEW issue arises, namely that hashing is inconsistent with equality. Please re-read the original issue: the objective of supporting unknown formats in memoryview comparisons is achieved. Remember that by reopening the issue, you are blocking the release (since it's still a release blocker). 2. Any significant change to the 3.3.0 code base should, IMO, require an additional release candidate (since the release candidate really ought to be what is going to be released, hence the name, so NO changes between candidate and release). Do you really want to delay the release of Python 3.3 until October because of hashing of memoryview objects (which, AFAICT, only affects bytes objects in the standard library)? 3. I don't think memoryview objects should be hashable at all. No matter what definition of hashing you chose, you likely won't manage to get it consistent with ==. Since a memoryview compares equal with its underlying object, it should also hash equal. 4. (unrelated to hashing, related to the original issue) I think it will be possible to create non-transitive equalities, where A==memoryview(A)==memoryview(B)==B, yet not (A==B) 5. I'm not sure whether the hash of a memoryview will surely be constant (as it should): isn't it possible to create a read-only buffer for a mutable memory block (not PyObject), so that any hashing considering the contents will result in changing hashes? Or, since the hash is cached, couldn't that cause the hash to deviate from ==? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 18:45:16 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 29 Aug 2012 16:45:16 +0000 Subject: [issue15811] ElementTree.write() raises TypeError when xml_declaration = True and encoding is a unicode string In-Reply-To: <1346246320.04.0.762260786774.issue15811@psf.upfronthosting.co.za> Message-ID: <1346258716.15.0.493428155913.issue15811@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Why is it a problem? Encoding must be a text string: encoding='utf-8' works with both Python 2 and 3. Or if you used "from __future__ import unicode_literals", str('utf-8') works as well. ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 19:00:53 2012 From: report at bugs.python.org (David Buxton) Date: Wed, 29 Aug 2012 17:00:53 +0000 Subject: [issue15811] ElementTree.write() raises TypeError when xml_declaration = True and encoding is a unicode string In-Reply-To: <1346246320.04.0.762260786774.issue15811@psf.upfronthosting.co.za> Message-ID: <1346259653.91.0.557485788398.issue15811@psf.upfronthosting.co.za> David Buxton added the comment: Only a problem because I am using unicode_literals and it didn't occur to me to use `str('utf-8')` to get a native string on both 2+3. Much the best solution, thank you. But that is still a little smelly - I think what I want ideally is for ElementTree to accept str or unicode on 2.7. Either way I appreciate this is very low priority and indeed debatable as to whether it is "wrong". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 19:03:57 2012 From: report at bugs.python.org (Mike Hoy) Date: Wed, 29 Aug 2012 17:03:57 +0000 Subject: [issue11776] Constructor signatures missing in types module documentation In-Reply-To: <1302036805.33.0.506634428921.issue11776@psf.upfronthosting.co.za> Message-ID: <1346259837.08.0.571426440568.issue11776@psf.upfronthosting.co.za> Mike Hoy added the comment: This should be all the requested changes. I've gone over the table entries (at least the first one, CodeType, with bitdancer on IRC). I've removed the descriptive language from below the table and added it to the table. Leaving the text below the table to deal with args and some descriptive text that was just too large to really fit into the right column of the table. One question though, do you want: BuiltinFunctionType BuiltinMethodType FrameType GeneratorType GetSetDescriptorType MemberDescriptorType TracebackType To be in the table as well. I'm a bit confused on this part. Just let me know. ---------- Added file: http://bugs.python.org/file27047/complete-patch-with-table-issue-11776.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 19:07:09 2012 From: report at bugs.python.org (Stefan Krah) Date: Wed, 29 Aug 2012 17:07:09 +0000 Subject: [issue15814] memoryview: equality-hash invariant Message-ID: <1346260029.19.0.320505643782.issue15814@psf.upfronthosting.co.za> New submission from Stefan Krah: The new PEP-3118 equality definition from #15573 that is based on element-wise comparisons breaks the equality-hash invariant: >>> from _testbuffer import ndarray >>> x = ndarray([1,2,3], shape=[3], format='f') >>> y = ndarray([1,2,3], shape=[3], format='B') >>> a = memoryview(x) >>> b = memoryview(y) >>> a == b True >>> hash(a) == hash(b) False >>> ---------- assignee: skrah messages: 169398 nosy: Arfrever, christian.heimes, georg.brandl, haypo, loewis, mark.dickinson, meador.inge, ncoghlan, pitrou, skrah priority: normal severity: normal stage: needs patch status: open title: memoryview: equality-hash invariant type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 19:09:27 2012 From: report at bugs.python.org (Stefan Krah) Date: Wed, 29 Aug 2012 17:09:27 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1346260167.71.0.0729087118694.issue15573@psf.upfronthosting.co.za> Stefan Krah added the comment: I agree that this isn't a blocker due to the limited use of memoryview hashing. Tracking this in #15814. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 19:16:39 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 29 Aug 2012 17:16:39 +0000 Subject: [issue15805] Add stdout redirection tool to contextlib In-Reply-To: <1346214384.31.0.130580797931.issue15805@psf.upfronthosting.co.za> Message-ID: <1346260599.65.0.190822585501.issue15805@psf.upfronthosting.co.za> Brett Cannon added the comment: So Alex's point is valid: the examples in the unittest.mock.patch docs shows how to do this (http://docs.python.org/dev/py3k/library/unittest.mock.html#patch). So this could be simplified to: def redirect_stdout(replacement=None): return unittest.mock.patch('sys.stdout', replacement if replacement is not None else io.StringIO()) Now that being said, this is extremely common, so Nick's point of just going ahead and providing the helper makes sense. But I wouldn't put it in contextlib but instead in unittest.mock since it is mocking out sys.stdout. ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 19:48:18 2012 From: report at bugs.python.org (Aleksey Filippov) Date: Wed, 29 Aug 2012 17:48:18 +0000 Subject: [issue15798] subprocess.Popen() fails if 0, 1 or 2 descriptor is closed In-Reply-To: <1346159030.18.0.947370235022.issue15798@psf.upfronthosting.co.za> Message-ID: <1346262498.53.0.389468198935.issue15798@psf.upfronthosting.co.za> Aleksey Filippov added the comment: It may be implemented simplier. fcntl(fd, F_DUPFD_CLOEXEC, min_fd_number) will allocate new fd at least min_fd_number. So, it is not necessary to do a lot of dup() calls. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 19:49:57 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 29 Aug 2012 17:49:57 +0000 Subject: [issue15573] Support unknown formats in memoryview comparisons In-Reply-To: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za> Message-ID: <1346262597.36.0.768415607221.issue15573@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 19:51:48 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 29 Aug 2012 17:51:48 +0000 Subject: [issue15798] subprocess.Popen() fails if 0, 1 or 2 descriptor is closed In-Reply-To: <1346159030.18.0.947370235022.issue15798@psf.upfronthosting.co.za> Message-ID: <1346262708.59.0.500514715785.issue15798@psf.upfronthosting.co.za> Gregory P. Smith added the comment: F_DUPFD_CLOEXEC appears exclusive to modern Linux kernels. Any idea how wide spread support for plain F_DUPFD is? If that is "everywhere" the code I've just whipped up could lose a lot of loops... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 19:54:45 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 29 Aug 2012 17:54:45 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <1346260029.19.0.320505643782.issue15814@psf.upfronthosting.co.za> Message-ID: <1346262885.95.0.511946076589.issue15814@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I think the proper solution is to make memoryview objects unhashable. Any other approach will have flaws of some kind. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 20:01:27 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 29 Aug 2012 18:01:27 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <1346262885.95.0.511946076589.issue15814@psf.upfronthosting.co.za> Message-ID: <1346263077.3344.0.camel@localhost.localdomain> Antoine Pitrou added the comment: > I think the proper solution is to make memoryview objects unhashable. Disagreed. If memoryviews are to be bytes-like objects they should be hashable (at least when readonly). > Any other approach will have flaws of some kind. Not more so than equality between memoryviews. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 20:21:12 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 29 Aug 2012 18:21:12 +0000 Subject: [issue15798] subprocess.Popen() fails if 0, 1 or 2 descriptor is closed In-Reply-To: <1346159030.18.0.947370235022.issue15798@psf.upfronthosting.co.za> Message-ID: <1346264472.12.0.137787965448.issue15798@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Here's my initial fix. If fcntl(errpipe_write, F_DUPFD, 3) is widely available this could be shrunk a bit to avoid the for loop potentially calling dup a few times and tracking the wasted fds to close later. Otherwise if it isn't I'd rather not bother with F_DUPFD as this code takes the optimal path when F_DUPFD_CLOEXEC is supported (true on all modern linux systems) and should cause no harm beyond a couple extra dup and close syscalls otherwise. Note: Linux pipe2() support appears in kernels a few revisions after F_DUPFD_CLOEXEC support so the good behavior when pipe2 exists will be kept in this situation as that also means F_DUPFD_CLOEXEC support should exist. The code will work regardless of that (incase someone has a frankenkernel, or other OSes choose to implement one but not the other). ---------- Added file: http://bugs.python.org/file27048/issue15798-fix-gps01.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 20:39:00 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Wed, 29 Aug 2012 18:39:00 +0000 Subject: [issue13769] json.dump(ensure_ascii=False) return str instead of unicode In-Reply-To: <1326300079.82.0.279410736545.issue13769@psf.upfronthosting.co.za> Message-ID: <1346265540.01.0.50490270015.issue13769@psf.upfronthosting.co.za> Petri Lehtinen added the comment: Attached an updated patch, which is more explicit on what ensure_ascii actually does. ---------- Added file: http://bugs.python.org/file27049/issue13769_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 20:41:28 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 Aug 2012 18:41:28 +0000 Subject: [issue15800] Closing of sys.std* files in gzip test. In-Reply-To: <1346187126.27.0.0616133533378.issue15800@psf.upfronthosting.co.za> Message-ID: <1346265688.32.0.401445400195.issue15800@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I can not imagine how it can be tested. Correction does not affect the current behavior. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 20:59:10 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 29 Aug 2012 18:59:10 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <1346263077.3344.0.camel@localhost.localdomain> Message-ID: <503E667B.8070804@v.loewis.de> Martin v. L?wis added the comment: Am 29.08.12 20:01, schrieb Antoine Pitrou: >> I think the proper solution is to make memoryview objects unhashable. > > Disagreed. If memoryviews are to be bytes-like objects they should be > hashable (at least when readonly). So what specific hash algorithm do you propose? >> Any other approach will have flaws of some kind. > > Not more so than equality between memoryviews. Well, memoryviews now have a definition of equality as discussed in issue15573. You may disagree whether it's a useful definition, but I don't believe it has actual flaws (in the sense that it is incorrect or inconsistent). My claim is that any hash definition for memoryviews will have a *fundamental* flaw, failing to provide the basic property that A==B must imply hash(A)==hash(B), making it actually work incorrectly (when used for its primary application, namely keys in dictionaries). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 21:06:29 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 29 Aug 2012 19:06:29 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <503E667B.8070804@v.loewis.de> Message-ID: <1346266979.3344.1.camel@localhost.localdomain> Antoine Pitrou added the comment: > Am 29.08.12 20:01, schrieb Antoine Pitrou: > >> I think the proper solution is to make memoryview objects unhashable. > > > > Disagreed. If memoryviews are to be bytes-like objects they should be > > hashable (at least when readonly). > > So what specific hash algorithm do you propose? The current algorithm works well in conjunction with bytes objects. > My claim is that any hash definition for memoryviews will have a > *fundamental* flaw, failing to provide the basic property > that A==B must imply hash(A)==hash(B), making it actually work > incorrectly Why is there such a fundamental flaw? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 21:24:44 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 29 Aug 2012 19:24:44 +0000 Subject: [issue15815] Add numerator to ZeroDivisionError messages Message-ID: <1346268284.86.0.294059613354.issue15815@psf.upfronthosting.co.za> New submission from Terry J. Reedy: I propose that we add 'of ####' to all ZeroDivisionError messagesso it is less necessary to use a debugger to add print statements to recover the information currently tossed away. (I also propose to change denominator from 'zero' to '0', '0.0', '0+0j', as appropriate.) >>> 3//0 ... ZeroDivisionError: integer division or modulo by zero # augment to ZeroDivisionError: integer division or modulo of 3 by 0 Similarly for >>> 3 / 0 ZeroDivisionError: division by zero # perhaps this should be 'true division of 3 by 0' >>> 3.0 / 0.0 ZeroDivisionError: float division by zero >>> (3+3j) / (0+0j) ZeroDivisionError: complex division by zero In #7482 it was proposed to make float and complex messages same as int message by adding 'or modulo'. I an not sure why not to do that, or if it was just deferred. Fractions currently print the numerator as part of an invalid numerator / 0 result from *either* construction or division. >>> from fractions import Fraction as F >>> F(3, 0) Traceback (most recent call last): File "", line 1, in F(3, 0) File "C:\Programs\Python33\lib\fractions.py", line 167, in __new__ raise ZeroDivisionError('Fraction(%s, 0)' % numerator) ZeroDivisionError: Fraction(3, 0) # Here, 'Fraction(3, 0)' is invalid input. >>> F(3, 1) / F(0, 1) Traceback (most recent call last): File "", line 1, in F(3, 1) / F(0, 1) File "C:\Programs\Python33\lib\fractions.py", line 367, in forward return monomorphic_operator(a, b) File "C:\Programs\Python33\lib\fractions.py", line 417, in _div a.denominator * b.numerator) File "C:\Programs\Python33\lib\fractions.py", line 167, in __new__ raise ZeroDivisionError('Fraction(%s, 0)' % numerator) ZeroDivisionError: Fraction(3, 0) # Here, 'Fraction(3, 0)' is invalid output. I found this confusing until I worked out the dual meaning. I think ZeroDevisionError: invalid Fraction(3, 0) from construction or division might be a bit clearer. I have not looked at decimals. ---------- components: Interpreter Core messages: 169410 nosy: ezio.melotti, mark.dickinson, terry.reedy priority: normal severity: normal stage: needs patch status: open title: Add numerator to ZeroDivisionError messages type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 21:33:48 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 29 Aug 2012 19:33:48 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <1346266979.3344.1.camel@localhost.localdomain> Message-ID: <503E6E97.3080101@v.loewis.de> Martin v. L?wis added the comment: Am 29.08.12 21:06, schrieb Antoine Pitrou: >> So what specific hash algorithm do you propose? > > The current algorithm works well in conjunction with bytes objects. That's about the only type if works for. >> My claim is that any hash definition for memoryviews will have a >> *fundamental* flaw, failing to provide the basic property >> that A==B must imply hash(A)==hash(B), making it actually work >> incorrectly > > Why is there such a fundamental flaw? The current algorithm is flawed as described in Stefan's original message: two objects compare equal, yet hash different. That means that if you use them as dictionary keys, you may end up with two different values for the "same" key, depending on the size of the dictionary (as the modulo operation in the dictionary still may map the different hashes to the same dictionary slot). In general, since memoryview(obj)==obj, it would be necessary that hash(memoryview(obj))==hash(obj). However, since memoryview cannot know what hashing algorithm obj uses, it cannot compute the hash value with the same algorithm. IOW, hashing is mutually exclusive with comparison with the underlying object, unless you know what the hash algorithm of the underlying object is. So restricting tp_hash to memoryview objects where the underlying object is the bytes type would work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 21:45:18 2012 From: report at bugs.python.org (David Kreuter) Date: Wed, 29 Aug 2012 19:45:18 +0000 Subject: [issue15816] pydoc.py uses a hack that depends on implementation details and breaks help() when __builtin__.__import__ is overwritten. Message-ID: <1346269515.86.0.485633003934.issue15816@psf.upfronthosting.co.za> New submission from David Kreuter: help("compile") # this works import __builtin__ real_import = __import__ __builtin__.__import__ = lambda *a: real_import(*a) help("compile") # this fails The line responsible for this is in pydoc.py around line 300: ... elif exc is ImportError and extract_tb(tb)[-1][2]=='safeimport': ... ---------- components: Library (Lib) messages: 169412 nosy: dkreuter priority: normal severity: normal status: open title: pydoc.py uses a hack that depends on implementation details and breaks help() when __builtin__.__import__ is overwritten. versions: Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 21:51:13 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 29 Aug 2012 19:51:13 +0000 Subject: [issue15816] pydoc.py uses a hack that depends on implementation details and breaks help() when __builtin__.__import__ is overwritten. In-Reply-To: <1346269515.86.0.485633003934.issue15816@psf.upfronthosting.co.za> Message-ID: <1346269873.64.0.960350720619.issue15816@psf.upfronthosting.co.za> R. David Murray added the comment: Replacing __import__ is not supported. That said, this is fixed in 3.3. ---------- nosy: +r.david.murray resolution: -> out of date stage: -> committed/rejected status: open -> closed type: -> behavior versions: +Python 3.3 -Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 21:52:22 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 29 Aug 2012 19:52:22 +0000 Subject: [issue14803] Add feature to allow code execution prior to __main__ invocation In-Reply-To: <1336981419.55.0.280530546632.issue14803@psf.upfronthosting.co.za> Message-ID: <1346269942.34.0.65600841319.issue14803@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 22:02:27 2012 From: report at bugs.python.org (Ned Deily) Date: Wed, 29 Aug 2012 20:02:27 +0000 Subject: [issue15808] Possibility of setting custom key bindings for "Additional help sources" menu items In-Reply-To: <1346239424.4.0.436515008596.issue15808@psf.upfronthosting.co.za> Message-ID: <1346270547.7.0.941949776273.issue15808@psf.upfronthosting.co.za> Ned Deily added the comment: Actually, IDLE does have code to look for an on-disk copy of the html-formatted Python documentation set but the paths are platform-specific and, in the Linux case, are out-of-date for some distributions at least. For Linux platforms it looks for `index.html` in either `/var/www/html/python` or `/usr/share/doc/python-docs-x.y/Doc/`. On current Debian systems, for example, the Python doc package is installed in `/usr/share/doc/pythonx.y-doc/html`. If you install the doc packages and then create a link, IDLE should find the docs off-line when you select `Python Docs` from the `Help` manual. For example, for Python 3.3 you *could* do: sudo aptitude install python3.3-doc sudo mkdir -p /var/www/html/ sudo ln -s /usr/share/doc/python3.3-doc/html python That said, the default locations should be updated. And perhaps a more useful customization would be to add a user configuration option for where to look for the on-disk copy of the docs rather than adding another hot key. (Also, older versions of Python are in security fix mode only.) ---------- nosy: +ned.deily stage: -> needs patch versions: -Python 2.6, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 22:04:10 2012 From: report at bugs.python.org (Stefan Krah) Date: Wed, 29 Aug 2012 20:04:10 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <503E6E97.3080101@v.loewis.de> Message-ID: <20120829200409.GA5001@sleipnir.bytereef.org> Stefan Krah added the comment: Martin v. L??wis wrote: > In general, since memoryview(obj)==obj, it would be necessary that > hash(memoryview(obj))==hash(obj). However, since memoryview cannot > know what hashing algorithm obj uses, it cannot compute the hash > value with the same algorithm. In the memoryview-hash thread on python-dev [1] this objection was addressed by demanding from exporters that they all use: hash(x) == hash(x.tobytes()) Since the previous equality concept was also based on x.tobytes() == y.tobytes(), this wasn't a problem. The new equality definition and any possible new hash definition should probably also be part of the buffer API documentation, since they aren't memoryview specific. [1] http://mail.python.org/pipermail/python-dev/2011-November/114459.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 22:27:31 2012 From: report at bugs.python.org (Stefan Krah) Date: Wed, 29 Aug 2012 20:27:31 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <20120829200409.GA5001@sleipnir.bytereef.org> Message-ID: <20120829202732.GA5197@sleipnir.bytereef.org> Stefan Krah added the comment: And since memory_richcompare() and any potentially compatible hash function are quite tricky to implement by now, perhaps the generally useful parts could be exposed as PyBuffer_RichCompareBool() and PyBuffer_Hash(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 22:50:40 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 29 Aug 2012 20:50:40 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <20120829200409.GA5001@sleipnir.bytereef.org> Message-ID: <503E809D.4010108@v.loewis.de> Martin v. L?wis added the comment: Am 29.08.12 22:04, schrieb Stefan Krah: > In the memoryview-hash thread on python-dev [1] this objection was > addressed by demanding from exporters that they all use: > > hash(x) == hash(x.tobytes()) > > Since the previous equality concept was also based on > x.tobytes() == y.tobytes(), this wasn't a problem. In the light of this requirement, it's even more difficult to ask people that they change their hashing, since some exporters may already comply with that original request. > The new equality definition and any possible new hash definition should > probably also be part of the buffer API documentation, since they > aren't memoryview specific. That's not true: they *are* memoryview-specific. The notion of equality is entirely one of memoryview objects, not of buffers. I still maintain that specifying hashing for memoryviews under the new equality definition is just not feasible, and that we should give up on it (except perhaps supporting the hashing of bytes views). I also question whether it is useful to hash arbitrarily-shaped read-only buffers (along with questioning whether people will actually *have* arbitrarily-shaped read-only buffers). Stefan: please do propose a semantics also along with proposing interfaces. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 23:15:08 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 29 Aug 2012 21:15:08 +0000 Subject: [issue15815] Add numerator to ZeroDivisionError messages In-Reply-To: <1346268284.86.0.294059613354.issue15815@psf.upfronthosting.co.za> Message-ID: <1346274908.79.0.232533141687.issue15815@psf.upfronthosting.co.za> Antoine Pitrou added the comment: What would be the point? Usually you should find out why the denominator is zero, not what the numerator's value is. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 23:32:21 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 29 Aug 2012 21:32:21 +0000 Subject: [issue15815] Add numerator to ZeroDivisionError messages In-Reply-To: <1346268284.86.0.294059613354.issue15815@psf.upfronthosting.co.za> Message-ID: <1346275941.81.0.968388717355.issue15815@psf.upfronthosting.co.za> Terry J. Reedy added the comment: In case the value of the numerator helps find out why the denominator is 0. The example given by Mike Graham on python-ideas, Verbose traceback formatting was def f(a): x = a * 4 y = a - 4 return x / y ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 29 23:35:32 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 29 Aug 2012 21:35:32 +0000 Subject: [issue15815] Add numerator to ZeroDivisionError messages In-Reply-To: <1346275941.81.0.968388717355.issue15815@psf.upfronthosting.co.za> Message-ID: <1346275920.3344.14.camel@localhost.localdomain> Antoine Pitrou added the comment: > In case the value of the numerator helps find out why the denominator > is 0. The example given by Mike Graham on python-ideas, Verbose > traceback formatting was > > def f(a): > x = a * 4 > y = a - 4 > return x / y Well, in this case y == 0 iff a == 4. I don't see how the numerator helps at all. (and besides, it's a rather silly artificial example) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 00:33:56 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 29 Aug 2012 22:33:56 +0000 Subject: [issue15800] Closing of sys.std* files in gzip test. In-Reply-To: <1346187126.27.0.0616133533378.issue15800@psf.upfronthosting.co.za> Message-ID: <3X6hSz2hNgzPpX@mail.python.org> Roundup Robot added the comment: New changeset 0b5ba5f610a9 by Antoine Pitrou in branch '3.2': Issue #15800: fix the closing of input / output files when gzip is used as a script. http://hg.python.org/cpython/rev/0b5ba5f610a9 New changeset be505d22dde8 by Antoine Pitrou in branch 'default': Issue #15800: fix the closing of input / output files when gzip is used as a script. http://hg.python.org/cpython/rev/be505d22dde8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 00:34:22 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 29 Aug 2012 22:34:22 +0000 Subject: [issue15800] Closing of sys.std* files in gzip test. In-Reply-To: <1346187126.27.0.0616133533378.issue15800@psf.upfronthosting.co.za> Message-ID: <1346279662.74.0.518472687933.issue15800@psf.upfronthosting.co.za> Antoine Pitrou added the comment: A simple fix indeed, thank you. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 00:54:16 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 29 Aug 2012 22:54:16 +0000 Subject: [issue15781] test_threaded_import fails with -j4 In-Reply-To: <1345883620.41.0.296577026972.issue15781@psf.upfronthosting.co.za> Message-ID: <1346280856.46.0.295037132624.issue15781@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Looks fixed! ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 01:33:05 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 29 Aug 2012 23:33:05 +0000 Subject: [issue15817] Misc/gdbinit: Expose command documentation to gdb help Message-ID: <1346283185.13.0.0954859318202.issue15817@psf.upfronthosting.co.za> New submission from Alexander Belopolsky: Currently "help user-defined" lists commands defined in Misc/gdbinit without explanations (gdb) help user-defined User-defined commands. The commands in this class are those defined by the user. Use the "define" command to define a command. List of commands: lineno -- User-defined printframe -- User-defined pu -- User-defined pyframe -- User-defined pyframev -- User-defined pyg -- User-defined With attached patch, you get List of commands: lineno -- User-defined printframe -- User-defined pu -- Generally useful macro to print a Unicode string pyframe -- User-defined pyframev -- Print the current frame - verbose pyg -- Prints a representation of the object to stderr pylocals -- Print the local variables of the current frame pyo -- Prints a representation of the object to stderr pystack -- Print the entire Python call stack pystackv -- Print the entire Python call stack - verbose mode This should be further polished, but I wanted to hear from others before spending more effort. ---------- components: Demos and Tools files: gdbinit.diff keywords: patch messages: 169424 nosy: belopolsky priority: normal severity: normal status: open title: Misc/gdbinit: Expose command documentation to gdb help type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file27050/gdbinit.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 01:36:08 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 29 Aug 2012 23:36:08 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <1346260029.19.0.320505643782.issue15814@psf.upfronthosting.co.za> Message-ID: <1346283368.63.0.544975812252.issue15814@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 01:40:01 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 29 Aug 2012 23:40:01 +0000 Subject: [issue15805] Add stdout redirection tool to contextlib In-Reply-To: <1346214384.31.0.130580797931.issue15805@psf.upfronthosting.co.za> Message-ID: <1346283601.7.0.550439651127.issue15805@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 02:26:03 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 30 Aug 2012 00:26:03 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <1346260029.19.0.320505643782.issue15814@psf.upfronthosting.co.za> Message-ID: <1346286363.03.0.00216010554927.issue15814@psf.upfronthosting.co.za> Nick Coghlan added the comment: My perspective is that hashing a memoryview only makes sense when the memoryview is read-only and "m == m.tobytes()" (i.e. it's a C contiguous 1D view of bytes, either because that's what the original object exported as a buffer or because the view has been cast that way) So, I think we should document that restriction in What's New and the memoryview docs for 3.3.0, and actually enforce it in 3.3.1 by raising ValueError from hash(m) when the assumption of a 1D C contiguous bytes view is violated (the "read-only" restriction is already enforced). In previous versions, this constraint didn't need to be explicitly enforced, since memoryview basically treated *everything* as a 1D C contiguous view of bytes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 03:30:35 2012 From: report at bugs.python.org (Ned Deily) Date: Thu, 30 Aug 2012 01:30:35 +0000 Subject: [issue15808] Possibility of setting custom key bindings for "Additional help sources" menu items In-Reply-To: <1346239424.4.0.436515008596.issue15808@psf.upfronthosting.co.za> Message-ID: <1346290235.86.0.120598928631.issue15808@psf.upfronthosting.co.za> Ned Deily added the comment: Here's a patch to update the doc paths to include current ones for Debian/Ubuntu and Fedora. The patch will have to be tweaked a bit for 3.2/2.7 to change sys.base_prefix to sys.prefix. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file27051/issue15808_idle_doc_paths.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 03:40:56 2012 From: report at bugs.python.org (Ned Deily) Date: Thu, 30 Aug 2012 01:40:56 +0000 Subject: [issue15808] Possibility of setting custom key bindings for "Additional help sources" menu items In-Reply-To: <1346239424.4.0.436515008596.issue15808@psf.upfronthosting.co.za> Message-ID: <1346290856.3.0.0502719493993.issue15808@psf.upfronthosting.co.za> Changes by Ned Deily : Removed file: http://bugs.python.org/file27051/issue15808_idle_doc_paths.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 03:42:02 2012 From: report at bugs.python.org (Ned Deily) Date: Thu, 30 Aug 2012 01:42:02 +0000 Subject: [issue15808] Possibility of setting custom key bindings for "Additional help sources" menu items In-Reply-To: <1346239424.4.0.436515008596.issue15808@psf.upfronthosting.co.za> Message-ID: <1346290922.07.0.553517652031.issue15808@psf.upfronthosting.co.za> Changes by Ned Deily : Added file: http://bugs.python.org/file27052/issue15808_idle_doc_paths.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 04:16:48 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 30 Aug 2012 02:16:48 +0000 Subject: [issue13405] Add DTrace probes In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za> Message-ID: <1346293008.47.0.865281594704.issue13405@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: OpenIndiana custom buildbots, 32 and 64 bits, SUCCESFULL: 2.7 branch: 32 bits: http://buildbot.python.org/all/builders/x86%20OpenIndiana%20custom/builds/6 64 bits: http://buildbot.python.org/all/builders/AMD64%20OpenIndiana%20custom/builds/8 3.3 branch: 32 bits: http://buildbot.python.org/all/builders/x86%20OpenIndiana%20custom/builds/7 64 bits: http://buildbot.python.org/all/builders/AMD64%20OpenIndiana%20custom/builds/9 Waiting for Solaris 11 custom buildbot to come online again :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 04:49:48 2012 From: report at bugs.python.org (Josh Kupershmidt) Date: Thu, 30 Aug 2012 02:49:48 +0000 Subject: [issue15818] multiprocessing documentation of Process.exitcode Message-ID: <1346294988.32.0.746763914895.issue15818@psf.upfronthosting.co.za> New submission from Josh Kupershmidt: [I tried to send this as an email to docs at python.org yesterday, but it seems to have gotten eaten, as I don't see the message in the archives.] Hi all, The documentation for the multiprocessing module claims: | Note that the start(), join(), is_alive() and exit_code methods | should only be called by the process that created the process object. Two problems with this description: 1. "exit_code" should be spelled "exitcode" 2. exitcode is an attribute of the Process class, not a method as claimed, since the underlying method is decorated with @property Also, aside from the above documentation issues, if it is true that it's not safe to query the exitcode from a separate process, should the exitcode property method include a check like so: assert self._parent_pid == os.getpid(), 'can only test a child process' since start(), join(), and is_alive() all perform this check? ---------- assignee: docs at python components: Documentation messages: 169428 nosy: docs at python, schmiddy priority: normal severity: normal status: open title: multiprocessing documentation of Process.exitcode versions: Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 07:32:25 2012 From: report at bugs.python.org (Trent Nelson) Date: Thu, 30 Aug 2012 05:32:25 +0000 Subject: [issue15765] test_getcwd_long_pathnames (in test_posix) kills NetBSD In-Reply-To: <1345644735.97.0.561553846154.issue15765@psf.upfronthosting.co.za> Message-ID: <1346304745.61.0.35344351914.issue15765@psf.upfronthosting.co.za> Changes by Trent Nelson : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 08:26:58 2012 From: report at bugs.python.org (Ross Lagerwall) Date: Thu, 30 Aug 2012 06:26:58 +0000 Subject: [issue15798] subprocess.Popen() fails if 0, 1 or 2 descriptor is closed In-Reply-To: <1346159030.18.0.947370235022.issue15798@psf.upfronthosting.co.za> Message-ID: <1346308018.83.0.240030927583.issue15798@psf.upfronthosting.co.za> Ross Lagerwall added the comment: I sent a review through on rietveld; I'm attaching a patch with the changes so that it compiles and passes the tests. ---------- Added file: http://bugs.python.org/file27053/issue15798_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 08:49:22 2012 From: report at bugs.python.org (Trent Nelson) Date: Thu, 30 Aug 2012 06:49:22 +0000 Subject: [issue15819] Unable to build Python out-of-tree when source tree is readonly. Message-ID: <1346309362.14.0.312540957077.issue15819@psf.upfronthosting.co.za> New submission from Trent Nelson: This is somewhat related to Issue #9860. You can't currently build Python out-of-tree when the source directory is readonly. This is because there are a few Parser/pgen/AST/python_asdl.py steps that try and write to $(srcdir). The attached patch fixes this. ---------- assignee: trent files: readonly_src.patch keywords: patch messages: 169430 nosy: trent priority: low severity: normal stage: needs patch status: open title: Unable to build Python out-of-tree when source tree is readonly. type: compile error versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file27054/readonly_src.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 08:49:31 2012 From: report at bugs.python.org (Trent Nelson) Date: Thu, 30 Aug 2012 06:49:31 +0000 Subject: [issue15819] Unable to build Python out-of-tree when source tree is readonly. In-Reply-To: <1346309362.14.0.312540957077.issue15819@psf.upfronthosting.co.za> Message-ID: <1346309371.08.0.83345556522.issue15819@psf.upfronthosting.co.za> Changes by Trent Nelson : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 08:59:28 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 30 Aug 2012 06:59:28 +0000 Subject: [issue15819] Unable to build Python out-of-tree when source tree is readonly. In-Reply-To: <1346309362.14.0.312540957077.issue15819@psf.upfronthosting.co.za> Message-ID: <1346309968.31.0.258919036401.issue15819@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Instead of using "mkdir -p", it should use $(MKDIR_P) (which actually isn't normally "mkdir -p" :-) Other than that, the patch looks fine. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 09:19:42 2012 From: report at bugs.python.org (Trent Nelson) Date: Thu, 30 Aug 2012 07:19:42 +0000 Subject: [issue15819] Unable to build Python out-of-tree when source tree is readonly. In-Reply-To: <1346309362.14.0.312540957077.issue15819@psf.upfronthosting.co.za> Message-ID: <1346311182.39.0.269800800351.issue15819@psf.upfronthosting.co.za> Trent Nelson added the comment: Hmmmmm. Now I'm confused. Is this what you meant? ------------------- % hg diff diff -r 019a2390b014 Makefile.pre.in --- a/Makefile.pre.in Tue Aug 21 23:41:43 2012 +0000 +++ b/Makefile.pre.in Thu Aug 30 07:16:55 2012 +0000 @@ -43,6 +43,8 @@ GNULD= @GNULD@ +MKDIR_P= @MKDIR_P@ + # Shell used by make (some versions default to the login shell, which is bad) SHELL= /bin/sh @@ -223,8 +225,8 @@ ########################################################################## # Grammar -GRAMMAR_H= $(srcdir)/Include/graminit.h -GRAMMAR_C= $(srcdir)/Python/graminit.c +GRAMMAR_H= Include/graminit.h +GRAMMAR_C= Python/graminit.c GRAMMAR_INPUT= $(srcdir)/Grammar/Grammar @@ -266,9 +268,9 @@ ########################################################################## # AST -AST_H_DIR= $(srcdir)/Include +AST_H_DIR= Include AST_H= $(AST_H_DIR)/Python-ast.h -AST_C_DIR= $(srcdir)/Python +AST_C_DIR= Python AST_C= $(AST_C_DIR)/Python-ast.c AST_ASDL= $(srcdir)/Parser/Python.asdl @@ -605,9 +607,11 @@ Parser/pgenmain.o: $(srcdir)/Include/parsetok.h $(AST_H): $(AST_ASDL) $(ASDLGEN_FILES) + $(MKDIR_P) $(AST_H_DIR) $(ASDLGEN) -h $(AST_H_DIR) $(AST_ASDL) $(AST_C): $(AST_ASDL) $(ASDLGEN_FILES) + $(MKDIR_P) $(AST_C_DIR) $(ASDLGEN) -c $(AST_C_DIR) $(AST_ASDL) Python/compile.o Python/symtable.o Python/ast.o: $(GRAMMAR_H) $(AST_H) diff -r 019a2390b014 configure --- a/configure Tue Aug 21 23:41:43 2012 +0000 +++ b/configure Thu Aug 30 07:16:55 2012 +0000 @@ -658,6 +658,7 @@ GNULD LINKCC LDVERSION +MKDIR_P RUNSHARED INSTSONAME LDLIBRARYDIR @@ -5262,6 +5263,7 @@ HGBRANCH="" fi +MKDIR_P="mkdir -p" DISABLE_ASDLGEN="" # Extract the first word of "python", so it can be a program name with args. ------------------- Given your "which actually isn't normally mkdir -p" comment... my patch doesn't seem right. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 09:28:16 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 30 Aug 2012 07:28:16 +0000 Subject: [issue15819] Unable to build Python out-of-tree when source tree is readonly. In-Reply-To: <1346311182.39.0.269800800351.issue15819@psf.upfronthosting.co.za> Message-ID: <503F160D.1060703@v.loewis.de> Martin v. L?wis added the comment: Am 30.08.12 09:19, schrieb Trent Nelson: > Hmmmmm. Now I'm confused. Is this what you meant? No. Makefile.pre.in *already* has a definition of MKDIR_P, no need to add one. ---------- title: Unable to build Python out-of-tree when source tree is readonly. -> Unable to build Python out-of-tree when source tree is readonly. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 09:30:10 2012 From: report at bugs.python.org (Trent Nelson) Date: Thu, 30 Aug 2012 07:30:10 +0000 Subject: [issue15819] Unable to build Python out-of-tree when source tree is readonly. In-Reply-To: <1346309362.14.0.312540957077.issue15819@psf.upfronthosting.co.za> Message-ID: <1346311810.11.0.193554939953.issue15819@psf.upfronthosting.co.za> Trent Nelson added the comment: That's what I figured you meant initially... Until I couldn't find any MKDIR_P definitions, and couldn't get it working without the hack above. I thought it might be an implicit make variable as well, but, not so much. (Tested with BSD make and gmake on FreeBSD.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 09:34:06 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Thu, 30 Aug 2012 07:34:06 +0000 Subject: [issue15819] Unable to build Python out-of-tree when source tree is readonly. In-Reply-To: <1346309362.14.0.312540957077.issue15819@psf.upfronthosting.co.za> Message-ID: <1346312046.85.0.2841796959.issue15819@psf.upfronthosting.co.za> Petri Lehtinen added the comment: In 3.3, Makefile.pre.in already defines MKDIR_P, in 3.2 it doesn't. ---------- nosy: +petri.lehtinen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 09:45:41 2012 From: report at bugs.python.org (Mike Hoy) Date: Thu, 30 Aug 2012 07:45:41 +0000 Subject: [issue15820] Add additional info to Resources area on Dev Guide Message-ID: <1346312741.02.0.319894267547.issue15820@psf.upfronthosting.co.za> New submission from Mike Hoy: I wrote a patch which adds more info the devguide under Resources: http://docs.python.org/devguide/index.html#resources ---------- messages: 169436 nosy: mikehoy priority: normal severity: normal status: open title: Add additional info to Resources area on Dev Guide versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 09:46:29 2012 From: report at bugs.python.org (Mike Hoy) Date: Thu, 30 Aug 2012 07:46:29 +0000 Subject: [issue15820] Add additional info to Resources area on Dev Guide In-Reply-To: <1346312741.02.0.319894267547.issue15820@psf.upfronthosting.co.za> Message-ID: <1346312789.48.0.360336589135.issue15820@psf.upfronthosting.co.za> Changes by Mike Hoy : ---------- keywords: +patch Added file: http://bugs.python.org/file27055/devguide-resources.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 09:47:24 2012 From: report at bugs.python.org (Trent Nelson) Date: Thu, 30 Aug 2012 07:47:24 +0000 Subject: [issue15819] Unable to build Python out-of-tree when source tree is readonly. In-Reply-To: <1346309362.14.0.312540957077.issue15819@psf.upfronthosting.co.za> Message-ID: <1346312844.35.0.0776093206928.issue15819@psf.upfronthosting.co.za> Trent Nelson added the comment: Ah, I see the MKDIR_P changes in 3.x/configure as well. Objections to backporting to 3.2? Is 2.7 off the table? (Building from a readonly source is handy for Snakebite; saves having a dozen machines needing to use their own hg clone.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 09:56:26 2012 From: report at bugs.python.org (Mike Hoy) Date: Thu, 30 Aug 2012 07:56:26 +0000 Subject: [issue15820] Add additional info to Resources area on Dev Guide In-Reply-To: <1346312741.02.0.319894267547.issue15820@psf.upfronthosting.co.za> Message-ID: <1346313386.77.0.193546222829.issue15820@psf.upfronthosting.co.za> Changes by Mike Hoy : Added file: http://bugs.python.org/file27056/devguide-resources-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 09:57:21 2012 From: report at bugs.python.org (Mike Hoy) Date: Thu, 30 Aug 2012 07:57:21 +0000 Subject: [issue15820] Add additional info to Resources area on Dev Guide In-Reply-To: <1346312741.02.0.319894267547.issue15820@psf.upfronthosting.co.za> Message-ID: <1346313441.86.0.0196123100142.issue15820@psf.upfronthosting.co.za> Mike Hoy added the comment: I changed the wording a bit and added a few more things. The second one is the one I prefer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 10:37:49 2012 From: report at bugs.python.org (Mike Hoy) Date: Thu, 30 Aug 2012 08:37:49 +0000 Subject: [issue15820] Add additional info to Resources area on Dev Guide In-Reply-To: <1346312741.02.0.319894267547.issue15820@psf.upfronthosting.co.za> Message-ID: <1346315869.59.0.762648642466.issue15820@psf.upfronthosting.co.za> Mike Hoy added the comment: I'm working on a new patch with Ezio. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 11:24:49 2012 From: report at bugs.python.org (Stefan Krah) Date: Thu, 30 Aug 2012 09:24:49 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <503E809D.4010108@v.loewis.de> Message-ID: <20120830092448.GA10805@sleipnir.bytereef.org> Stefan Krah added the comment: Martin v. L??wis wrote: > > hash(x) == hash(x.tobytes()) > In the light of this requirement, it's even more difficult to ask > people that they change their hashing, since some exporters may already > comply with that original request. I don't think so. memoryview.__hash__() is new in 3.3 and the requirement is not documented at all in the general PEP-3118 sections. [Adding Stefan Behnel to nosy, since Cython is pretty quick to pick up new features.] > > The new equality definition and any possible new hash definition should > > probably also be part of the buffer API documentation, since they > > aren't memoryview specific. > > That's not true: they *are* memoryview-specific. The notion of equality > is entirely one of memoryview objects, not of buffers. Could you name a part of the equality definition that is memoryview-specific? > I still maintain that specifying hashing for memoryviews under the > new equality definition is just not feasible, and that we should give > up on it (except perhaps supporting the hashing of bytes views). > I also question whether it is useful to hash arbitrarily-shaped > read-only buffers (along with questioning whether people will actually > *have* arbitrarily-shaped read-only buffers). Useful, perhaps. I don't know if it is worth the effort though. We could restrict hashing to contiguous bytes views in 3.3.1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 11:26:10 2012 From: report at bugs.python.org (Stefan Krah) Date: Thu, 30 Aug 2012 09:26:10 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <1346260029.19.0.320505643782.issue15814@psf.upfronthosting.co.za> Message-ID: <1346318770.92.0.259762072455.issue15814@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: +scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 11:26:31 2012 From: report at bugs.python.org (Mike Hoy) Date: Thu, 30 Aug 2012 09:26:31 +0000 Subject: [issue15820] Add additional info to Resources area on Dev Guide In-Reply-To: <1346312741.02.0.319894267547.issue15820@psf.upfronthosting.co.za> Message-ID: <1346318791.91.0.915064068213.issue15820@psf.upfronthosting.co.za> Mike Hoy added the comment: This patch adds a link from: http://docs.python.org/devguide/index.html#resources To: http://docs.python.org/devguide/docquality.html#helping-with-the-developer-s-guide ---------- Added file: http://bugs.python.org/file27057/devguide-resources-3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 11:32:18 2012 From: report at bugs.python.org (Mike Hoy) Date: Thu, 30 Aug 2012 09:32:18 +0000 Subject: [issue15820] Add additional info to Resources area on Dev Guide In-Reply-To: <1346312741.02.0.319894267547.issue15820@psf.upfronthosting.co.za> Message-ID: <1346319138.15.0.11400837338.issue15820@psf.upfronthosting.co.za> Mike Hoy added the comment: It was determined by Ezio that the previous patches had too much information about how to open a browser, or install python-sphynx on a debian system. It was just out of scope for the docs (people should know how to use their package management systems, etc). We worked out that it was best to just use the existing docs for stuff like hg clone... and leave out the sudo apt-get install python-sphynx. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 11:53:08 2012 From: report at bugs.python.org (Stefan Krah) Date: Thu, 30 Aug 2012 09:53:08 +0000 Subject: [issue15821] Improve docs for PyMemoryView_FromBuffer() Message-ID: <1346320388.88.0.494685067241.issue15821@psf.upfronthosting.co.za> New submission from Stefan Krah: People are using PyMemoryView_FromBuffer() to create and return permanent memoryviews from buffers that are allocated on the stack. See: http://stackoverflow.com/questions/8123121/how-to-get-back-a-valid-object-from-python-in-c-while-this-object-has-been-con The docs should perhaps warn against this. ---------- assignee: docs at python components: Documentation messages: 169443 nosy: belopolsky, docs at python, ncoghlan, pitrou, skrah priority: normal severity: normal status: open title: Improve docs for PyMemoryView_FromBuffer() type: enhancement versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 12:00:06 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 30 Aug 2012 10:00:06 +0000 Subject: [issue15819] Unable to build Python out-of-tree when source tree is readonly. In-Reply-To: <1346312844.35.0.0776093206928.issue15819@psf.upfronthosting.co.za> Message-ID: <503F39A4.60805@v.loewis.de> Martin v. L?wis added the comment: Am 30.08.12 09:47, schrieb Trent Nelson: > Objections to backporting to 3.2? > > Is 2.7 off the table? No, adding AC_PROG_MKDIR_P into all of them is fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 12:05:26 2012 From: report at bugs.python.org (=?utf-8?q?Tomi_Pievil=C3=A4inen?=) Date: Thu, 30 Aug 2012 10:05:26 +0000 Subject: [issue15822] Python 3.3 creates lib2to3 grammar in wrong order Message-ID: <1346321126.73.0.788135574831.issue15822@psf.upfronthosting.co.za> New submission from Tomi Pievil?inen: Python 3.3rc1 source install modifies/installs lib2to3/Grammar.txt after modifying Grammar3.3.0.candidate.1.pickle: -rw-r--r--. 1 root root 6589 2012-08-27 13:25:33.190414570 +0300 Grammar.txt -rw-r--r--. 1 root root 20622 2012-08-27 13:25:33.150477192 +0300 Grammar3.3.0.candidate.1.pickle This causes lib2to3/pgen2/driver:load_grammar to try to recreate the pickle (the _newer call on line 119 returns false), which triggers SandboxViolation in when using easy_install/distribute (https://bitbucket.org/tarek/distribute/issue/317/easy_install-fails-with-sandboxviolation) see . ---------- components: 2to3 (2.x to 3.x conversion tool) messages: 169445 nosy: tpievila priority: normal severity: normal status: open title: Python 3.3 creates lib2to3 grammar in wrong order type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 12:14:33 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 30 Aug 2012 10:14:33 +0000 Subject: [issue15724] Add "versionchanged" to memoryview docs In-Reply-To: <1345377223.09.0.176185074566.issue15724@psf.upfronthosting.co.za> Message-ID: <3X701M4XX1zPsv@mail.python.org> Roundup Robot added the comment: New changeset 34e8c06f7e55 by Stefan Krah in branch 'default': Issue #15724: Add versionchanged tags to the memoryview documentation. http://hg.python.org/cpython/rev/34e8c06f7e55 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 12:36:50 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 30 Aug 2012 10:36:50 +0000 Subject: [issue15798] subprocess.Popen() fails if 0, 1 or 2 descriptor is closed In-Reply-To: <1346159030.18.0.947370235022.issue15798@psf.upfronthosting.co.za> Message-ID: <1346323010.66.0.853934841949.issue15798@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I haven't tested Ross's latest patch, but it looks ok to me. ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 12:39:42 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 30 Aug 2012 10:39:42 +0000 Subject: [issue10650] decimal.py: quantize(): excess digits with watchexp=0 In-Reply-To: <1291816575.32.0.784106881295.issue10650@psf.upfronthosting.co.za> Message-ID: <3X70ZN75dCzQ52@mail.python.org> Roundup Robot added the comment: New changeset 7db16ff9f5fd by Stefan Krah in branch 'default': Closes #10650: Deprecate the watchexp parameter of Decimal.quantize(). http://hg.python.org/cpython/rev/7db16ff9f5fd ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 12:43:32 2012 From: report at bugs.python.org (Stefan Krah) Date: Thu, 30 Aug 2012 10:43:32 +0000 Subject: [issue15724] Add "versionchanged" to memoryview docs In-Reply-To: <1345377223.09.0.176185074566.issue15724@psf.upfronthosting.co.za> Message-ID: <1346323412.81.0.598970636939.issue15724@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 12:55:05 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 30 Aug 2012 10:55:05 +0000 Subject: [issue15798] subprocess.Popen() fails if 0, 1 or 2 descriptor is closed In-Reply-To: <1346159030.18.0.947370235022.issue15798@psf.upfronthosting.co.za> Message-ID: <1346324105.25.0.681894887483.issue15798@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 12:56:42 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Thu, 30 Aug 2012 10:56:42 +0000 Subject: [issue15818] multiprocessing documentation of Process.exitcode In-Reply-To: <1346294988.32.0.746763914895.issue15818@psf.upfronthosting.co.za> Message-ID: <1346324202.15.0.86261550131.issue15818@psf.upfronthosting.co.za> Changes by Richard Oudkerk : ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 13:08:03 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Thu, 30 Aug 2012 11:08:03 +0000 Subject: [issue15798] subprocess.Popen() fails if 0, 1 or 2 descriptor is closed In-Reply-To: <1346159030.18.0.947370235022.issue15798@psf.upfronthosting.co.za> Message-ID: <1346324883.43.0.00849503772382.issue15798@psf.upfronthosting.co.za> Richard Oudkerk added the comment: Would it simplify matters to stop treating 0,1,2 specially and just add them to pass_fds instead? ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 13:24:30 2012 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 30 Aug 2012 11:24:30 +0000 Subject: [issue15616] logging.FileHandler not correctly created with PyYaml (unpickling problems?) In-Reply-To: <1344595757.56.0.0377955516485.issue15616@psf.upfronthosting.co.za> Message-ID: <1346325870.24.0.855209861729.issue15616@psf.upfronthosting.co.za> Changes by Vinay Sajip : ---------- status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 13:35:32 2012 From: report at bugs.python.org (Stefan Krah) Date: Thu, 30 Aug 2012 11:35:32 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <1346260029.19.0.320505643782.issue15814@psf.upfronthosting.co.za> Message-ID: <1346326532.07.0.160514387659.issue15814@psf.upfronthosting.co.za> Stefan Krah added the comment: Here's a doc patch restricting the hash to formats 'B', 'b' and 'c'. I think non-contiguous views are fine: both __eq__() and tobytes() handle these, so the equality-hash invariant is preserved. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 13:36:02 2012 From: report at bugs.python.org (Stefan Krah) Date: Thu, 30 Aug 2012 11:36:02 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <1346260029.19.0.320505643782.issue15814@psf.upfronthosting.co.za> Message-ID: <1346326562.29.0.491201558374.issue15814@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- keywords: +patch Added file: http://bugs.python.org/file27058/issue15814-doc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 15:01:52 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 30 Aug 2012 13:01:52 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <20120830092448.GA10805@sleipnir.bytereef.org> Message-ID: <503F643D.5060507@v.loewis.de> Martin v. L?wis added the comment: Am 30.08.12 11:24, schrieb Stefan Krah: >>> The new equality definition and any possible new hash definition should >>> probably also be part of the buffer API documentation, since they >>> aren't memoryview specific. >> >> That's not true: they *are* memoryview-specific. The notion of equality >> is entirely one of memoryview objects, not of buffers. > > Could you name a part of the equality definition that is memoryview-specific? As literally spelled out, it starts with "a memoryview and a PEP 3118 exporter". But I was actually thinking of the implementation... In any case, I'm skeptical that this is a useful extension to the buffer interface. You would imply "two exporters are equal iff their exported buffers are equal". I think this is asking too much. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 15:35:27 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 30 Aug 2012 13:35:27 +0000 Subject: [issue15822] Python 3.3 creates lib2to3 grammar in wrong order In-Reply-To: <1346321126.73.0.788135574831.issue15822@psf.upfronthosting.co.za> Message-ID: <1346333727.34.0.284009848206.issue15822@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +benjamin.peterson, georg.brandl priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 15:39:04 2012 From: report at bugs.python.org (Stefan Krah) Date: Thu, 30 Aug 2012 13:39:04 +0000 Subject: [issue15821] Improve docs for PyMemoryView_FromBuffer() In-Reply-To: <1346320388.88.0.494685067241.issue15821@psf.upfronthosting.co.za> Message-ID: <1346333944.53.0.237978097972.issue15821@psf.upfronthosting.co.za> Stefan Krah added the comment: This may be a bigger problem (grep for image_surface_get_data): http://lists.cairographics.org/archives/cairo/2011-December/022563.html The previous semantics for PyMemoryView_FromBuffer(view) were: 1) If non-NULL, steal the view.obj reference with automatic decrement in PyBuffer_Release(). 2) Copy shape and strides to view.smalltable. The new semantics for PyMemoryView_FromBuffer(view) are: 1) If non-NULL, treat view.obj as a borrowed reference. 2) Rely on the fact that shape and strides won't disappear. 2) means that returning PyMemoryView_FromBuffer(view) from a view allocated on the stack is no longer safe. In all instances people could migrate to PyMemoryView_FromMemory(), which is both safe and more convenient, but code may be broken. PyManaged_Buffer is designed to expect buffers from exporters, where it is guaranteed that the buffers won't disappear,so it won't be easy to keep backwards compatibility. ---------- priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 15:54:36 2012 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 30 Aug 2012 13:54:36 +0000 Subject: [issue15776] Allow pyvenv to work in existing directory In-Reply-To: <1345799746.88.0.728928529816.issue15776@psf.upfronthosting.co.za> Message-ID: <1346334876.36.0.270254498048.issue15776@psf.upfronthosting.co.za> Changes by Vinay Sajip : ---------- nosy: +carljm _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 15:59:48 2012 From: report at bugs.python.org (karl) Date: Thu, 30 Aug 2012 13:59:48 +0000 Subject: [issue15799] httplib client and statusline In-Reply-To: <1346185891.22.0.123491218752.issue15799@psf.upfronthosting.co.za> Message-ID: <1346335188.65.0.431779370116.issue15799@psf.upfronthosting.co.za> karl added the comment: So what do we do with it? Do I created a patch or do we close that bug? :) No hard feelings about it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 16:02:31 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 30 Aug 2012 14:02:31 +0000 Subject: [issue15799] httplib client and statusline In-Reply-To: <1346185891.22.0.123491218752.issue15799@psf.upfronthosting.co.za> Message-ID: <1346335351.25.0.4099082089.issue15799@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Well, I'd like to hear Senthil's opinion, since he's the main http / urllib maintainer these days. ---------- versions: +Python 3.3 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 16:06:31 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 30 Aug 2012 14:06:31 +0000 Subject: [issue15799] httplib client and statusline In-Reply-To: <1346185891.22.0.123491218752.issue15799@psf.upfronthosting.co.za> Message-ID: <1346335591.9.0.692177739666.issue15799@psf.upfronthosting.co.za> R. David Murray added the comment: I'm inclined to think it isn't worth the effort, myself. I think a "validating" client would be a valuable tool, but that that isn't what the stdlib is focused on. But yes, let's hear Senthil's opinion. (That said, I am in fact adding a lot of validation capabilities to the email package...but in general those are only a matter of exposing the information about parsing failures that the code then has to recover from, rather than adding extra parsing to detect non-compliance.) ---------- versions: +Python 3.2 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 16:14:22 2012 From: report at bugs.python.org (Nikolay Golub) Date: Thu, 30 Aug 2012 14:14:22 +0000 Subject: [issue15823] argparse produces error when multiply help lines Message-ID: <1346336062.37.0.78121639083.issue15823@psf.upfronthosting.co.za> New submission from Nikolay Golub: When i use this code: parser.add_argument('-r', '--range', action = 'store', dest = 'ranges', nargs = 2, metavar = 'RANGE', required = False, help = 'Start and end range date and time for report data.'\ 'Timeformat is %y-%m-%d %H:%M:%S'\ 'for example -r "2012-08-20 14:48:39 "2012-08-25 15:35:00"' ) I get this error: Traceback (most recent call last): File "./create_report.py", line 166, in main() File "./create_report.py", line 123, in main args = parser.parse_args() File "/usr/lib/python2.7/argparse.py", line 1688, in parse_args args, argv = self.parse_known_args(args, namespace) File "/usr/lib/python2.7/argparse.py", line 1720, in parse_known_args namespace, args = self._parse_known_args(args, namespace) File "/usr/lib/python2.7/argparse.py", line 1926, in _parse_known_args start_index = consume_optional(start_index) File "/usr/lib/python2.7/argparse.py", line 1866, in consume_optional take_action(action, args, option_string) File "/usr/lib/python2.7/argparse.py", line 1794, in take_action action(self, namespace, argument_values, option_string) File "/usr/lib/python2.7/argparse.py", line 994, in __call__ parser.print_help() File "/usr/lib/python2.7/argparse.py", line 2313, in print_help self._print_message(self.format_help(), file) File "/usr/lib/python2.7/argparse.py", line 2287, in format_help return formatter.format_help() File "/usr/lib/python2.7/argparse.py", line 279, in format_help help = self._root_section.format_help() File "/usr/lib/python2.7/argparse.py", line 209, in format_help func(*args) File "/usr/lib/python2.7/argparse.py", line 209, in format_help func(*args) File "/usr/lib/python2.7/argparse.py", line 515, in _format_action help_text = self._expand_help(action) File "/usr/lib/python2.7/argparse.py", line 601, in _expand_help return self._get_help_string(action) % params ValueError: unsupported format character 'y' (0x79) at index 65 i think that it sin't normal. i always cut strings like these, according to pep8 ---------- components: Library (Lib) messages: 169456 nosy: Nikolay.Golub priority: normal severity: normal status: open title: argparse produces error when multiply help lines versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 16:23:53 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 30 Aug 2012 14:23:53 +0000 Subject: [issue15823] argparse produces error when multiply help lines In-Reply-To: <1346336062.37.0.78121639083.issue15823@psf.upfronthosting.co.za> Message-ID: <1346336633.08.0.949372950169.issue15823@psf.upfronthosting.co.za> R. David Murray added the comment: The problem is the timeformat. % codes are used to include data into the strings, so if you want a literal % in the help string, you need to double it. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 16:24:16 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 30 Aug 2012 14:24:16 +0000 Subject: [issue15823] argparse produces error when multiply help lines In-Reply-To: <1346336062.37.0.78121639083.issue15823@psf.upfronthosting.co.za> Message-ID: <1346336656.09.0.081521544196.issue15823@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 16:32:13 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 30 Aug 2012 14:32:13 +0000 Subject: [issue15819] Unable to build Python out-of-tree when source tree is readonly. In-Reply-To: <1346309362.14.0.312540957077.issue15819@psf.upfronthosting.co.za> Message-ID: <3X75kh331ZzQ88@mail.python.org> Roundup Robot added the comment: New changeset 62044cd5b19b by Trent Nelson in branch '3.2': Issue #15819: Fix out-of-tree builds from a readonly source. http://hg.python.org/cpython/rev/62044cd5b19b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 16:35:21 2012 From: report at bugs.python.org (Nikolay Golub) Date: Thu, 30 Aug 2012 14:35:21 +0000 Subject: [issue15823] argparse produces error when multiply help lines In-Reply-To: <1346336062.37.0.78121639083.issue15823@psf.upfronthosting.co.za> Message-ID: <1346337321.03.0.398276812379.issue15823@psf.upfronthosting.co.za> Nikolay Golub added the comment: thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 16:36:13 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 30 Aug 2012 14:36:13 +0000 Subject: [issue15821] Improve docs for PyMemoryView_FromBuffer() In-Reply-To: <1346320388.88.0.494685067241.issue15821@psf.upfronthosting.co.za> Message-ID: <1346337373.39.0.378356509277.issue15821@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Having been bitten by an indirect buffer bug in 2.7, I decided to write some tests for 3.3. I added an objview() function to _testbuffer module that creates an indirect view for nested tuples. I have not written unit tests yet, so I'll attach a demo script test_indirect.py. I hope this test case will be helpful in figuring out the right semantics for PyMemoryView_FromBuffer(). My feeling is that memoryview should be able to store shape/strides/suboffsets arrays in its own structure. I also think the only way to achieve that is to make it a PyVarObject and allocate up to sizeof(Py_ssize_t)*ndim*3 bytes after the "view" substructure to store copies of shape/strides/suboffsets arrays. ---------- keywords: +patch Added file: http://bugs.python.org/file27059/_testbuffer.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 16:36:35 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 30 Aug 2012 14:36:35 +0000 Subject: [issue15821] Improve docs for PyMemoryView_FromBuffer() In-Reply-To: <1346320388.88.0.494685067241.issue15821@psf.upfronthosting.co.za> Message-ID: <1346337395.46.0.72682232328.issue15821@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : Added file: http://bugs.python.org/file27060/test_indirect.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 16:36:37 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 30 Aug 2012 14:36:37 +0000 Subject: [issue15819] Unable to build Python out-of-tree when source tree is readonly. In-Reply-To: <1346309362.14.0.312540957077.issue15819@psf.upfronthosting.co.za> Message-ID: <3X75qm3hR5zQ79@mail.python.org> Roundup Robot added the comment: New changeset af36536988fd by Trent Nelson in branch 'default': Block 78809:62044cd5b19b (Issue #15819) from 3.2. http://hg.python.org/cpython/rev/af36536988fd ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 16:52:53 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 30 Aug 2012 14:52:53 +0000 Subject: [issue15819] Unable to build Python out-of-tree when source tree is readonly. In-Reply-To: <1346309362.14.0.312540957077.issue15819@psf.upfronthosting.co.za> Message-ID: <3X76BV6vXQzQ95@mail.python.org> Roundup Robot added the comment: New changeset ab6ab44921b2 by Trent Nelson in branch 'default': Issue #15819: Fix out-of-tree builds from a readonly source. http://hg.python.org/cpython/rev/ab6ab44921b2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 16:56:24 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 30 Aug 2012 14:56:24 +0000 Subject: [issue15819] Unable to build Python out-of-tree when source tree is readonly. In-Reply-To: <1346309362.14.0.312540957077.issue15819@psf.upfronthosting.co.za> Message-ID: <3X76GY68wwzQ1Y@mail.python.org> Roundup Robot added the comment: New changeset 2dde5a7439fd by Trent Nelson in branch '2.7': Issue #15819: Fix out-of-tree builds from a readonly source. http://hg.python.org/cpython/rev/2dde5a7439fd ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 16:57:20 2012 From: report at bugs.python.org (Trent Nelson) Date: Thu, 30 Aug 2012 14:57:20 +0000 Subject: [issue15819] Unable to build Python out-of-tree when source tree is readonly. In-Reply-To: <1346309362.14.0.312540957077.issue15819@psf.upfronthosting.co.za> Message-ID: <1346338640.78.0.953170668257.issue15819@psf.upfronthosting.co.za> Changes by Trent Nelson : ---------- stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 16:57:21 2012 From: report at bugs.python.org (Stefan Krah) Date: Thu, 30 Aug 2012 14:57:21 +0000 Subject: [issue15821] Improve docs for PyMemoryView_FromBuffer() In-Reply-To: <1346337373.39.0.378356509277.issue15821@psf.upfronthosting.co.za> Message-ID: <20120830145719.GA14110@sleipnir.bytereef.org> Stefan Krah added the comment: PyMemoryViewObject already is a PyVarObject with its own shape, strides and suboffsets. It is the PyManagedBuffer object that directly communicates with exporters. The decision to store *exactly* the buffer that is obtained from the exporter was made in #10181. Your test case seems to pass here. :) Was it supposed to crash? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 17:00:00 2012 From: report at bugs.python.org (Trent Nelson) Date: Thu, 30 Aug 2012 15:00:00 +0000 Subject: [issue9860] Building python outside of source directory fails In-Reply-To: <1284559695.71.0.359508650396.issue9860@psf.upfronthosting.co.za> Message-ID: <1346338800.24.0.475437451021.issue9860@psf.upfronthosting.co.za> Trent Nelson added the comment: FWIW, `make patchcheck` fails for me as follows: % make patchcheck ./python /home/trent/hg/cpython-3.2/Tools/scripts/patchcheck.py Getting the list of files that have been added/changed ... abort: no repository found in '/tmp/cpython-3.2-build' (.hg not found)! 0 files Fixing whitespace ... 0 files Fixing C file whitespace ... 0 files Fixing docs whitespace ... 0 files Docs modified ... NO Misc/ACKS updated ... NO Misc/NEWS updated ... NO [51233 refs] patchcheck.py needs to be modified so that it cd's into SRCDIR before running any hg commands. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 17:07:27 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 30 Aug 2012 15:07:27 +0000 Subject: [issue15821] Improve docs for PyMemoryView_FromBuffer() In-Reply-To: <1346320388.88.0.494685067241.issue15821@psf.upfronthosting.co.za> Message-ID: <1346339247.22.0.987714414225.issue15821@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > Your test case seems to pass here. :) Was it supposed to crash? No, I worked real hard to make it pass. :-) I think it would crash 2.7 and 3.2, but I have not tried. I also suspect it leaks memory. Do you think this is something that we should include in the test suit. If so, I will probably open a separate issue and transform test_indirect.py into a patch for test_buffer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 17:15:48 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 30 Aug 2012 15:15:48 +0000 Subject: [issue15821] Improve docs for PyMemoryView_FromBuffer() In-Reply-To: <1346320388.88.0.494685067241.issue15821@psf.upfronthosting.co.za> Message-ID: <1346339748.31.0.862619399419.issue15821@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > PyMemoryViewObject already is a PyVarObject with its own shape, > strides and suboffsets. You are right. I was mistakenly looking at 3.2.3 sources. It looks like there are a lot of undocumented changes here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 17:41:44 2012 From: report at bugs.python.org (Shish) Date: Thu, 30 Aug 2012 15:41:44 +0000 Subject: [issue2988] Invalid cookies crash web applications In-Reply-To: <1211963484.7.0.388679808819.issue2988@psf.upfronthosting.co.za> Message-ID: <1346341304.26.0.258459174216.issue2988@psf.upfronthosting.co.za> Shish added the comment: I'm having problems with this too -- a third party app on the same domain as me has set an invalid cookie, and now my app crashes horribly :( (And even if cherrypy handled the exception and didn't crash completely, it would still not be able to use any cookies) ---------- nosy: +shish2k _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 17:47:50 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 30 Aug 2012 15:47:50 +0000 Subject: [issue2988] Invalid cookies crash web applications In-Reply-To: <1211963484.7.0.388679808819.issue2988@psf.upfronthosting.co.za> Message-ID: <1346341670.19.0.0150974892496.issue2988@psf.upfronthosting.co.za> R. David Murray added the comment: There is some extensive (and somewhat contentious) discussion of this on issue 2193. I myself am sympathetic to having a mode where parsing errors are handled in a more convenient fashion, but it would pretty much have to be a new feature. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 18:21:50 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 30 Aug 2012 16:21:50 +0000 Subject: [issue15822] Python 3.3 creates lib2to3 grammar in wrong order In-Reply-To: <1346321126.73.0.788135574831.issue15822@psf.upfronthosting.co.za> Message-ID: <1346343710.66.0.553894474875.issue15822@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 19:05:50 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 30 Aug 2012 17:05:50 +0000 Subject: [issue12014] str.format parses replacement field incorrectly In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za> Message-ID: <1346346350.33.0.0804492072079.issue12014@psf.upfronthosting.co.za> ?ric Araujo added the comment: You can bring this up to python-dev to get other developers? opinion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 19:22:37 2012 From: report at bugs.python.org (Stefan Krah) Date: Thu, 30 Aug 2012 17:22:37 +0000 Subject: [issue15821] Improve docs for PyMemoryView_FromBuffer() In-Reply-To: <1346333944.53.0.237978097972.issue15821@psf.upfronthosting.co.za> Message-ID: <20120830172237.GA15173@sleipnir.bytereef.org> Stefan Krah added the comment: On second thought, it's impossible to crash a memoryview generated by PyMemoryView_FromBuffer(info) even when info->shape etc. point to stack addresses. The reason is this: All new memoryviews are created through the mbuf_add* API. In the first call to mbuf_add_view(mbuf, NULL) the stack addresses are still valid, and the private shape, strides and suboffsets of the first memoryview that is registered with the managed buffer are initialized correctly. Now PyMemoryView_FromBuffer() returns and the managed buffer itself contains invalid stack addresses. But these are never used again! Chained memoryviews are generated from existing memoryviews, and they are registered with the managed buffer by calling mbuf_add_view(mbuf, existing_view->view). mbuf_add_incomplete_view(mbuf, NULL, ndim) does not access shape, strides and suboffsets. If info->format points to a stack address, it would crash both the old and new implementations. I'd regard such a use of info->format silly. I've never considered this use of PyMemoryView_FromBuffer(info) legitimate, but it works in the new implementation. If we officially endorse this pattern, then info->format should probably also be copied. So the topic is reduced to: 1) Previous: If non-NULL, steal the view.obj reference with automatic decrement in PyBuffer_Release(). New: If non-NULL, treat view.obj as a borrowed reference. 2) Copy info->format? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 19:23:11 2012 From: report at bugs.python.org (Stefan Krah) Date: Thu, 30 Aug 2012 17:23:11 +0000 Subject: [issue15821] Improve docs for PyMemoryView_FromBuffer() In-Reply-To: <1346320388.88.0.494685067241.issue15821@psf.upfronthosting.co.za> Message-ID: <1346347391.15.0.627265328579.issue15821@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- priority: high -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 19:25:55 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 30 Aug 2012 17:25:55 +0000 Subject: [issue15821] Improve docs for PyMemoryView_FromBuffer() In-Reply-To: <1346320388.88.0.494685067241.issue15821@psf.upfronthosting.co.za> Message-ID: <1346347555.66.0.097652004537.issue15821@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : Added file: http://bugs.python.org/file27061/_testbuffer.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 19:30:02 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 30 Aug 2012 17:30:02 +0000 Subject: [issue15821] Improve docs for PyMemoryView_FromBuffer() In-Reply-To: <1346320388.88.0.494685067241.issue15821@psf.upfronthosting.co.za> Message-ID: <1346347802.95.0.585302484332.issue15821@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I've updated test_indirect.py to print all memoryview fields and cleaned up the _testbuffer patch a little. Note this code that is needed to prevent a memory leak: + /* PyMemoryView_FromBuffer ignores info.obj. Add it explicitely. */ + if (view != NULL) + ((PyMemoryViewObject *)view)->view.obj = info.obj; Shouldn't PyMemoryView_FromBuffer() copy non-NULL obj from Py_buffer? ---------- Added file: http://bugs.python.org/file27062/test_indirect.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 19:38:22 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 30 Aug 2012 17:38:22 +0000 Subject: [issue15821] Improve docs for PyMemoryView_FromBuffer() In-Reply-To: <20120830172237.GA15173@sleipnir.bytereef.org> Message-ID: Alexander Belopolsky added the comment: On Thu, Aug 30, 2012 at 1:22 PM, Stefan Krah wrote: > So the topic is reduced to: > > 1) Previous: If non-NULL, steal the view.obj reference with automatic > decrement in PyBuffer_Release(). > New: If non-NULL, treat view.obj as a borrowed reference. > > 2) Copy info->format? +1 to both ideas. ---------- nosy: +Alexander.Belopolsky title: Improve docs for PyMemoryView_FromBuffer() -> Improve docs for PyMemoryView_FromBuffer() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 19:39:36 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 30 Aug 2012 17:39:36 +0000 Subject: [issue15821] Improve docs for PyMemoryView_FromBuffer() In-Reply-To: <1346320388.88.0.494685067241.issue15821@psf.upfronthosting.co.za> Message-ID: <1346348376.59.0.759844984772.issue15821@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : Removed file: http://bugs.python.org/file27059/_testbuffer.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 19:39:45 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 30 Aug 2012 17:39:45 +0000 Subject: [issue15821] Improve docs for PyMemoryView_FromBuffer() In-Reply-To: <1346320388.88.0.494685067241.issue15821@psf.upfronthosting.co.za> Message-ID: <1346348385.5.0.939292739566.issue15821@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : Removed file: http://bugs.python.org/file27060/test_indirect.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 20:17:45 2012 From: report at bugs.python.org (mastahyeti) Date: Thu, 30 Aug 2012 18:17:45 +0000 Subject: [issue15824] mutable urlparse return type Message-ID: <1346350665.33.0.731435453404.issue15824@psf.upfronthosting.co.za> New submission from mastahyeti: This patch removes the inheritance from namedtuple and attempts to add the necessary methods to make it backwards compatible. When parsing a url with urlparse.urlparse, the return type is non-mutable (named tuple). This is really inconvenient, because one of the most common (imop) use cases for urlparse is to parse a url, make an adjustment or change and then unparse it. Currently, something like this is required: import urlparse url = list(urlparse.urlparse('http://www.example.com/foo/bar?hehe=haha')) url[1] = 'python.com' new_url = urllib.urlunparse(url) I think this is really clunky. Moving to a mutable return type is challenging because (to my knowledge) there are no types that are mutable and compatible with tuple. This patch removes the inheritance from namedtuple and attempts to add the necessary methods to make it backwards compatible. Does any one know of a better way to do this? It would be nice if there were a namedlist type that acted like namedtuple but was mutable. With these updates, urlparse can be used as follows: import urlparse url = list(urlparse.urlparse('http://www.example.com/foo/bar?hehe=haha')) url.netloc = 'www.python.com' urlparse.urlunparse(url) I think this is much better. Let me know if you disagree... Also, I ran the script through autopep8 because it was messy. Also, I'm not sure if I'm supposed to duplicate this patch over to Python3. I can do that if necessary ---------- components: Library (Lib) files: urlparse_patch.patch keywords: patch messages: 169474 nosy: mastahyeti priority: normal severity: normal status: open title: mutable urlparse return type type: enhancement versions: Python 2.7 Added file: http://bugs.python.org/file27063/urlparse_patch.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 20:21:01 2012 From: report at bugs.python.org (mastahyeti) Date: Thu, 30 Aug 2012 18:21:01 +0000 Subject: [issue15824] mutable urlparse return type In-Reply-To: <1346350665.33.0.731435453404.issue15824@psf.upfronthosting.co.za> Message-ID: <1346350861.65.0.903560804414.issue15824@psf.upfronthosting.co.za> mastahyeti added the comment: TYPO!!! After my patch, urlparse can be used as such: import urlparse url = urlparse.urlparse('http://www.example.com/foo/bar?hehe=haha') url.netloc = 'www.python.com' urlparse.urlunparse(url) The difference being that the result doesn't need to be casted to a list in order to be mutated... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 20:22:00 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 30 Aug 2012 18:22:00 +0000 Subject: [issue15824] mutable urlparse return type In-Reply-To: <1346350665.33.0.731435453404.issue15824@psf.upfronthosting.co.za> Message-ID: <1346350920.5.0.314244825635.issue15824@psf.upfronthosting.co.za> Ezio Melotti added the comment: This is a new feature, so it can't go in 2.7. ---------- nosy: +ezio.melotti, orsenthil stage: -> needs patch versions: +Python 3.4 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 20:24:58 2012 From: report at bugs.python.org (mastahyeti) Date: Thu, 30 Aug 2012 18:24:58 +0000 Subject: [issue15824] mutable urlparse return type In-Reply-To: <1346350920.5.0.314244825635.issue15824@psf.upfronthosting.co.za> Message-ID: mastahyeti added the comment: This is my first patch for python. Is there a feature freeze? Does it need to go in Python3? Thanks. On Thu, Aug 30, 2012 at 1:22 PM, Ezio Melotti wrote: > > Ezio Melotti added the comment: > > This is a new feature, so it can't go in 2.7. > > ---------- > nosy: +ezio.melotti, orsenthil > stage: -> needs patch > versions: +Python 3.4 -Python 2.7 > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 20:25:34 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 30 Aug 2012 18:25:34 +0000 Subject: [issue15824] mutable urlparse return type In-Reply-To: <1346350665.33.0.731435453404.issue15824@psf.upfronthosting.co.za> Message-ID: <1346351134.94.0.294121528305.issue15824@psf.upfronthosting.co.za> R. David Murray added the comment: I think the first step is probably to get consensus on whether this is desirable or not. That might require a trip to python-idea, or it might not :) As for the patch itself, you should definitely *not* include any changes other than the ones you are proposing. Otherwise reviewing the patch is very difficult. As Ezio said, as a new feature this could only go into 3.4, so the patch should be against the default branch in the mercurial repository. ---------- nosy: +r.david.murray stage: needs patch -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 20:38:27 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Thu, 30 Aug 2012 18:38:27 +0000 Subject: [issue15824] mutable urlparse return type In-Reply-To: <1346350665.33.0.731435453404.issue15824@psf.upfronthosting.co.za> Message-ID: Senthil Kumaran added the comment: On Thu, Aug 30, 2012 at 11:17 AM, mastahyeti wrote: > > When parsing a url with urlparse.urlparse, the return type is non-mutable (named tuple). This is really inconvenient, because one of the most common (imop) use cases for urlparse is to parse a url, make an adjustment or change and then unparse it. Currently, something like this is required: Not actually, using the namedtuple is a convenience and working through way may help you to be generate your target url in a more meaningful way. Also remember that we moved to namedtuple after understanding that it is more meaningful to use that for parsed result. So, my vote for this proposal is -1. And if you need discuss the strategies of how to use it, then you can ask over at python-help or related lists. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 20:51:10 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Thu, 30 Aug 2012 18:51:10 +0000 Subject: [issue15819] Unable to build Python out-of-tree when source tree is readonly. In-Reply-To: <1346309362.14.0.312540957077.issue15819@psf.upfronthosting.co.za> Message-ID: <1346352670.41.0.250098150205.issue15819@psf.upfronthosting.co.za> Richard Oudkerk added the comment: I tried building from out-of-tree with a read-only srcdir, but I found two other files which the build process tries to create in the source directory: $(srcdir)/Objects/typeslots.inc $(srcdir)/Lib/_sysconfigdata.py ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 20:54:59 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Thu, 30 Aug 2012 18:54:59 +0000 Subject: [issue13769] json.dump(ensure_ascii=False) return str instead of unicode In-Reply-To: <1326300079.82.0.279410736545.issue13769@psf.upfronthosting.co.za> Message-ID: <1346352899.53.0.564432879782.issue13769@psf.upfronthosting.co.za> Petri Lehtinen added the comment: Attached yet another patch. It explains what input causes the result to be unicode instead of str. ---------- Added file: http://bugs.python.org/file27064/issue13769_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 20:58:07 2012 From: report at bugs.python.org (mastahyeti) Date: Thu, 30 Aug 2012 18:58:07 +0000 Subject: [issue15824] mutable urlparse return type In-Reply-To: Message-ID: mastahyeti added the comment: Senthil, Can you give an example of how namedtuple would be more convenient? It is definitely more convenient than an ordinary tuple, but its inconvenient having its items not be assignable. As I showed in my example above, it is usable as-is, but it is clunky. As David says above, this obviously needs to be moved to another list for discussion of whether the current behavior is desirable. On Thu, Aug 30, 2012 at 1:38 PM, Senthil Kumaran wrote: > > Senthil Kumaran added the comment: > > On Thu, Aug 30, 2012 at 11:17 AM, mastahyeti wrote: >> >> When parsing a url with urlparse.urlparse, the return type is non-mutable (named tuple). This is really inconvenient, because one of the most common (imop) use cases for urlparse is to parse a url, make an adjustment or change and then unparse it. Currently, something like this is required: > > Not actually, using the namedtuple is a convenience and working > through way may help you to be generate your target url in a more > meaningful way. Also remember that we moved to namedtuple after > understanding that it is more meaningful to use that for parsed > result. So, my vote for this proposal is -1. And if you need discuss > the strategies of how to use it, then you can ask over at python-help > or related lists. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 21:03:40 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 30 Aug 2012 19:03:40 +0000 Subject: [issue15824] mutable urlparse return type In-Reply-To: <1346350665.33.0.731435453404.issue15824@psf.upfronthosting.co.za> Message-ID: <1346353420.47.0.00406194791438.issue15824@psf.upfronthosting.co.za> R. David Murray added the comment: Actually, Senthil is right. What you want is the _replace method of namedtuple to satisfy your use case. ---------- resolution: -> works for me stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 21:09:34 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 30 Aug 2012 19:09:34 +0000 Subject: [issue15819] Unable to build Python out-of-tree when source tree is readonly. In-Reply-To: <1346309362.14.0.312540957077.issue15819@psf.upfronthosting.co.za> Message-ID: <1346353774.69.0.498012916313.issue15819@psf.upfronthosting.co.za> Martin v. L?wis added the comment: What I liked about Trent's original bug report is that it didn't just bring up a generic issue (cannot build with read-only source code), but clarified that his concern really was graminit. So I'd like to declare that this (graminit) is the focus of this issue: any other aspects of read-only source trees are out of scope, and should be reported separately. That said: As for typeslots.inc: this shouldn't really be an issue for a released version of Python, since its tarball should include the generated file, and the timestamps should be in an order so that generation is unnecessary. This should be the case for all generated files that are also checked into Mercurial. For checkouts from Mercurial, you should do "make touch" after an update, as this will bring the timestamps in the right order. It seems that graminit is missing from .hgtouch (in which case Trent's patch probably wouldn't have been necessary, except that it also fixes older branches). But that is again a different issue. As for sysconfigdata: this really should be a separate issue. It's more difficult, since installation and packaging needs to pick up the file even if it's not in the source tree. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 21:10:22 2012 From: report at bugs.python.org (mastahyeti) Date: Thu, 30 Aug 2012 19:10:22 +0000 Subject: [issue15824] mutable urlparse return type In-Reply-To: <1346353420.47.0.00406194791438.issue15824@psf.upfronthosting.co.za> Message-ID: mastahyeti added the comment: I can live with that, it just seems that ordinary item assignment is more pythonic.... On Thu, Aug 30, 2012 at 2:03 PM, R. David Murray wrote: > > R. David Murray added the comment: > > Actually, Senthil is right. What you want is the _replace method of namedtuple to satisfy your use case. > > ---------- > resolution: -> works for me > stage: -> committed/rejected > status: open -> closed > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 21:13:48 2012 From: report at bugs.python.org (Ned Deily) Date: Thu, 30 Aug 2012 19:13:48 +0000 Subject: [issue15819] Unable to build Python out-of-tree when source tree is readonly. In-Reply-To: <1346309362.14.0.312540957077.issue15819@psf.upfronthosting.co.za> Message-ID: <1346354028.17.0.869810004021.issue15819@psf.upfronthosting.co.za> Ned Deily added the comment: The sysconfigdata problem is already documented in two open issues: Issue14774 and Issue15298. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 21:16:46 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 30 Aug 2012 19:16:46 +0000 Subject: [issue15824] mutable urlparse return type In-Reply-To: <1346350665.33.0.731435453404.issue15824@psf.upfronthosting.co.za> Message-ID: <1346354206.74.0.942850842007.issue15824@psf.upfronthosting.co.za> R. David Murray added the comment: Not in this case. We are treating the URL as an immutable object, so the Pythonic thing to do is create new object of the same type with the change applied. Similar to "abcd".replace('a', 'z') returning a new string. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 21:22:39 2012 From: report at bugs.python.org (mastahyeti) Date: Thu, 30 Aug 2012 19:22:39 +0000 Subject: [issue15824] mutable urlparse return type In-Reply-To: <1346354206.74.0.942850842007.issue15824@psf.upfronthosting.co.za> Message-ID: mastahyeti added the comment: Hrmm. Okay. I concede. On Thu, Aug 30, 2012 at 2:16 PM, R. David Murray wrote: > > R. David Murray added the comment: > > Not in this case. We are treating the URL as an immutable object, so the Pythonic thing to do is create new object of the same type with the change applied. Similar to "abcd".replace('a', 'z') returning a new string. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 21:50:50 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 30 Aug 2012 19:50:50 +0000 Subject: [issue15819] Unable to build Python out-of-tree when source tree is readonly. In-Reply-To: <1346309362.14.0.312540957077.issue15819@psf.upfronthosting.co.za> Message-ID: <1346356250.25.0.783543861568.issue15819@psf.upfronthosting.co.za> Martin v. L?wis added the comment: As a further follow-up: the original code (in 67ed8a6905c3, by Neil Schemenauer from 2001), he explicitly changed GRAMMAR_C/H to refer to srcdir, claiming that errors from building them would be ignored. In r87558, for which I can't find a subversion revsision for, Victor Stinner dropped the Makefile "-" marker, making the read-only case fail. In reviewing the patch more, I think it is actually incorrect: it now generates the files into Include, but they aren't considered there since (builddir)/Include is not added to the -I options. So the two options now are: a) revert the patch, and restore Neil's original approach, or b) add Include to the -I options, if srcdir is not "." Reopening for consideration. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 21:58:49 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 30 Aug 2012 19:58:49 +0000 Subject: [issue15824] mutable urlparse return type In-Reply-To: <1346350665.33.0.731435453404.issue15824@psf.upfronthosting.co.za> Message-ID: <1346356729.54.0.146310798994.issue15824@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 22:02:51 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 30 Aug 2012 20:02:51 +0000 Subject: [issue15819] Unable to build Python out-of-tree when source tree is readonly. In-Reply-To: <1346309362.14.0.312540957077.issue15819@psf.upfronthosting.co.za> Message-ID: <1346356971.62.0.665662822698.issue15819@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Reconsidering more: it would be desirable if even an out-of-source-tree compilation wouldn't require Python for bootstrapping; with the committed patch, it does since it will always run ASDLGEN. If the source version of the generated files is fresh enough, they should just be copied to the destination. I'm not quite sure how to achieve that with Make rules. This probably *is* a separate issue (which would become irrelevant if the patch here is reverted). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 23:05:54 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 30 Aug 2012 21:05:54 +0000 Subject: [issue13992] Segfault in PyTrash_destroy_chain In-Reply-To: <1328964953.21.0.536994091719.issue13992@psf.upfronthosting.co.za> Message-ID: <1346360754.45.0.727387491434.issue13992@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Can someone witnessing the problem try to apply the attached patch? ---------- keywords: +patch Added file: http://bugs.python.org/file27065/trashcan-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 23:08:57 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 30 Aug 2012 21:08:57 +0000 Subject: [issue13992] Segfault in PyTrash_destroy_chain In-Reply-To: <1328964953.21.0.536994091719.issue13992@psf.upfronthosting.co.za> Message-ID: <1346360937.13.0.426437478812.issue13992@psf.upfronthosting.co.za> Antoine Pitrou added the comment: (for context about the patch, see my hypothesis at http://mail.python.org/pipermail/python-dev/2012-August/121533.html ) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 23:29:19 2012 From: report at bugs.python.org (ThiefMaster) Date: Thu, 30 Aug 2012 21:29:19 +0000 Subject: [issue15825] Typo in OrderedDict docs Message-ID: <1346362159.24.0.0813127284667.issue15825@psf.upfronthosting.co.za> New submission from ThiefMaster: "It is also straight-forward to create an ordered dictionary variant that the remembers the order the keys were last inserted." The first "the" doesn't belong there. ---------- assignee: docs at python components: Documentation messages: 169493 nosy: ThiefMaster, docs at python priority: normal severity: normal status: open title: Typo in OrderedDict docs versions: Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 30 23:57:57 2012 From: report at bugs.python.org (Jason R. Coombs) Date: Thu, 30 Aug 2012 21:57:57 +0000 Subject: [issue14847] AttributeError: NoneType has no attribute 'utf_8_decode' In-Reply-To: <1337311331.2.0.610588604888.issue14847@psf.upfronthosting.co.za> Message-ID: <1346363877.6.0.498660568404.issue14847@psf.upfronthosting.co.za> Jason R. Coombs added the comment: Since my last comment, we've been running with a version of the wrapper (attached) around the main entry point to our application and it has completely eliminated the error. However, while the wrapper does report when a module deletion is requested, it is never triggered (we don't see the word "deletion" anywhere in our logs). This result leads me to two findings: 1. Merely making a reference to sys.modules was sufficient to prevent the error. 2. Preventing deletion of 'encodings.*' modules is not sufficient (as apparently this doesn't happen in our code). My next step is going to be to remove the wrapper, so the error exhibits itself again and we can prove that the issue is still present, and then to re-apply the wrapper, but this time only creating a reference to sys.modules (not actually replacing it). ---------- Added file: http://bugs.python.org/file27066/wrapper.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 03:03:54 2012 From: report at bugs.python.org (Ned Deily) Date: Fri, 31 Aug 2012 01:03:54 +0000 Subject: [issue15822] Python 3.3 creates lib2to3 grammar in wrong order In-Reply-To: <1346321126.73.0.788135574831.issue15822@psf.upfronthosting.co.za> Message-ID: <1346375034.28.0.583299866731.issue15822@psf.upfronthosting.co.za> Ned Deily added the comment: Can you give the steps to reproduce this issue? Also, what platform and file system are in use? I can guess what an underlying problem might be but I haven't been able to reproduce the failure myself. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 04:52:15 2012 From: report at bugs.python.org (Alessandro Moura) Date: Fri, 31 Aug 2012 02:52:15 +0000 Subject: [issue15826] Increased test coverage of test_glob.py Message-ID: <1346381534.69.0.636623200483.issue15826@psf.upfronthosting.co.za> New submission from Alessandro Moura: Hi, Here is a patch to increase test coverage of test_glob.py. I added tests where the glob patterns are of type bytes. The coverage (according to coverage.py) is now complete, except for what are clearly artefacts probably caused by the fact that glob is loaded before coverage measurements start (global statements are reported not covered but local ones are). ---------- components: Tests files: glob-cov-incr.patch keywords: patch messages: 169496 nosy: eng793 priority: normal severity: normal status: open title: Increased test coverage of test_glob.py type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file27067/glob-cov-incr.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 05:31:31 2012 From: report at bugs.python.org (Dag Sverre Seljebotn) Date: Fri, 31 Aug 2012 03:31:31 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <1346260029.19.0.320505643782.issue15814@psf.upfronthosting.co.za> Message-ID: <1346383891.67.0.981628251748.issue15814@psf.upfronthosting.co.za> Dag Sverre Seljebotn added the comment: It is perfectly possible for an object to export memory in a read-only way that may still change. Another object may have a writeable view: x = obj.readonly_view y = obj.writable_view obj.move_to_next_image() # changes memory under x, y So, hashing using tobytes() doesn't make any sense at all to me. A memoryview != its contents. You could compare memoryviews simply by comparing the Py_buffer structure, but that's going to be confusing for a lot of users. I would really prefer unhashable (+ if needed a method for comparing contents). (FWIW, not sure how relevant this is; in NumPy, == does In [1]: np.array([1,2,3]) == np.array([1,3,3]) Out[1]: array([ True, False, True], dtype=bool) Cython will follow this behaviour for its "typed memory views", which is Cython's builting mechanism for PEP 3118 which is not quite the same as CPython "memoryview". But I understand that following this behaviour is probably out of the question for CPython.) ---------- nosy: +Dag.Sverre.Seljebotn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 05:47:33 2012 From: report at bugs.python.org (Dag Sverre Seljebotn) Date: Fri, 31 Aug 2012 03:47:33 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <1346260029.19.0.320505643782.issue15814@psf.upfronthosting.co.za> Message-ID: <1346384853.22.0.857205936594.issue15814@psf.upfronthosting.co.za> Dag Sverre Seljebotn added the comment: OK, I can understand the desire to make memoryviews be bytes-like objects (though to my mind, bytes is "frozen" in a very different way...) If so, and it is deemed worth it, my suggestion is to add a new PyBUF_CONST flag to the buffer acquisition in that case (which can not be used together with PyBUF_WRITABLE). Given that flag, the exporter guarantees that the contents does not change (or fails to give away a buffer). Perhaps it could be possible for hash() to try to re-acquire a const buffer, so that some buffers are hashable (by contents) and others not. (I really think relying on buffers that are not writeable to be constant is dangerous. A readonly memoryview could for instance point straight to the live output of a webcam.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 06:14:02 2012 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 31 Aug 2012 04:14:02 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <1346260029.19.0.320505643782.issue15814@psf.upfronthosting.co.za> Message-ID: <1346386442.15.0.282217595683.issue15814@psf.upfronthosting.co.za> Stefan Behnel added the comment: To add on Dag's comments, this essentially means that any caching of the hash value is dangerous, unless it can be assured that the underlying buffer definitely has not changed in the meantime. There is no way for users to explicitly tell a memoryview to rehash itself, so putting it into one dict, then modifying the content, then putting it into another is a perfectly reasonable use case for users, but fails when the memory view caches its hash value. As far as I can see it, any "obvious" fix for this creates a whole bath tub full of worms: updating views transitively, adding new APIs, supporting new buffer parameters, ... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 07:01:21 2012 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 31 Aug 2012 05:01:21 +0000 Subject: [issue15827] Use "ll" for PY_FORMAT_SIZE_T on Win64 Message-ID: <1346389281.37.0.195421488616.issue15827@psf.upfronthosting.co.za> New submission from Stefan Behnel: Formatting support for "lld"/"llu" was added (I think) in issue 7228, but the definition of PY_FORMAT_SIZE_T wasn't adapted. We are getting test output failures in Cython on Win64 when formatting error messages using the "Id" format, as defined by pyport.h: """ #ifndef PY_FORMAT_SIZE_T # if SIZEOF_SIZE_T == SIZEOF_INT && !defined(__APPLE__) # define PY_FORMAT_SIZE_T "" # elif SIZEOF_SIZE_T == SIZEOF_LONG # define PY_FORMAT_SIZE_T "l" # elif defined(MS_WINDOWS) # define PY_FORMAT_SIZE_T "I" # else # error "This platform's pyconfig.h needs to define PY_FORMAT_SIZE_T" # endif #endif """ The "%Id" format is not being resolved in the error messages and shows up in the output instead. NumPy uses "lld" when available, starting with Py2.7: https://github.com/numpy/numpy/blob/master/numpy/core/include/numpy/npy_common.h#L66 Shouldn't PY_FORMAT_SIZE_T become "ll" on Win64 directly? ---------- components: Interpreter Core messages: 169500 nosy: scoder priority: normal severity: normal status: open title: Use "ll" for PY_FORMAT_SIZE_T on Win64 type: behavior versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 07:49:58 2012 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 31 Aug 2012 05:49:58 +0000 Subject: [issue15827] Use "ll" for PY_FORMAT_SIZE_T on Win64 In-Reply-To: <1346389281.37.0.195421488616.issue15827@psf.upfronthosting.co.za> Message-ID: <1346392198.08.0.865304893573.issue15827@psf.upfronthosting.co.za> Stefan Behnel added the comment: I just saw that we were misusing PY_FORMAT_SIZE_T according to the documentation (reading that sometimes helps...). It is not supposed to be used with the Python formatting functions, only with low-level functions. Closing, sorry for the noise. ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 08:41:45 2012 From: report at bugs.python.org (=?utf-8?q?Tomi_Pievil=C3=A4inen?=) Date: Fri, 31 Aug 2012 06:41:45 +0000 Subject: [issue15822] Python 3.3 creates lib2to3 grammar in wrong order In-Reply-To: <1346321126.73.0.788135574831.issue15822@psf.upfronthosting.co.za> Message-ID: <1346395305.54.0.213669853858.issue15822@psf.upfronthosting.co.za> Tomi Pievil?inen added the comment: Platform: RHEL 6.3 x86_64. 0. (remove old python 3 install, though this doesn't change anything) 1. Unpack 3.3rc1 source, cd Python-3.3.0rc1/ 2. ./configure; make 3. sudo make install 4. ls -ltc --full-time /usr/local/lib/python3.3/lib2to3/ This shows that Grammar.txt is just a tiny bit newer than the pickle. To produce the SandboxViolation: 1. curl -O https://raw.github.com/pypa/virtualenv/master/virtualenv.py 2. python3.3 virtualenv.py my_new_env or alternatively use distribute to install anything with the easy_install command. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 08:43:49 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 31 Aug 2012 06:43:49 +0000 Subject: [issue15822] Python 3.3 creates lib2to3 grammar in wrong order In-Reply-To: <1346321126.73.0.788135574831.issue15822@psf.upfronthosting.co.za> Message-ID: <1346395429.17.0.546358115977.issue15822@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: This issue can be easily reproduced on filesystems with nanosecond precision (e.g. ext4). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 08:46:31 2012 From: report at bugs.python.org (=?utf-8?q?Tomi_Pievil=C3=A4inen?=) Date: Fri, 31 Aug 2012 06:46:31 +0000 Subject: [issue15822] Python 3.3 creates lib2to3 grammar in wrong order In-Reply-To: <1346321126.73.0.788135574831.issue15822@psf.upfronthosting.co.za> Message-ID: <1346395591.36.0.00818024161791.issue15822@psf.upfronthosting.co.za> Tomi Pievil?inen added the comment: Ah, sorry, forgot to add that info. I also am running ext4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 08:46:38 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 31 Aug 2012 06:46:38 +0000 Subject: [issue15822] Python 3.3 creates lib2to3 grammar in wrong order In-Reply-To: <1346321126.73.0.788135574831.issue15822@psf.upfronthosting.co.za> Message-ID: <1346395598.41.0.143530234219.issue15822@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: `make install DESTDIR=/some/temporary/path` can be used to avoid affecting installed version of Python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 09:31:29 2012 From: report at bugs.python.org (Berker Peksag) Date: Fri, 31 Aug 2012 07:31:29 +0000 Subject: [issue15676] mmap: add empty file check prior to offset check In-Reply-To: <1345052794.26.0.230448790651.issue15676@psf.upfronthosting.co.za> Message-ID: <1346398289.13.0.169484402115.issue15676@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- versions: -Python 3.1, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 09:32:28 2012 From: report at bugs.python.org (Mark Tolonen) Date: Fri, 31 Aug 2012 07:32:28 +0000 Subject: [issue15828] imp.load_module doesn't support C_EXTENSION type Message-ID: <1346398348.83.0.242228991466.issue15828@psf.upfronthosting.co.za> New submission from Mark Tolonen: I built a C extension using SWIG for both Python 3.2 and Python 3.3. The Python file supplying class proxies uses imp.load_module and fails with the following traceback on 3.3.0rc1, but works on 3.2.3: Traceback (most recent call last): File "", line 1, in File ".\Widget.py", line 26, in _Widget = swig_import_helper() File ".\Widget.py", line 22, in swig_import_helper _mod = imp.load_module('_Widget', fp, pathname, description) File "D:\dev\python33\lib\imp.py", line 171, in load_module raise ImportError(msg, name=name) ImportError: Don't know how to import _Widget (type code 3 It looks like imp.py is new in Python 3.3, and imp.load_module no longer supports the C_EXTENSION type. It looks like a regression. To reproduce, I was able to run the following lines with the .pyd file in the current directory: import imp fp, pathname, description = imp.find_module('_Widget') imp.load_module('_Widget', fp, pathname, description) Nit: Also note the missing final ')' in the ImportError message. ---------- components: Library (Lib) messages: 169506 nosy: metolone priority: normal severity: normal status: open title: imp.load_module doesn't support C_EXTENSION type type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 09:33:45 2012 From: report at bugs.python.org (The Written Word) Date: Fri, 31 Aug 2012 07:33:45 +0000 Subject: [issue15340] OSError with "import random" when /dev/urandom doesn't exist (regression from 2.6) In-Reply-To: <1342132229.15.0.69254682318.issue15340@psf.upfronthosting.co.za> Message-ID: <1346398425.54.0.634669540438.issue15340@psf.upfronthosting.co.za> The Written Word added the comment: Actually, this regression appeared after the Hash Randomization patches prior to 2.6.8, 2.7.3, 3.1.4 and 3.2.3. Also, it not only breaks `from os import urandom`, but also prevents installation of many third-party packages that use setuptools or distribute, where the interpreter bails out with: "OSError: No such file or directory /dev/urandom" inside setup.py on all Tru64 machines, and HPUX 11.00 and 11.11 (at least). As best I can tell it's failing either because dev_urandom_noraise aborts the interpreter if /dev/urandom is missing, or later an uncaught PyExc_OSError in dev_urandom_python triggers for the same reason. In either case there's no NotImplemented exception raised for the fallback code be used :( ---------- nosy: +bugs-python at vendor.thewrittenword.com versions: +Python 2.6, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 10:26:49 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 31 Aug 2012 08:26:49 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <1346383891.67.0.981628251748.issue15814@psf.upfronthosting.co.za> Message-ID: <20120831082648.GA27982@sleipnir.bytereef.org> Stefan Krah added the comment: Dag Sverre Seljebotn wrote: > It is perfectly possible for an object to export memory in a read-only > way that may still change. Another object may have a writeable view: > > x = obj.readonly_view > y = obj.writable_view > obj.move_to_next_image() # changes memory under x, y PEP-3118 always means different things to different people. :) Your distinction between constant, readonly, writable is one way to interpret things. But looking at the use in the Python source tree, readonly does mean immutable. Unfortunately the PEP doesn't specify readonly: Is it the same as "mount a partition readonly", "readonly CD" or O_RDONLY? Also, existing practice was that in response to a PyBUF_FULL_RO request the exporter was free to hand out a writable buffer! This is now documented and subverts reliable tagging for consumers: http://docs.python.org/dev/c-api/buffer.html#readonly-format If any of this is a major inconvenience to NumPy or other users of the buffer API, perhaps you could open a separate issue. > (FWIW, not sure how relevant this is; in NumPy, == does > > In [1]: np.array([1,2,3]) == np.array([1,3,3]) > Out[1]: array([ True, False, True], dtype=bool) Since afa3dedfee18 we compare memoryviews and any exporter in the same manner as NumPy, except that the return value is a single boolean. So I think the new comparison is equivalent to all(a == b) in NumPy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 10:41:26 2012 From: report at bugs.python.org (Ned Deily) Date: Fri, 31 Aug 2012 08:41:26 +0000 Subject: [issue15822] Python 3.3 creates lib2to3 grammar in wrong order In-Reply-To: <1346321126.73.0.788135574831.issue15822@psf.upfronthosting.co.za> Message-ID: <1346402486.03.0.133635373793.issue15822@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the details. Moving to ext4, I was still not seeing the problem as Grammar.txt and the pickle file have the same nanosecond ctime but that may be due to running in a vm environment or other factors. Manually touching Grammar.txt, not surprisingly, does cause the reported behavior so that's sufficient for testing purposes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 10:42:29 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 31 Aug 2012 08:42:29 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <1346384853.22.0.857205936594.issue15814@psf.upfronthosting.co.za> Message-ID: <20120831084230.GB27982@sleipnir.bytereef.org> Stefan Krah added the comment: Dag Sverre Seljebotn wrote: > OK, I can understand the desire to make memoryviews be bytes-like objects > (though to my mind, bytes is "frozen" in a very different way...) We have two desires that sometimes conflict: People who want to use memoryview as a *buffer* legitimately want it to behave like bytes. People who want to have an "arrayview" want it to behave like NumPy or PIL arrays. The new implementation preserves fast paths for bytes and otherwise behaves pretty much like a very restricted version of NumPy's ndarray (with support for suboffsets), except that not all planned multi-dimensional features have been implemented yet. > If so, and it is deemed worth it, my suggestion is to add a new > PyBUF_CONST flag to the buffer acquisition in that case Note that memory_hash() raises an error if the exporter *itself* is not hashable, so it only hashes immutable objects by design. But the PyBUF_CONST flag might be worth considering (in another issue). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 11:13:30 2012 From: report at bugs.python.org (Berker Peksag) Date: Fri, 31 Aug 2012 09:13:30 +0000 Subject: [issue15701] AttributeError from HTTPError when using digest auth In-Reply-To: <1345149357.77.0.903430006119.issue15701@psf.upfronthosting.co.za> Message-ID: <1346404410.31.0.787085854236.issue15701@psf.upfronthosting.co.za> Berker Peksag added the comment: Python 2.6 is now in security-fix-only mode. ---------- components: +Library (Lib) nosy: +berker.peksag versions: +Python 2.7 -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 11:50:28 2012 From: report at bugs.python.org (Mike Hoy) Date: Fri, 31 Aug 2012 09:50:28 +0000 Subject: [issue15825] Typo in OrderedDict docs In-Reply-To: <1346362159.24.0.0813127284667.issue15825@psf.upfronthosting.co.za> Message-ID: <1346406628.6.0.634192147833.issue15825@psf.upfronthosting.co.za> Mike Hoy added the comment: I added two patches one for 2.7 and one for 3.3. Please advise if this is the correct way to handle this. ---------- keywords: +patch nosy: +mikehoy Added file: http://bugs.python.org/file27068/typo-ordered-dict2.7.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 11:50:38 2012 From: report at bugs.python.org (Mike Hoy) Date: Fri, 31 Aug 2012 09:50:38 +0000 Subject: [issue15825] Typo in OrderedDict docs In-Reply-To: <1346362159.24.0.0813127284667.issue15825@psf.upfronthosting.co.za> Message-ID: <1346406638.42.0.0712368204835.issue15825@psf.upfronthosting.co.za> Changes by Mike Hoy : Added file: http://bugs.python.org/file27069/typo-ordered-dict3.3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 11:55:35 2012 From: report at bugs.python.org (Mike Hoy) Date: Fri, 31 Aug 2012 09:55:35 +0000 Subject: [issue15829] Threading Lock - Wrong Exception Name Message-ID: <1346406935.1.0.0548021295601.issue15829@psf.upfronthosting.co.za> New submission from Mike Hoy: >From the Docs mailing list: >Hi >I found a bug in python docs which can be accessed at links: >http://docs.python.org/library/threading.html#lock-objects >http://docs.python.org/py3k/library/threading.html#lock-objects >Bug is in second paragraph describing threading.Lock. I found that >statement: >"If an attempt is made to release an unlocked lock, a RuntimeError will >be raised." >Which is not true, name of exception is wrong it should be (and it >relay is) ThreadError (from threading module) >Could someone fix it? >-- >Br, >Slawomir Kuszczynski ---------- messages: 169513 nosy: mikehoy priority: normal severity: normal status: open title: Threading Lock - Wrong Exception Name versions: Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 11:56:27 2012 From: report at bugs.python.org (Mike Hoy) Date: Fri, 31 Aug 2012 09:56:27 +0000 Subject: [issue15829] Threading Lock - Wrong Exception Name In-Reply-To: <1346406935.1.0.0548021295601.issue15829@psf.upfronthosting.co.za> Message-ID: <1346406987.2.0.500309260668.issue15829@psf.upfronthosting.co.za> Mike Hoy added the comment: Working on a patch now unless there are objections to the OP. ---------- nosy: +docs at python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 12:01:43 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 31 Aug 2012 10:01:43 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <1346386442.15.0.282217595683.issue15814@psf.upfronthosting.co.za> Message-ID: <50408B84.8080904@v.loewis.de> Martin v. L?wis added the comment: Am 31.08.12 06:14, schrieb Stefan Behnel: > To add on Dag's comments, this essentially means that any caching of > the hash value is dangerous Stefan Krah is right here: the proper test (which is already implemented) is whether the underlying object is hashable; this is a sufficient test. Caching of the hash is always correct, or else the hash function is incorrect: a hash of an object must not change. If it would change, you couldn't find the key anymore in a dictionary. > unless it can be assured that the > underlying buffer definitely has not changed in the meantime. There > is no way for users to explicitly tell a memoryview to rehash itself, > so putting it into one dict, then modifying the content, then putting > it into another is a perfectly reasonable use case for users, No, it's not: d = {} o = some_object m = memoryview(o) d[m] = -1 o.modify() # so that hash(m) changes print(d[m]) # keyerror, even though m in d.keys() > As far as I can see it, any "obvious" fix for this creates a whole > bath tub full of worms: updating views transitively, adding new APIs, > supporting new buffer parameters, ... So above (in this thread): the easiest fix is to just drop hashing support for memoryview objects. This can be extended in steps: - support hashing if the underlying object is bytes - support hashing if the shape is 1D "B", and the underlying object is hashable - support hashing if the exporter has somehow promised to not modify the memory ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 12:22:41 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 31 Aug 2012 10:22:41 +0000 Subject: [issue15829] Threading Lock - Wrong Exception Name In-Reply-To: <1346406935.1.0.0548021295601.issue15829@psf.upfronthosting.co.za> Message-ID: <1346408561.03.0.817304013462.issue15829@psf.upfronthosting.co.za> Andrew Svetlov added the comment: The problem is: threading.Lock raises ThreadingError (which is subclass of RuntimeError for 3.3 but not for 3.2), but threading.Condition raises RuntimeError for the same reason. RLock behavior is even worse: it raises ThreadingError if C accelerator is available in _thread and RuntimeError otherwise. I think RuntimeError should be replaced by ThreadingError for _RLock and Condition implementations as well as docs need to be updated. Also I think this patch should be applied to 3.4 only, it is enchacement, not bugfix. About fixing docs for 2.7-3.3: I see nothing wrong if current inconsistency will be documented, perhaps as *warning* or *note* block. ---------- components: +Library (Lib) nosy: +asvetlov type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 12:26:25 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 31 Aug 2012 10:26:25 +0000 Subject: [issue13992] Segfault in PyTrash_destroy_chain In-Reply-To: <1328964953.21.0.536994091719.issue13992@psf.upfronthosting.co.za> Message-ID: <1346408785.9.0.762769290356.issue13992@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 12:27:20 2012 From: report at bugs.python.org (Mike Hoy) Date: Fri, 31 Aug 2012 10:27:20 +0000 Subject: [issue15829] Threading Lock - Wrong Exception Name In-Reply-To: <1346406935.1.0.0548021295601.issue15829@psf.upfronthosting.co.za> Message-ID: <1346408840.38.0.868142689115.issue15829@psf.upfronthosting.co.za> Mike Hoy added the comment: >>I think RuntimeError should be replaced by ThreadingError for _RLock >>and Condition implementations as well as docs need to be updated. >> >>Also I think this patch should be applied to 3.4 only, it is >>enchacement, not bugfix. >>About fixing docs for 2.7-3.3: I see nothing wrong if current >>inconsistency will be documented, perhaps as *warning* or *note* block. I should warn that ThreadError or `ThreadError` has no link. I've tried to find a place in the docs I could link to but haven't yet. `ValueError` does have a link. ---------- type: enhancement -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 12:27:21 2012 From: report at bugs.python.org (Mike Hoy) Date: Fri, 31 Aug 2012 10:27:21 +0000 Subject: [issue15829] Threading Lock - Wrong Exception Name In-Reply-To: <1346406935.1.0.0548021295601.issue15829@psf.upfronthosting.co.za> Message-ID: <1346408841.8.0.901324625564.issue15829@psf.upfronthosting.co.za> Mike Hoy added the comment: >>I think RuntimeError should be replaced by ThreadingError for _RLock >>and Condition implementations as well as docs need to be updated. >> >>Also I think this patch should be applied to 3.4 only, it is >>enchacement, not bugfix. >>About fixing docs for 2.7-3.3: I see nothing wrong if current >>inconsistency will be documented, perhaps as *warning* or *note* block. I should warn that ThreadError or `ThreadError` has no link. I've tried to find a place in the docs I could link to but haven't yet. `ValueError` does have a link. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 12:27:29 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 31 Aug 2012 10:27:29 +0000 Subject: [issue15819] Unable to build Python out-of-tree when source tree is readonly. In-Reply-To: <1346309362.14.0.312540957077.issue15819@psf.upfronthosting.co.za> Message-ID: <1346408849.35.0.0952527372013.issue15819@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- stage: committed/rejected -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 12:32:49 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 31 Aug 2012 10:32:49 +0000 Subject: [issue15829] Threading Lock - Wrong Exception Name In-Reply-To: <1346406935.1.0.0548021295601.issue15829@psf.upfronthosting.co.za> Message-ID: <1346409169.43.0.39210044144.issue15829@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- Removed message: http://bugs.python.org/msg169518 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 12:38:47 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 31 Aug 2012 10:38:47 +0000 Subject: [issue15829] Threading Lock - Wrong Exception Name In-Reply-To: <1346406935.1.0.0548021295601.issue15829@psf.upfronthosting.co.za> Message-ID: <1346409527.52.0.397382695898.issue15829@psf.upfronthosting.co.za> Andrew Svetlov added the comment: ValueError can be referenced by :exc:`ValueError`. For ThreadError you can add section for describing this exception type like: .. exception:: ThreadError Raised when lock object cannot be acquired or released. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 12:39:33 2012 From: report at bugs.python.org (The Written Word) Date: Fri, 31 Aug 2012 10:39:33 +0000 Subject: [issue15340] OSError with "import random" when /dev/urandom doesn't exist (regression from 2.6) In-Reply-To: <1342132229.15.0.69254682318.issue15340@psf.upfronthosting.co.za> Message-ID: <1346409573.43.0.398897898187.issue15340@psf.upfronthosting.co.za> The Written Word added the comment: The root of the problem preventing me from running some 3rd party setup.py scripts correctly is the mismatch between (recently) raising an OSError in Python/random.c, but catching only NotImplementedError in Lib/random.py. For backwards compatibility (previous releases all raised and caught NotImplementedError), here is a patch that stops Python bailing out with "OSError: No such file or directory /dev/urandom" for me. Tested with Python-2.6.8, Python-2.7.3 and Python-3.2.3, on HPUX 11.00, HPUX 11.11 and Tru 64 5.1. Arguably, as long as 3rd party code doesn't rely on the NotImplementedError exception, changing random.py to catch OSErrors would work equally well. This patch does not stop dev_urandom_noraise() from halting the interpreter on machines with no /dev/urandom, but that seems intentional to me so I didn't try to fix it. ---------- components: +Interpreter Core -Library (Lib) keywords: +patch Added file: http://bugs.python.org/file27070/hash-randomization-not-implemented.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 12:51:06 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 31 Aug 2012 10:51:06 +0000 Subject: [issue15340] OSError with "import random" when /dev/urandom doesn't exist (regression from 2.6) In-Reply-To: <1342132229.15.0.69254682318.issue15340@psf.upfronthosting.co.za> Message-ID: <1346410266.16.0.820083373103.issue15340@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Looks like a critical regression to me. ---------- nosy: +barry, benjamin.peterson, georg.brandl, pitrou priority: normal -> release blocker versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 12:55:37 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 31 Aug 2012 10:55:37 +0000 Subject: [issue15825] Typo in OrderedDict docs In-Reply-To: <1346362159.24.0.0813127284667.issue15825@psf.upfronthosting.co.za> Message-ID: <3X7ctH6pRhzQC7@mail.python.org> Roundup Robot added the comment: New changeset 69952b5599b5 by Andrew Svetlov in branch '2.7': Issue #15825: fix typo in OrderedDict docs. http://hg.python.org/cpython/rev/69952b5599b5 New changeset 8877d25119ef by Andrew Svetlov in branch '3.2': Issue #15825: fix typo in OrderedDict docs. http://hg.python.org/cpython/rev/8877d25119ef New changeset ef80ce83eab1 by Andrew Svetlov in branch 'default': Issue #15825: fix typo in OrderedDict docs. http://hg.python.org/cpython/rev/ef80ce83eab1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 12:59:00 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 31 Aug 2012 10:59:00 +0000 Subject: [issue15825] Typo in OrderedDict docs In-Reply-To: <1346362159.24.0.0813127284667.issue15825@psf.upfronthosting.co.za> Message-ID: <1346410740.38.0.958599675626.issue15825@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Thanks. ---------- nosy: +asvetlov resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 13:10:20 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 31 Aug 2012 11:10:20 +0000 Subject: [issue15828] imp.load_module doesn't support C_EXTENSION type In-Reply-To: <1346398348.83.0.242228991466.issue15828@psf.upfronthosting.co.za> Message-ID: <1346411420.93.0.882722733258.issue15828@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +brett.cannon, ncoghlan priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 13:36:20 2012 From: report at bugs.python.org (Mike Hoy) Date: Fri, 31 Aug 2012 11:36:20 +0000 Subject: [issue15829] Threading Lock - Wrong Exception Name In-Reply-To: <1346406935.1.0.0548021295601.issue15829@psf.upfronthosting.co.za> Message-ID: <1346412980.59.0.43211348227.issue15829@psf.upfronthosting.co.za> Mike Hoy added the comment: I discussed this in IRC and got the following information from Ezio: < Taggnostr> the doc fix can go in 2.7/3.3, the code fix in 3.4 Plan is to put the definition for ThreadError in threading.rst for both 2.7 and 3.3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 13:39:52 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 31 Aug 2012 11:39:52 +0000 Subject: [issue15829] Threading Lock - Wrong Exception Name In-Reply-To: <1346406935.1.0.0548021295601.issue15829@psf.upfronthosting.co.za> Message-ID: <1346413192.06.0.686502536716.issue15829@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Sounds good. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 14:22:46 2012 From: report at bugs.python.org (Mike Hoy) Date: Fri, 31 Aug 2012 12:22:46 +0000 Subject: [issue15829] Threading Lock - Wrong Exception Name In-Reply-To: <1346406935.1.0.0548021295601.issue15829@psf.upfronthosting.co.za> Message-ID: <1346415766.46.0.260508673365.issue15829@psf.upfronthosting.co.za> Mike Hoy added the comment: 3.3 patch ---------- keywords: +patch Added file: http://bugs.python.org/file27071/15829-thread-errror3.3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 14:23:14 2012 From: report at bugs.python.org (Mike Hoy) Date: Fri, 31 Aug 2012 12:23:14 +0000 Subject: [issue15829] Threading Lock - Wrong Exception Name In-Reply-To: <1346406935.1.0.0548021295601.issue15829@psf.upfronthosting.co.za> Message-ID: <1346415794.67.0.668968658251.issue15829@psf.upfronthosting.co.za> Mike Hoy added the comment: 2.7 patch. ---------- Added file: http://bugs.python.org/file27072/15829-thread-errror2.7.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 14:33:38 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 31 Aug 2012 12:33:38 +0000 Subject: [issue15828] imp.load_module doesn't support C_EXTENSION type In-Reply-To: <1346398348.83.0.242228991466.issue15828@psf.upfronthosting.co.za> Message-ID: <1346416418.77.0.288978221113.issue15828@psf.upfronthosting.co.za> Nick Coghlan added the comment: An even easier reproducer: >>> import imp [93559 refs] >>> details = imp.find_module("_elementtree") [93572 refs] >>> mod = imp.load_module('_elementtree', *details) Traceback (most recent call last): File "", line 1, in File "/home/ncoghlan/devel/py3k/Lib/imp.py", line 171, in load_module raise ImportError(msg, name=name) ImportError: Don't know how to import _elementtree (type code 3 [93572 refs] ---------- keywords: +3.3regression _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 14:55:39 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 31 Aug 2012 12:55:39 +0000 Subject: [issue15828] imp.load_module doesn't support C_EXTENSION type In-Reply-To: <1346398348.83.0.242228991466.issue15828@psf.upfronthosting.co.za> Message-ID: <1346417739.78.0.604943131381.issue15828@psf.upfronthosting.co.za> Nick Coghlan added the comment: Patch adds test case and fix (there was simply a missing entry for C_EXTENSION/load_dynamic in the load_module if-elif chain). Also moves an imp module test from test_import to test_imp (it's the test I used as a guide to check I wasn't missing anything obvious when writing the new one). ---------- keywords: +patch Added file: http://bugs.python.org/file27073/issue15828_handle_extension_modules.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 14:57:40 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 31 Aug 2012 12:57:40 +0000 Subject: [issue15828] imp.load_module doesn't support C_EXTENSION type In-Reply-To: <1346398348.83.0.242228991466.issue15828@psf.upfronthosting.co.za> Message-ID: <1346417860.63.0.993541236114.issue15828@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- nosy: +georg.brandl stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 14:59:08 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 31 Aug 2012 12:59:08 +0000 Subject: [issue15828] imp.load_module doesn't support C_EXTENSION type In-Reply-To: <1346398348.83.0.242228991466.issue15828@psf.upfronthosting.co.za> Message-ID: <1346417948.9.0.603399635611.issue15828@psf.upfronthosting.co.za> Nick Coghlan added the comment: Tweaked patch to also fix the typo in the error message ---------- Added file: http://bugs.python.org/file27074/issue15828_handle_extension_modules.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 14:59:20 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 31 Aug 2012 12:59:20 +0000 Subject: [issue15828] imp.load_module doesn't support C_EXTENSION type In-Reply-To: <1346398348.83.0.242228991466.issue15828@psf.upfronthosting.co.za> Message-ID: <1346417960.01.0.971941358622.issue15828@psf.upfronthosting.co.za> Changes by Nick Coghlan : Removed file: http://bugs.python.org/file27073/issue15828_handle_extension_modules.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 15:07:29 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 31 Aug 2012 13:07:29 +0000 Subject: [issue15828] imp.load_module doesn't support C_EXTENSION type In-Reply-To: <1346398348.83.0.242228991466.issue15828@psf.upfronthosting.co.za> Message-ID: <1346418449.3.0.52560523192.issue15828@psf.upfronthosting.co.za> Nick Coghlan added the comment: I'm heading to bed, so whoever reviews this one, please feel free to add a NEWS entry and check it in :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 15:07:30 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 31 Aug 2012 13:07:30 +0000 Subject: [issue15829] Threading Lock - Wrong Exception Name In-Reply-To: <1346406935.1.0.0548021295601.issue15829@psf.upfronthosting.co.za> Message-ID: <1346418450.9.0.854605068097.issue15829@psf.upfronthosting.co.za> R. David Murray added the comment: Please see Issue 14502. The docs probably do need clarification, but it must be done carefully. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 15:08:11 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 31 Aug 2012 13:08:11 +0000 Subject: [issue15828] imp.load_module doesn't support C_EXTENSION type In-Reply-To: <1346398348.83.0.242228991466.issue15828@psf.upfronthosting.co.za> Message-ID: <1346418491.8.0.295663258342.issue15828@psf.upfronthosting.co.za> Brett Cannon added the comment: LGTM ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 15:19:09 2012 From: report at bugs.python.org (Trent Nelson) Date: Fri, 31 Aug 2012 13:19:09 +0000 Subject: [issue15819] Unable to build Python out-of-tree when source tree is readonly. In-Reply-To: <1346309362.14.0.312540957077.issue15819@psf.upfronthosting.co.za> Message-ID: <1346419149.67.0.667858316622.issue15819@psf.upfronthosting.co.za> Trent Nelson added the comment: Well, that escalated quickly :-) I think I should clarify my use case that resulted in raising this bug. 1. Create a fresh hg clone, say, ~/hg/cpython-3.2. 2. Make it readonly: `zfs set readonly=on tank/home/cpython/hg/cpython-3.2` 3. cd /tmp/cpython-3.2-build 4. /home/cpython/hg/cpython-3.2/configure --srcdir=/home/cpython/hg/cpython-3.2/configure So, my patches address that use case. The thing I like about the approach above is that I can set the source directory to readonly immediately -- I don't have to do an intermediate ./configure in that directory in order to generate a Makefile so I can `make touch`. (Side note: I'm almost certain `make touch` wouldn't work for my use case.) Richard: what was your use case? What steps did you take that resulted in getting typeslots.inc and _sysconfigdata.py written to? ....although I just tried an out-of-tree build with 'default' using the exact steps above and got the same error with _sysconfigdata.py. Martin: I think I understand your arguments, and I (think) I agree with them. Especially your last point with regards to always running ASDLGEN. I think I'm +1 on reverting and trying the '-' approach originally used by Neil. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 15:20:16 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 31 Aug 2012 13:20:16 +0000 Subject: [issue14502] Document better what happens on releasing an unacquired lock In-Reply-To: <1333609616.9.0.633115743228.issue14502@psf.upfronthosting.co.za> Message-ID: <1346419216.6.0.484413213724.issue14502@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 15:56:31 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 31 Aug 2012 13:56:31 +0000 Subject: [issue15819] Unable to build Python out-of-tree when source tree is readonly. In-Reply-To: <1346419149.67.0.667858316622.issue15819@psf.upfronthosting.co.za> Message-ID: <5040C28C.9060300@v.loewis.de> Martin v. L?wis added the comment: Am 31.08.12 15:19, schrieb Trent Nelson: > I think I should clarify my use case that resulted in raising this > bug. > > 1. Create a fresh hg clone, say, ~/hg/cpython-3.2. > 2. Make it readonly The use case is really uncontended, and long-standing. People want to build from CD-ROM sources, from sources mounted via NFS, from sources owned by some other user - there are really many reasons why you want to build in a separate directory, and why you then do not want the original source be clobbered. > Richard: what was your use case? I guess pretty much the same (though perhaps not ZFS). > What steps did you take that > resulted in getting typeslots.inc and _sysconfigdata.py written to? Touch Include/typeslots.h (before making the checkout readonly) to see this problem. On a hg checkout, it really depends on the order in which Mercurial creates the files to either run or not run into one of these issues. You were lucky that the timestamps happened to be in an order were in an order that caused typeslots.inc to be newer than its sources. AFAIK, hg uses alphapbetical order when updating files, so this may have helped. > I think I'm +1 on reverting and trying the '-' approach originally > used by Neil. Please don't. I think Victor dropped the - because it would mask errors from running pgen. pgen might fail, but pgen.stamp is still generated. Then, on a subsequent run, pgen would not run again. Of course, pgen.stamp is a later addition (by me), so this wasn't originally a problem. I think the regular case should be that the time stamps are in the right order in the source tree, so none of the generators should run. But if they happen to be in the wrong order (either because of Mercurial, or because one of the sources was actually modified), then the generators should run and output into the build directory. Since the committed patch is already a step in that direction, I think it now needs to be completed. It's mandatory (IMO) that the generated files are actually used; that the generators are not run if not needed is optional and can be fixed later. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 16:03:16 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 31 Aug 2012 14:03:16 +0000 Subject: [issue15830] make -s no longer silences output from setup.py Message-ID: <1346421796.43.0.205634084125.issue15830@psf.upfronthosting.co.za> New submission from Brett Cannon: Sometime in the last month (probably) I change has been made in either configure(.ac), Makefile.pre.in, or setup.py that is causing the -s option passed to make to not also make its way into setup.py when extensions are built. ---------- components: Build keywords: 3.2regression messages: 169536 nosy: brett.cannon priority: normal severity: normal status: open title: make -s no longer silences output from setup.py versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 16:12:02 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 31 Aug 2012 14:12:02 +0000 Subject: [issue15828] imp.load_module doesn't support C_EXTENSION type In-Reply-To: <1346398348.83.0.242228991466.issue15828@psf.upfronthosting.co.za> Message-ID: <1346422322.68.0.572934895164.issue15828@psf.upfronthosting.co.za> Nick Coghlan added the comment: Since I'm still up, I guess I'll check it in, then :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 16:18:51 2012 From: report at bugs.python.org (Manu Cupcic) Date: Fri, 31 Aug 2012 14:18:51 +0000 Subject: [issue13992] Segfault in PyTrash_destroy_chain In-Reply-To: <1328964953.21.0.536994091719.issue13992@psf.upfronthosting.co.za> Message-ID: <1346422731.44.0.28658772606.issue13992@psf.upfronthosting.co.za> Manu Cupcic added the comment: I am testing this patch right now. Will report back. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 16:15:01 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 31 Aug 2012 14:15:01 +0000 Subject: [issue15828] imp.load_module doesn't support C_EXTENSION type In-Reply-To: <1346398348.83.0.242228991466.issue15828@psf.upfronthosting.co.za> Message-ID: <1346422501.8.0.365194287271.issue15828@psf.upfronthosting.co.za> Nick Coghlan added the comment: Over to Georg to cherry pick this one into rc2 ---------- assignee: -> georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 16:13:55 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 31 Aug 2012 14:13:55 +0000 Subject: [issue15828] imp.load_module doesn't support C_EXTENSION type In-Reply-To: <1346398348.83.0.242228991466.issue15828@psf.upfronthosting.co.za> Message-ID: <3X7jH63R07zQG7@mail.python.org> Roundup Robot added the comment: New changeset 9ba57938f54d by Nick Coghlan in branch 'default': Issue #15828: Restore support for C extension modules in imp.load_module() http://hg.python.org/cpython/rev/9ba57938f54d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 16:40:38 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 31 Aug 2012 14:40:38 +0000 Subject: [issue15819] Unable to build Python out-of-tree when source tree is readonly. In-Reply-To: <1346309362.14.0.312540957077.issue15819@psf.upfronthosting.co.za> Message-ID: <1346424038.29.0.327812760578.issue15819@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > Richard: what was your use case? Building on the main host and a VM without having to commit and synchronize temporary changes. (The VM has read-only access to the host's repositories). > What steps did you take that resulted in getting typeslots.inc and > _sysconfigdata.py written to? As Martin says it is probably just the timestamps which caused typeslots.inc to be rebuilt. In 3.3 _sysconfigdata.py is rebuilt whenever the python binary is. I suspect a bigger issue is the fact that *.pyc files cannot be written to $(srcdir)/Lib/__pycache__. This means that to complete the build, $(PYTHON_FOR_BUILD) should probably include the -B flag to prevent it from trying to write *.pyc files to a read-only location. But that still leaves you with a python which only works with the -B flag. Maybe library files could be linked/copied to some writable directory early in sys.path. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 16:57:22 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 31 Aug 2012 14:57:22 +0000 Subject: [issue15819] Unable to build Python out-of-tree when source tree is readonly. In-Reply-To: <1346424038.29.0.327812760578.issue15819@psf.upfronthosting.co.za> Message-ID: <5040D0D0.10806@v.loewis.de> Martin v. L?wis added the comment: Am 31.08.12 16:40, schrieb Richard Oudkerk: > I suspect a bigger issue is the fact that *.pyc files cannot be > written to $(srcdir)/Lib/__pycache__. This means that to complete > the build, $(PYTHON_FOR_BUILD) should probably include the -B flag to > prevent it from trying to write *.pyc files to a read-only location. Why is that? python will work just fine if it can't write pyc files. > But that still leaves you with a python which only works with the -B > flag. Maybe library files could be linked/copied to some writable > directory early in sys.path. Just for running setup.py? I don't see the need for that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 17:31:30 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 31 Aug 2012 15:31:30 +0000 Subject: [issue15828] imp.load_module doesn't support C_EXTENSION type In-Reply-To: <1346398348.83.0.242228991466.issue15828@psf.upfronthosting.co.za> Message-ID: <3X7l0d4PlKzQLr@mail.python.org> Roundup Robot added the comment: New changeset d54f047312a8 by Brett Cannon in branch 'default': Issue #15828: Don't try to close a file if imp.find_module() doesn't http://hg.python.org/cpython/rev/d54f047312a8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 17:32:08 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 31 Aug 2012 15:32:08 +0000 Subject: [issue15819] Unable to build Python out-of-tree when source tree is readonly. In-Reply-To: <1346309362.14.0.312540957077.issue15819@psf.upfronthosting.co.za> Message-ID: <1346427128.61.0.955285858823.issue15819@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > Why is that? python will work just fine if it can't write pyc files. When I hacked around the _sysconfigdata.py issue, running the created python produced Fatal Python error: Py_Initialize: Unable to get the locale encoding Traceback (most recent call last): File "/mnt/hgfs/Repos/cpython-dirty/Lib/encodings/__init__.py", line 31, in File "", line 1562, in _find_and_load File "", line 1529, in _find_and_load_unlocked File "", line 590, in _check_name_wrapper File "", line 1027, in load_module File "", line 1008, in load_module File "", line 566, in module_for_loader_wrapper File "", line 858, in _load_module File "", line 994, in get_code File "", line 1055, in _cache_bytecode File "", line 1078, in set_data File "", line 128, in _write_atomic OSError: [Errno 5] Input/output error: '/mnt/hgfs/Repos/cpython-dirty/Lib/__pycache__/codecs.cpython-33.pyc.3076609376' Aborted I took this to be a failure to write the bytecompiled file. (A regression?) Running "./python -B" does work correctly for me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 17:40:05 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 31 Aug 2012 15:40:05 +0000 Subject: [issue15819] Unable to build Python out-of-tree when source tree is readonly. In-Reply-To: <1346309362.14.0.312540957077.issue15819@psf.upfronthosting.co.za> Message-ID: <1346427605.61.0.787272441875.issue15819@psf.upfronthosting.co.za> Richard Oudkerk added the comment: It looks like the code which writes the byte-compiled codes checks for and ignores PermissionError (EACCES, EPERM) and FileExistsError (EEXIST). However, for me it is EIO which is raised. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 17:49:06 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 31 Aug 2012 15:49:06 +0000 Subject: [issue15819] Unable to build Python out-of-tree when source tree is readonly. In-Reply-To: <1346427128.61.0.955285858823.issue15819@psf.upfronthosting.co.za> Message-ID: <5040DCF0.1010109@v.loewis.de> Martin v. L?wis added the comment: Am 31.08.12 17:32, schrieb Richard Oudkerk: > File "", line 128, in _write_atomic > OSError: [Errno 5] Input/output error: '/mnt/hgfs/Repos/cpython-dirty/Lib/__pycache__/codecs.cpython-33.pyc.3076609376' > Aborted > > I took this to be a failure to write the bytecompiled file. (A regression?) Sounds like a regression to me. However, errno 5 is EIO. Normally, you should get PermissionError(errno=13, EACCES). I could understand EROFS as well. This sounds like a bug in the VM software, which really should report EROFS if the volume is read-only, not EIO. You might want to check whether this really is a regression; in any case, I consider Python's reaction reasonable and then your setup as just not supported. However, I could also accept that a work-around is added for treating EIO also as an ignorable error. In any case, this is a separate issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 17:57:14 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 31 Aug 2012 15:57:14 +0000 Subject: [issue15831] comma after leading optional argument is after bracket in docs Message-ID: <1346428634.66.0.0584130722662.issue15831@psf.upfronthosting.co.za> New submission from Chris Jerdonek: >From docs at python.org: """ In a number of places we find documentation with optional leading arguments where the meta-notation (square brackets) are in the wrong place. For example, for range, the standard doc heading says range([start], stop [, step]) # The comma after start should be inside the square bracket, not outside. The same error occurs with docs for print, and for slice, for random.randrange and for random.seed, etc, etc. This seems a consistent bug whenever a function or method takes an optional first argument, and it looks like it might have been put there by some tool that generates the docs. I use Python 3 - perhaps there was once a time when one had to supply the comma if one omitted the first argument? In Python 3 it gives errors if one follows the documentation carefully and uses the comma. """" (or see http://mail.python.org/pipermail/docs/2012-August/010051.html ) ---------- assignee: docs at python components: Documentation messages: 169547 nosy: cjerdonek, docs at python priority: normal severity: normal status: open title: comma after leading optional argument is after bracket in docs type: behavior versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 17:58:22 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 31 Aug 2012 15:58:22 +0000 Subject: [issue15831] comma after leading optional argument is after bracket in docs In-Reply-To: <1346428634.66.0.0584130722662.issue15831@psf.upfronthosting.co.za> Message-ID: <1346428702.81.0.952425076112.issue15831@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +easy nosy: +ezio.melotti stage: -> needs patch versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 18:07:38 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 31 Aug 2012 16:07:38 +0000 Subject: [issue15831] comma after leading optional argument is after bracket in docs In-Reply-To: <1346428634.66.0.0584130722662.issue15831@psf.upfronthosting.co.za> Message-ID: <1346429258.79.0.521528974481.issue15831@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 18:08:10 2012 From: report at bugs.python.org (Riccardo Murri) Date: Fri, 31 Aug 2012 16:08:10 +0000 Subject: [issue15832] argparse: typechecks default value too early Message-ID: <1346429290.76.0.112195597635.issue15832@psf.upfronthosting.co.za> New submission from Riccardo Murri: The `argparse` module (tested with 2.7, but other versions might be affected) checks the `default` value of an option too early: if the default value raises an exception, then command-line parsing stops. Consider for example the following code: ############### begin sample ##################### import os import argparse def existing_filename(path): if not os.access(path, os.F_OK | os.R_OK): raise argparse.ArgumentTypeError("File '%s' does not exist or cannot be read." % path) return path parser = argparse.ArgumentParser(description='Process a file.') parser.add_argument('file', type=existing_filename, default='/some/weird/default', help='A file to process.') args = parser.parse_args() print ("Will process file '%s' ..." % args.file) ############### end sample ##################### The intention here is that the default value should be used *if and only if* the script users do not provide their own file to process. It may happen that the default is invalid, but that should be reported as an error only if the default is used, i.e., users did not provide any file name to the script. What happens instead is that the argparse errors out in any case, even when `--help` is requested or when a valid file name is passed, as the following two examples show: rmurri at xenia:/tmp$ ./argparse-processes-defaults-too-early.py --help Traceback (most recent call last): File "./argparse-processes-defaults-too-early.py", line 18, in args = parser.parse_args() File "/usr/lib/python2.7/argparse.py", line 1688, in parse_args args, argv = self.parse_known_args(args, namespace) File "/usr/lib/python2.7/argparse.py", line 1710, in parse_known_args default = self._get_value(action, default) File "/usr/lib/python2.7/argparse.py", line 2239, in _get_value raise ArgumentError(action, msg) argparse.ArgumentError: argument file: File '/some/weird/default' does not exist or cannot be read. rmurri at xenia:/tmp$ ./argparse-processes-defaults-too-early.py /tmp/xxx.py Traceback (most recent call last): File "./argparse-processes-defaults-too-early.py", line 18, in args = parser.parse_args() File "/usr/lib/python2.7/argparse.py", line 1688, in parse_args args, argv = self.parse_known_args(args, namespace) File "/usr/lib/python2.7/argparse.py", line 1710, in parse_known_args default = self._get_value(action, default) File "/usr/lib/python2.7/argparse.py", line 2239, in _get_value raise ArgumentError(action, msg) argparse.ArgumentError: argument file: File '/some/weird/default' does not exist or cannot be read. Thanks! ---------- components: Library (Lib) messages: 169548 nosy: riccardomurri priority: normal severity: normal status: open title: argparse: typechecks default value too early type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 18:11:43 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 31 Aug 2012 16:11:43 +0000 Subject: [issue15831] comma after leading optional argument is after bracket in docs In-Reply-To: <1346428634.66.0.0584130722662.issue15831@psf.upfronthosting.co.za> Message-ID: <1346429503.02.0.0665891998383.issue15831@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Do we know that this is easy? It might be a Sphinx issue, in which case it might not be as trivial as fixing typos. I ask because the reST file looks correct (for range() for example): .. function:: range([start,] stop[, step]) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 18:15:35 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 31 Aug 2012 16:15:35 +0000 Subject: [issue15831] comma after leading optional argument is after bracket in docs In-Reply-To: <1346428634.66.0.0584130722662.issue15831@psf.upfronthosting.co.za> Message-ID: <1346429735.63.0.54571532091.issue15831@psf.upfronthosting.co.za> Ezio Melotti added the comment: I thought that was just a matter of finding the wrong commas and fixing them, but if they are correct in the source, then the situation might be a bit more complicated. Does this happen only with "unusual" signatures like range([start], stop [, step])? FWIW this could be replaced with: range(stop) range(start, stop [, step]) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 18:17:59 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 31 Aug 2012 16:17:59 +0000 Subject: [issue15832] argparse: typechecks default value too early In-Reply-To: <1346429290.76.0.112195597635.issue15832@psf.upfronthosting.co.za> Message-ID: <1346429879.59.0.612516688277.issue15832@psf.upfronthosting.co.za> R. David Murray added the comment: It is possible this could be considered a feature rather than a bug :) Let's see what Steven thinks. ---------- nosy: +bethard, r.david.murray versions: +Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 18:18:04 2012 From: report at bugs.python.org (Eric Snow) Date: Fri, 31 Aug 2012 16:18:04 +0000 Subject: [issue15819] Unable to build Python out-of-tree when source tree is readonly. In-Reply-To: <1346309362.14.0.312540957077.issue15819@psf.upfronthosting.co.za> Message-ID: <1346429884.22.0.787903927296.issue15819@psf.upfronthosting.co.za> Eric Snow added the comment: Doesn't EIO cover pathologies which we don't want to silence? I could see adding EROFS though. ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 18:21:27 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 31 Aug 2012 16:21:27 +0000 Subject: [issue15831] comma after leading optional argument is after bracket in docs In-Reply-To: <1346428634.66.0.0584130722662.issue15831@psf.upfronthosting.co.za> Message-ID: <1346430087.78.0.934901183614.issue15831@psf.upfronthosting.co.za> Chris Jerdonek added the comment: This is what my search for ",] " gave me (though the OP's print and random.seed do not show up in this list): library/curses.rst 380:.. function:: newwin([nlines, ncols,] begin_y, begin_x) 659:.. method:: window.addch([y, x,] ch[, attr]) 673:.. method:: window.addnstr([y, x,] str, n[, attr]) 679:.. method:: window.addstr([y, x,] str[, attr]) 766:.. method:: window.chgat([y, x, ] [num,] attr) 815:.. method:: window.derwin([nlines, ncols,] begin_y, begin_x) 909:.. method:: window.hline([y, x,] ch, n) 943:.. method:: window.insch([y, x,] ch[, attr]) 964:.. method:: window.insnstr([y, x,] str, n [, attr]) 1156:.. method:: window.subpad([nlines, ncols,] begin_y, begin_x) 1162:.. method:: window.subwin([nlines, ncols,] begin_y, begin_x) 1219:.. method:: window.vline([y, x,] ch, n) library/functions.rst 1064:.. function:: range([start,] stop[, step]) 1129:.. function:: slice([start,] stop[, step]) library/itertools.rst 55::func:`islice` seq, [start,] stop [, step] elements from seq[start:stop:step] ``islice('ABCDEFG', 2, None) --> C D E F G`` 404:.. function:: islice(iterable, [start,] stop [, step]) library/random.rst 96:.. function:: randrange([start,] stop[, step]) library/syslog.rst 20:.. function:: syslog([priority,] message) library/tkinter.tix.rst 507:.. method:: tixCommand.tix_configure([cnf,] **kw) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 18:25:59 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 31 Aug 2012 16:25:59 +0000 Subject: [issue15826] Increased test coverage of test_glob.py In-Reply-To: <1346381534.69.0.636623200483.issue15826@psf.upfronthosting.co.za> Message-ID: <1346430359.26.0.263609399428.issue15826@psf.upfronthosting.co.za> Ezio Melotti added the comment: I think it would be easier to subclass GlobTests and override norm and glob there (assuming that doesn't create problems with some of the tests). ---------- nosy: +ezio.melotti stage: -> patch review versions: +Python 3.2, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 18:32:14 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 31 Aug 2012 16:32:14 +0000 Subject: [issue15831] comma after leading optional argument is after bracket in docs In-Reply-To: <1346428634.66.0.0584130722662.issue15831@psf.upfronthosting.co.za> Message-ID: <1346430734.97.0.258107167982.issue15831@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Yes, it looks like Sphinx problem. About having tho signatures for single function/method. Does Sphinx support it for *.. function::*? Pointing to anchor for first signature with adding second one somewhere in paragraph text doesn't look good. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 18:42:53 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 31 Aug 2012 16:42:53 +0000 Subject: [issue15815] Add numerator to ZeroDivisionError messages In-Reply-To: <1346268284.86.0.294059613354.issue15815@psf.upfronthosting.co.za> Message-ID: <1346431373.26.0.262781415851.issue15815@psf.upfronthosting.co.za> Ezio Melotti added the comment: I'm not sure this is really useful. Once I know that I divided by zero and I know where the division is, I don't really care what the numerator is. Knowing the exact type of the denominator (0, 0.0, 0j) doesn't sound too useful as well -- unless you somehow manage to get the wrong type and a 0-value at the same time. On a side note, I don't like ZeroDivisionError: integer division or modulo of 3 by 0 too much, but I would prefer ZeroDivisionError: integer division (or modulo) by zero over ZeroDivisionError: integer division or modulo by zero IIRC the reason why both "division" and "modulo" are included in the message is because the error is created in a piece of code that is shared by both operations. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 18:45:25 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 31 Aug 2012 16:45:25 +0000 Subject: [issue15831] comma after leading optional argument is after bracket in docs In-Reply-To: <1346428634.66.0.0584130722662.issue15831@psf.upfronthosting.co.za> Message-ID: <1346431525.79.0.524145521416.issue15831@psf.upfronthosting.co.za> Ezio Melotti added the comment: > Does Sphinx support it for *.. function::*? I'm pretty sure it does for methods, so I don't see why it shouldn't work for functions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 18:45:43 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 31 Aug 2012 16:45:43 +0000 Subject: [issue15819] Unable to build Python out-of-tree when source tree is readonly. In-Reply-To: <1346429884.22.0.787903927296.issue15819@psf.upfronthosting.co.za> Message-ID: <5040EA35.7020607@v.loewis.de> Martin v. L?wis added the comment: Am 31.08.12 18:18, schrieb Eric Snow: > Doesn't EIO cover pathologies which we don't want to silence? I could see adding EROFS though. [This should *really* be its own issue] Sure, EIO indicates normally something pathological, such as a broken cable to the disk. I'm not sure it needs to be reported, though, at least not when coming out of open(): we are trying to write to the cache, and that failed really bad. However, this is not bad for Python: if we don't have a cache file, we can still continue executing. If we get EIO in the middle of writing, this would be worse. So as a work-around, I could propose to map OSError(EIO) coming out of open into PermissionError(EIO) (inside _bootstrap). But as I said: I'd also be fine with declaring this VM software unsupported. If this work-around is added, we should record the exact software for which it is a work-around, so we can remove it in the future. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 18:48:40 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 31 Aug 2012 16:48:40 +0000 Subject: [issue15831] comma after leading optional argument is after bracket in docs In-Reply-To: <1346428634.66.0.0584130722662.issue15831@psf.upfronthosting.co.za> Message-ID: <1346431720.72.0.789541749884.issue15831@psf.upfronthosting.co.za> Andrew Svetlov added the comment: No, methods for *curses* are also corrupted. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 18:49:35 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Fri, 31 Aug 2012 16:49:35 +0000 Subject: [issue15701] AttributeError from HTTPError when using digest auth In-Reply-To: <1345149357.77.0.903430006119.issue15701@psf.upfronthosting.co.za> Message-ID: <1346431775.92.0.770557396498.issue15701@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Okay, this is funny. first info is invoking addinfourl of urllib, which would return headers. But in urllib2, the headers are self.hdrs I would side with the documentation that info is advertised method for HTTPError object. In 2.7, I guess just docs could be improved. This problem would be the present in 3.x. ---------- assignee: -> orsenthil nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 18:50:19 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 31 Aug 2012 16:50:19 +0000 Subject: [issue15831] comma after leading optional argument is after bracket in docs In-Reply-To: <1346428634.66.0.0584130722662.issue15831@psf.upfronthosting.co.za> Message-ID: <1346431819.12.0.829538147235.issue15831@psf.upfronthosting.co.za> Ezio Melotti added the comment: > This is what my search for ",] " gave me It would be fine with me to use a double signature for these. Georg, do you have any opinion? (The double signature might be easier to understand, but the original issue should probably be fixed in Sphinx, even if we decide to stop using this kind of signature.) ---------- nosy: +eric.araujo, georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 18:51:26 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 31 Aug 2012 16:51:26 +0000 Subject: [issue15831] comma after leading optional argument is after bracket in docs In-Reply-To: <1346428634.66.0.0584130722662.issue15831@psf.upfronthosting.co.za> Message-ID: <1346431886.9.0.992564012318.issue15831@psf.upfronthosting.co.za> Ezio Melotti added the comment: > No, methods for *curses* are also corrupted. I meant the double signature support. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 18:57:03 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 31 Aug 2012 16:57:03 +0000 Subject: [issue15831] comma after leading optional argument is after bracket in docs In-Reply-To: <1346428634.66.0.0584130722662.issue15831@psf.upfronthosting.co.za> Message-ID: <1346432223.66.0.153552875681.issue15831@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > It would be fine with me to use a double signature for these. Just an FYI that more than two signatures would be needed for cases like this: 766:.. method:: window.chgat([y, x, ] [num,] attr) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 18:57:26 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 31 Aug 2012 16:57:26 +0000 Subject: [issue15833] most failures to write byte-compiled file no longer suppressed Message-ID: <1346432246.49.0.876284426658.issue15833@psf.upfronthosting.co.za> New submission from Richard Oudkerk: As discussed in http://bugs.python.org/issue15819 trying to run python built outside a read-only source directory fails for me because OSError(EIO, ...) is raised when importlib tries to write the byte compiled file. (I built python in a Linux VM using VMware Player which only had read-only access to the source directory.) Currently importlib only ignores PermissionError (EACCES, EPERM) and FileExistsError (EEXIST): http://hg.python.org/cpython/file/d54f047312a8/Lib/importlib/_bootstrap.py#l1080 Under Python 3.2 all failures are ignored: http://hg.python.org/cpython/file/69952b5599b5/Python/import.c#l905 so this seems to be a regression. ---------- components: Interpreter Core keywords: 3.3regression messages: 169564 nosy: brett.cannon, sbt priority: normal severity: normal status: open title: most failures to write byte-compiled file no longer suppressed type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 18:59:32 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 31 Aug 2012 16:59:32 +0000 Subject: [issue15831] comma after leading optional argument is after bracket in docs In-Reply-To: <1346428634.66.0.0584130722662.issue15831@psf.upfronthosting.co.za> Message-ID: <1346432372.9.0.206678793276.issue15831@psf.upfronthosting.co.za> Ezio Melotti added the comment: > 766:.. method:: window.chgat([y, x, ] [num,] attr) What's this even supposed to mean? See also #14783. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 19:04:32 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 31 Aug 2012 17:04:32 +0000 Subject: [issue15831] comma after leading optional argument is after bracket in docs In-Reply-To: <1346428634.66.0.0584130722662.issue15831@psf.upfronthosting.co.za> Message-ID: <1346432672.97.0.287727319371.issue15831@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > What's this even supposed to mean? I started wondering the same thing after I posted. :) I guess my point/question is: are there any cases where more than two signatures would be needed to account for all of the possibilities? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 19:09:36 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 31 Aug 2012 17:09:36 +0000 Subject: [issue14783] Update int() docstring from manual In-Reply-To: <1336751413.58.0.519130225761.issue14783@psf.upfronthosting.co.za> Message-ID: <1346432976.22.0.877625171433.issue14783@psf.upfronthosting.co.za> ?ric Araujo added the comment: +1! This notation helps clearing up how int, str and other constructors work. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 19:11:22 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 31 Aug 2012 17:11:22 +0000 Subject: [issue15831] comma after leading optional argument is after bracket in docs In-Reply-To: <1346428634.66.0.0584130722662.issue15831@psf.upfronthosting.co.za> Message-ID: <1346433082.54.0.134722603479.issue15831@psf.upfronthosting.co.za> Ezio Melotti added the comment: I think/hope that all the APIs we have in the stdlib are sane enough to have no more than 2-3 signatures (I'm not counting optional args (at the end) here). If that's not the case we should still be able to add as many signature as we need (I don't know if Sphinx has some limit about it though). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 19:23:12 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 31 Aug 2012 17:23:12 +0000 Subject: [issue15819] Unable to build Python out-of-tree when source tree is readonly. In-Reply-To: <1346309362.14.0.312540957077.issue15819@psf.upfronthosting.co.za> Message-ID: <1346433792.27.0.00228585715582.issue15819@psf.upfronthosting.co.za> Richard Oudkerk added the comment: I have opened a new issue: http://bugs.python.org/issue15833 It is a regression because in Python 3.2 all failures to open the file for writing were supressed. > But as I said: I'd also be fine with declaring this VM software > unsupported. If this work-around is added, we should record the > exact software for which it is a work-around, so we can remove > it in the future. It is VMware Player 4.0.0. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 19:34:25 2012 From: report at bugs.python.org (Steven Bethard) Date: Fri, 31 Aug 2012 17:34:25 +0000 Subject: [issue15832] argparse: typechecks default value too early In-Reply-To: <1346429290.76.0.112195597635.issue15832@psf.upfronthosting.co.za> Message-ID: <1346434465.74.0.957925303292.issue15832@psf.upfronthosting.co.za> Steven Bethard added the comment: It's a bug, but it's already been reported in Issue 12776. There's a patch there, but someone needs to commit it. ---------- superseder: -> argparse: type conversion function should be called only once _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 19:34:41 2012 From: report at bugs.python.org (Steven Bethard) Date: Fri, 31 Aug 2012 17:34:41 +0000 Subject: [issue15832] argparse: typechecks default value too early In-Reply-To: <1346429290.76.0.112195597635.issue15832@psf.upfronthosting.co.za> Message-ID: <1346434481.55.0.00544607269705.issue15832@psf.upfronthosting.co.za> Changes by Steven Bethard : ---------- resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 19:45:33 2012 From: report at bugs.python.org (Ned Deily) Date: Fri, 31 Aug 2012 17:45:33 +0000 Subject: [issue15830] make -s no longer silences output from setup.py In-Reply-To: <1346421796.43.0.205634084125.issue15830@psf.upfronthosting.co.za> Message-ID: <1346435133.36.0.509126283187.issue15830@psf.upfronthosting.co.za> Ned Deily added the comment: Issue15591 perhaps? ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 19:53:58 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 31 Aug 2012 17:53:58 +0000 Subject: [issue15810] assertSequenceEqual should be fired when comparing sequence subclasses In-Reply-To: <1346246299.41.0.924919509525.issue15810@psf.upfronthosting.co.za> Message-ID: <1346435638.68.0.96666510275.issue15810@psf.upfronthosting.co.za> Gregory P. Smith added the comment: When we added this functionality to assertEqual we were *intentionally* conservative on when it would auto-promote to nicer equality comparison functions. It needs to behave exactly as == would in all situations. >>> (1,2,3) == [1,2,3] False We must maintain that behavior in assertEqual. Tests should use assertSequenceEqual when they want to compare sequences regardless of type because they are testing for something less than strict equality. ---------- nosy: +gregory.p.smith resolution: -> rejected stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 19:59:35 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 31 Aug 2012 17:59:35 +0000 Subject: [issue14783] Update int() docstring from manual In-Reply-To: <1336751413.58.0.519130225761.issue14783@psf.upfronthosting.co.za> Message-ID: <1346435975.84.0.663944158942.issue14783@psf.upfronthosting.co.za> Ezio Melotti added the comment: Here's a patch for the signature. ---------- assignee: -> ezio.melotti keywords: +patch stage: needs patch -> commit review Added file: http://bugs.python.org/file27075/issue14783.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 20:34:43 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 31 Aug 2012 18:34:43 +0000 Subject: [issue15821] PyMemoryView_FromBuffer() behavior change (possible regression) In-Reply-To: <1346320388.88.0.494685067241.issue15821@psf.upfronthosting.co.za> Message-ID: <1346438083.63.0.144847991141.issue15821@psf.upfronthosting.co.za> Stefan Krah added the comment: Alexander, your test case is brilliant and could eventually go into _testbuffer.c, but I'd prefer a simpler test case for now. :) Here's a patch that restores the info.obj cleanup facility. I intentionally did not add copying the format in order to keep the diff small (in case this can go into rc2). Crashing on stack addresses for format is not a regression. Apparently PyMemoryView_FromBuffer() is used for low level tinkering and automatic cleanup, so I now think that it's better not to break backwards compatibility, i.e. leave the value of info.obj untouched. Otherwise people using the cleanup facility will have reference leaks. However, I don't like the interface at all: Passing a pointer to a struct and then relying on the fact that *some* values are copied (shape, strides and suboffsets) but not others (format, buf) is counterintuitive. With the ManagedBuffer, we could now write a new function that returns a memoryview with much nicer cleanup facilities. But that doesn't help here since we're stuck with this function for 3.3.0. What do you think? Should this go into 3.3.0? The changes to memoryobject.c are minimal, the rest are tests and docs. ---------- assignee: docs at python -> skrah components: +Interpreter Core -Documentation stage: -> patch review title: Improve docs for PyMemoryView_FromBuffer() -> PyMemoryView_FromBuffer() behavior change (possible regression) type: enhancement -> behavior Added file: http://bugs.python.org/file27076/issue15821.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 20:54:19 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 31 Aug 2012 18:54:19 +0000 Subject: [issue15821] PyMemoryView_FromBuffer() behavior change (possible regression) In-Reply-To: <1346438083.63.0.144847991141.issue15821@psf.upfronthosting.co.za> Message-ID: Alexander Belopolsky added the comment: On Fri, Aug 31, 2012 at 2:34 PM, Stefan Krah wrote: > With the ManagedBuffer, we could now write a new function that returns > a memoryview with much nicer cleanup facilities. But that doesn't help > here since we're stuck with this function for 3.3.0. > > > What do you think? Should this go into 3.3.0? I am still getting up to speed with all the changes that went in since 3.2. I'll review your patch over the weekend. Meanwhile, I think the goal should be that after PyMemoryview_FromBuffer(info) is called, it should be OK to discard info by calling PyBuffer_Release() and if info is not allocated on the stack, Py_DECREF(info). I think we are almost there achieving that goal with possible exception of dynamically or stack-allocated fmt strings. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 21:12:12 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 31 Aug 2012 19:12:12 +0000 Subject: [issue15821] PyMemoryView_FromBuffer() behavior change (possible regression) In-Reply-To: Message-ID: <20120831191212.GA2642@sleipnir.bytereef.org> Stefan Krah added the comment: Alexander Belopolsky wrote: > I am still getting up to speed with all the changes that went in since > 3.2. I'll review your patch over the weekend. Meanwhile, I think the > goal should be that after PyMemoryview_FromBuffer(info) is called, it > should be OK to discard info by calling PyBuffer_Release() Now I'm puzzled: I thought your goal was to preserve the implicit cleanup from 3.2, i.e. PyBuffer_Release() is called when the managed buffer is deallocated. Without the patch it's OK to call PyBuffer_Release(info) after PyMemoryview_FromBuffer(info). With the patch you can't call PyBuffer_Release(info), since it's done automatically already. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 21:31:00 2012 From: report at bugs.python.org (Berker Peksag) Date: Fri, 31 Aug 2012 19:31:00 +0000 Subject: [issue15756] subprocess.poll() does not handle errno.ECHILD "No child processes" In-Reply-To: <1345576517.75.0.906463701582.issue15756@psf.upfronthosting.co.za> Message-ID: <1346441460.21.0.265335849421.issue15756@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- versions: -Python 2.6, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 21:36:40 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 31 Aug 2012 19:36:40 +0000 Subject: [issue14783] Make int() and str() docstrings correct In-Reply-To: <1336751413.58.0.519130225761.issue14783@psf.upfronthosting.co.za> Message-ID: <1346441800.65.0.307269749453.issue14783@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The large issue is documenting complex signatures that do not really fit in any of the standard one-line patterns. I was initially puzzled by Raymond describing the 3.3 line as 'confusing', but putting on 'newbie glasses' I see now that correctly parsing int([number | string[, base]]) requires knowing that '[, option]' binds tighter than '|'. Since ',' normally has the lowest binding priority, someone who does not know the signature already (ie, a target audience member) could parse it as int([ (number | string) [, base]]) rather than as intended: int([number | (string[, base]) ]) So I agree that the two stacked lines in the doc patch are clearer. However, this issue is about the docstring. Leave it incorrect? Change it to the hard-to-parse one liner? Change it to a two-line signature also? I noticed this issue while working on IDLE tooltips, using int as a test case. They currently use only the first line of the docstring, but I have decided that they should get more when needed for C functions. (For Python functions, tooltips use inspect for the actual signature and the first docstring line only for a description.) The first line of the str docstring is also incorrect in that the optional parameters are only valid for first arguments that are strings. str(string[, encoding[, errors]]) -> str It needs either a '|' construction like int or another line: str(object) I prefer the latter. I revised the title to add str.__doc__ to the issue. While we are at it, how about range(stop) range(start, stop, [step]) instead of the current doc and docstring signature range([start,] stop[, step]) ? The current docstring is inaccurate and confusing to some. (How can there be an optional first arg and required second ? -- Answer: there can't.) The technically accurate signature is range(start_or_stop[, stop[, step]]) but that has been rejected as confusing. The bytes and bytearrays docstrings have 5 signature lines!. (The manual gives just one which does not quite cover all cases.) So (a) there is precedent for multiple signatures in docstrings and (b) tooltips already need to grab multiple signature lines. So I think int and str (and maybe range) should use a couple of clear lines. If the new inspect.signature function were to give signatures for C functions, there would be no problem for tooltips, but it does not. (Can signature objects even handle multiple (or type-dependent) signatures?) ---------- nosy: +georg.brandl title: Update int() docstring from manual -> Make int() and str() docstrings correct _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 21:56:45 2012 From: report at bugs.python.org (Thomas Miedema) Date: Fri, 31 Aug 2012 19:56:45 +0000 Subject: [issue15535] Fix pickling of named tuples in 2.7.3 (BUG) In-Reply-To: <1343915086.31.0.252328658724.issue15535@psf.upfronthosting.co.za> Message-ID: <1346443005.71.0.780345011702.issue15535@psf.upfronthosting.co.za> Thomas Miedema added the comment: Added a better testcase. ---------- title: Fix pickling of named tuples in 2.7.3 -> Fix pickling of named tuples in 2.7.3 (BUG) Added file: http://bugs.python.org/file27077/namedtuple_pickle_fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 21:57:56 2012 From: report at bugs.python.org (Thomas Miedema) Date: Fri, 31 Aug 2012 19:57:56 +0000 Subject: [issue15535] Fix pickling of named tuples in 2.7.3 (BUG) In-Reply-To: <1343915086.31.0.252328658724.issue15535@psf.upfronthosting.co.za> Message-ID: <1346443076.66.0.800715074678.issue15535@psf.upfronthosting.co.za> Changes by Thomas Miedema : Removed file: http://bugs.python.org/file26662/namedtuple_pickle_fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 22:19:55 2012 From: report at bugs.python.org (Nicholas Cole) Date: Fri, 31 Aug 2012 20:19:55 +0000 Subject: [issue14223] curses addch broken on Python3.3a1 In-Reply-To: <1331153094.15.0.871612927682.issue14223@psf.upfronthosting.co.za> Message-ID: <1346444395.63.0.367819904212.issue14223@psf.upfronthosting.co.za> Nicholas Cole added the comment: I'm reopening this bug because I've noticed that in Python3.3rc1, although trying to print curses.ACS_HLINE and other such characters no long cause an Exception, only blank characters are printed to the screen. Tested with both Terminal.App and xterm running under XQuartz. Here is some minimal test code, that will print a line on Python2.x but a blank screen on Python3.3rc1. ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 22:20:28 2012 From: report at bugs.python.org (Nicholas Cole) Date: Fri, 31 Aug 2012 20:20:28 +0000 Subject: [issue14223] curses addch broken on Python3.3a1 In-Reply-To: <1331153094.15.0.871612927682.issue14223@psf.upfronthosting.co.za> Message-ID: <1346444428.52.0.388777546981.issue14223@psf.upfronthosting.co.za> Nicholas Cole added the comment: import curses def test_screen(screen): screen.addch(5,5, curses.ACS_HLINE) screen.addch(5,6, curses.ACS_HLINE) screen.refresh() curses.napms(2000) curses.wrapper(test_screen) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 22:38:34 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 31 Aug 2012 20:38:34 +0000 Subject: [issue15756] subprocess.poll() does not handle errno.ECHILD "No child processes" In-Reply-To: <1345576517.75.0.906463701582.issue15756@psf.upfronthosting.co.za> Message-ID: <1346445514.85.0.759562956131.issue15756@psf.upfronthosting.co.za> Gregory P. Smith added the comment: thanks! I'll take care of getting this fix in. ---------- assignee: -> gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 22:40:45 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 31 Aug 2012 20:40:45 +0000 Subject: [issue15821] PyMemoryView_FromBuffer() behavior change (possible regression) In-Reply-To: <20120831191212.GA2642@sleipnir.bytereef.org> Message-ID: Alexander Belopolsky added the comment: On Fri, Aug 31, 2012 at 3:12 PM, Stefan Krah wrote: > Now I'm puzzled: I thought your goal was to preserve the implicit cleanup > from 3.2, i.e. PyBuffer_Release() is called when the managed buffer is > deallocated. > The issue that I raised in msg169472 above was that PyMemoryView_FromBuffer() would not copy .obj from Py_buffer structure to the memoryview. A related issue is that it looks like PyObject_GetBuffer() often does not fill .obj either. I would expect that PyObject_GetBuffer() would always store a new reference in .obj to assure that the .buf pointer remains valid until PyBuffer_Release() is called explicitly. (I am ignoring the issue of mutable objects such as lists for the moment.) PyMemoryView_FromBuffer() in turn should store an additional reference in its own private copy of Py_buffer structure. After PyMemoryView_FromBuffer() returns a well-behaved program should call PyBuffer_Release() releasing the first reference and the second reference should be released in memoryview destructor. Am I missing something? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 23:06:10 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 31 Aug 2012 21:06:10 +0000 Subject: [issue15821] PyMemoryView_FromBuffer() behavior change (possible regression) In-Reply-To: <1346320388.88.0.494685067241.issue15821@psf.upfronthosting.co.za> Message-ID: <1346447170.51.0.944082632726.issue15821@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Here is what I think the test case should look like (untested): static PyObject * memoryview_from_buffer_cleanup(PyObject *self, PyObject *noargs) { PyObject *b, *view = NULL; Py_buffer info; Py_ssize_t shape[3] = {2, 2, 3}; Py_ssize_t strides[3] = {6, 3, 1}; const char *cp = "abcdefghijkl"; b = PyBytes_FromString(cp); if (b == NULL) return NULL; if (PyObject_GetBuffer(b, &info, PyBUF_FULL_RO) < 0) goto done; /* reshape */ info.ndim = 3; info.shape = shape; info.strides = strides; view = PyMemoryView_FromBuffer(&info); /* release resources allocated for Py_buffer struct before it goes out of scope */ PyBuffer_Release(&info); done: Py_DECREF(b); return view; } ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 23:11:02 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 31 Aug 2012 21:11:02 +0000 Subject: [issue15830] make -s no longer silences output from setup.py In-Reply-To: <1346421796.43.0.205634084125.issue15830@psf.upfronthosting.co.za> Message-ID: <1346447462.53.0.322199671874.issue15830@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +doko _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 23:12:26 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 31 Aug 2012 21:12:26 +0000 Subject: [issue15833] most failures to write byte-compiled file no longer suppressed In-Reply-To: <1346432246.49.0.876284426658.issue15833@psf.upfronthosting.co.za> Message-ID: <1346447546.49.0.958846585535.issue15833@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Raising EIO in a read-only dir sounds weird. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 23:19:36 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 31 Aug 2012 21:19:36 +0000 Subject: [issue8912] `make patchcheck` should check the whitespace of .c/.h files In-Reply-To: <1275794679.2.0.211731721822.issue8912@psf.upfronthosting.co.za> Message-ID: <1346447976.73.0.0269172426224.issue8912@psf.upfronthosting.co.za> Chris Jerdonek added the comment: The following commit from today is related to this issue: 815b88454e3e "Remove trailing whitespace in order to silence warnings on HP-UX." ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 23:29:01 2012 From: report at bugs.python.org (Berker Peksag) Date: Fri, 31 Aug 2012 21:29:01 +0000 Subject: [issue15775] Add StopParser() to expat In-Reply-To: <1345796297.89.0.127411549702.issue15775@psf.upfronthosting.co.za> Message-ID: <1346448541.22.0.916484599091.issue15775@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 31 23:35:09 2012 From: report at bugs.python.org (Alessandro Moura) Date: Fri, 31 Aug 2012 21:35:09 +0000 Subject: [issue15826] Increased test coverage of test_glob.py In-Reply-To: <1346381534.69.0.636623200483.issue15826@psf.upfronthosting.co.za> Message-ID: <1346448909.2.0.0462989838925.issue15826@psf.upfronthosting.co.za> Alessandro Moura added the comment: Agreed, here is the patch where this is done. ---------- Added file: http://bugs.python.org/file27078/test_glob.patch _______________________________________ Python tracker _______________________________________